You are on page 1of 29

Android

4.1 (Jelly Bean)

Android
Open so6ware pla8orm for mobile development A complete stack: OS, Middleware, ApplicaDons An Open Handset Alliance (OHA) project Powered by Linux operaDng system Open source under the Apache 2 license
Email, calendar, browser, maps, text messaging, contacts, camera, dialer, music player, seOngs and others

Android ships with a rich set of applicaDons

A bit of process

Set up
Set up your development environment Install the Android SDK, Android Development Tools, and Android pla8orms Set up AVDs and devices for tesDng Create Android Virtual Devices (AVDs) and connect hardware devices on which you can install your applicaDons

Development Create your applicaDon Create an Android project with your source code, resource les, and Android manifest le

Debugging and tesDng

Build and run your applicaDon Build and run your applicaDon in debug mode

Debug your applicaDon Debug your applicaDon using the Android debugging and logging tools

Test your applicaDon Test your applicaDon using the Android tesDng instrumentaDon framework

Publishing

Prepare your applicaDon for release Congure, build, and test your applicaDon in release mode

Release your applicaDon Publicize, sell, and distribute your applicaDon to users

Linux Kernel
Based on Linux kernel 2.6 Works as a Hardware AbstracDon Layer Provides
High security Device drivers Memory management Process management Networking

Libraries
C/C++ libraries Interface through Java Surface manager
UI Windows

2D and 3D graphics Media codecs, SQLite, Browser engine

RunDme
DVM (Dalvik Virtual Machine)
Java source code is compiled to a class le (.class) Later transformed to Dalvik Executable (.dex) Compact and ecient Limited memory and bacery power

Core Libraries
Java standard ediDon CollecDons, I/O etc

Highest levels
ApplicaDon Framework
Provides all kinds of APIs needed to develop applicaDons AcDvity manager manages applicaDon life cycle

ApplicaDons
ApplicaDons developed with Java
email client, SMS program, calendar, browser and contacts applicaDons

Can replace built in apps

Packaging
An applicaDon is a single APK (applicaDon package) le An APK le roughly has three main components
Dalvik executable: all your Java source code compiled down to Dalvik executable Resources: everything that is not code (images, audio/video clips, XML les describing layouts, language packs, and so on) NaDve libraries: e.g. C/C++ libraries

Manifest
User permissions the applicaDon requires Minimum API Level required by the applicaDon Hardware and so6ware features used or required by the applicaDon API libraries the applicaDon needs to be linked against And more

Security model
Android OS is a mulD-user Linux system in which each applicaDon is a dierent user The system assigns each applicaDon a unique Linux user ID (the ID is unknown to the applicaDon)
The system sets permissions for all the les in an applicaDon so that only the user ID assigned to that applicaDon can access them

Each process has its own virtual machine (VM)


An applicaDon's code runs in isolaDon with respect to other applicaDons

Every applicaDon runs in its own Linux process

CooperaDon and sharing


Each applicaDon has access only to the components it requires to work and nothing more Two applicaDons can share the same Linux user ID
They would be able to access each other's les ApplicaDons with the same ID can also be run in the same Linux process and share the same VM
The applicaDons must also be signed with the same cerDcate

An applicaDon can request permission to access device data


All permissions must be granted when installing the applicaDon

4 building blocks
AcDviDes Services Content providers Broadcast receivers

AcDviDes
Represent the presentaDon layer of an Android applicaDon An acDvity consists of a single screen the user sees
For example, an acDvity that shows a list of new emails, another acDvity to compose an email, and another acDvity for reading emails Although acDviDes work together, each one is independent of the others An acDvity is implemented as a subclass of Ac#vity
An applicaDon can start any one of these acDviDes

AcDviDes can be:

Be faceless Be in a oaDng window Return a value

Services
Are component that run in the background to perform long-running operaDons or to perform work for remote processes A service does not provide a user interface

For example, a service might play music in the background while the user is in a dierent applicaDon, or it might fetch data over the network without blocking user interacDon with an acDvity Another component, such as an acDvity, can start the service and let it run or bind to it in order to interact with it A service is implemented as a subclass of Service

Content providers
Manage a shared set of applicaDon data You can store the data in the le system, an SQLite database, on the web, or any other persistent storage locaDon your applicaDon can access
Through the content provider, other applicaDons can query or even modify the data (if the content provider allows it) For example, the Android system provides a content provider that manages the user's contact informaDon
Any applicaDon with the proper permissions can query it to read and write informaDon about a parDcular person

Content providers are also useful for reading and wriDng data that is private to your applicaDon and not shared. Provide uniform APIs for: querying, deleting, updating, and inserting elements

A content provider is implemented as a subclass of ContentProvider and must implement a standard set of APIs that enable other applicaDons to perform transacDons

Broadcast receivers
Are components that respond to system-wide broadcast announcements
Many broadcasts originate from the systemfor example, a broadcast announcing that the screen has turned o, the bacery is low, or a picture was captured ApplicaDons can also iniDate broadcastsfor example, to let other applicaDons know that some data has been downloaded to the device and is available for them to use For instance, it might iniDate a service to perform some work based on the event A broadcast receiver is implemented as a subclass of BroadcastReceiver and each broadcast is delivered as an Intent object

A broadcast receiver is just a "gateway" to other components and is intended to do a very minimal amount of work

Key terminology

AcDvaDng Components
AcDviDes, services, and broadcast receivers are acDvated by Intent
Intents bind individual components to each other at runDme An intent is created with an Intent object, which denes a message to acDvate either a specic component or a specic type of component For acDviDes and services, an intent denes the acDon to perform For broadcast receivers, the intent simply denes the announcement being broadcast They are acDvated when targeted by a request from a ContentResolver This leaves a layer of abstracDon between the content provider and the component requesDng informaDon (for security)

Content providers are not acDvated by intents

Example methods
There are separate methods for acDvaDng each type of component
You can start an acDvity (or give it something new to do) by passing an Intent to startAcDvity() or startAcDvityForResult() (when you want the acDvity to return a result) You can start a service (or give new instrucDons to an ongoing service) by passing an Intent to startService(). Or you can bind to the service by passing an Intent to bindService() You can iniDate a broadcast by passing an Intent to methods like sendBroadcast(), sendOrderedBroadcast(), or sendSDckyBroadcast() You can perform a query to a content provider by calling query() on a ContentResolver

Main characterisDcs
Any applicaDon can start another applicaDons component
For example, one can simply start the acDvity in the camera applicaDon that captures a photo. When complete, the photo is even returned to your applicaDon so you can use it

When the system starts a component, it starts the process for that applicaDon and instanDates the classes needed for the component
For example, if one starts the acDvity in the camera applicaDon that captures a photo, that acDvity runs in the process that belongs to the camera applicaDon, not in your applicaDon's process To acDvate a component in another applicaDon, you must deliver a message to the system that species your intent to start a parDcular component The system then acDvates the component for you

An applicaDon cannot directly acDvate a component from another applicaDon, but the Android system can

Android through MVC


View Control Model

AcDvity Service View and related classes Broadcast receiver

SQLite

File and content providers

You might also like