Android Component Model

Carlo U. Nicola, IMVS FHNW

With extracts from the :

Android Developers Guide

MAS HS12 2

Java

C/C++

Kernel

Android architecture

MAS HS12 3

Android (1)

Open-source platform (Open Handset Alliance)

Native development, Java development

Platform outline:

! Linux kernel ¸ 2.6

! Webkit-based browser engine

! SQLite as DB

! Open SSL, Bouncy Castle crypto API and Java library

! Bionic C library (small code, good performance, no GPL)

! Apache Harmony libraries (open source Java implementation)

! Many others: video stuff, Bluetooth, vibrate phone, etc.

MAS HS12 4

Android challenges

Battery life:

! Developers must conserve power

! Applications store state so they can be stopped (to save power)

and restarted (helps with DoS attacks)

! The most foreground activity is never killed

Android market:

! Not reviewed by Google (not like Apple!)

! No way of stopping bad applications from showing up on

market

! Malware writers may be able to get code onto platform: shifts

focus from remote exploit to privilege escalation

MAS HS12 5

Application = set of components

Basic components:

Activity: defines the user interface:

– Example: scroll through your inbox

– Email client comprises many activities

Service: Java daemon that runs in background

– Example: application that streams an mp3 in background

Content provider

– Store and share data using a relational database interface

Broadcast receiver

– “mailboxes” for messages from other applications

MAS HS12 6

A central feature of Android is that one application consisting of different Activities can start

and use Activities within and without the process in which it started.

Puzzle pieces: Components ! Android: Activities

Binding glue (double arrow line): Messages ! Android: Intents

Interprocess Intraprocess

Component model

MAS HS12 7

A central feature of Android is that one application can make use of components of

other applications either within the same process or in another process; under the proviso

that those applications permit it.

Thus, the system must be able to start an application process when any part of it is

needed, and instantiate the Java objects for that part. Therefore, Android applications don't have a single entry point for everything in the application (no main() function, for

example). Rather, they have essential components that the system can instantiate and

run as needed.

Android component model

MAS HS12 8

Components: message passing system

Intents : asynchronous messaging system:

– Signal an intent to switch from one activity to another

– Example: email app has an inbox, a compose activity, a viewer activity

• User click on inbox entry fires an intent to the viewer activity, which then allows the user to view that email

MAS HS12 9

! Components of an application share a Linux process:

By default, every application runs in its own Linux process.

! Applications are isolated:

Each process has its own Java virtual machine (VM), so application code runs

in isolation.

! By default, each application is assigned a unique Linux user ID.

How applications run

MAS HS12 10

An activity presents a visual user interface for one focused task.

! Each activity is implemented as a subclass of the Activity base class.

! Typically, one activity corresponds to one screen, i.e. each activity is given a

default window to draw in. ! An application may consist of several activities.

! But, each activity is independent of the others.

Activities

MAS HS12 11

A service doesn't have a visual user interface, but rather runs in the background

for an indefinite period of time, e.g. a service might play background music while

the user performs other tasks. The system would keep playing music even after

the activity that started the playback service leaves the screen.

! Each service extends the Service base class.

! It's possible to connect (to bind) to an ongoing service, and while connected,

one can communicate with the service through an interface that the service

exposes. ! Services often spawn another thread for time-consuming tasks (like music

playback).

Services

MAS HS12 12

A broadcast receiver is a component that does nothing but receive and react to

broadcast announcements.

Many broadcasts arrive from the Android OS, e.g. announcements that the

time zone has changed, that the battery is low, that a picture has been taken, or

that the user changed a language preference.

Applications can also initiate broadcasts.

! Each receiver extends the BroadcastReceiver base class.

! An application can have as many broadcast receivers as announcements to

respond. ! Broadcast receivers do not display a user interface.

! In response to the information they receive, they may start an activity, or

they may use the NotificationManager to alert the user.

Broadcast receivers

MAS HS12 13

A content provider enables different applications to share data.

Basically the data can be stored (i) in the Android file system, or (ii) in an SQLite

database.

! Each content provider extends the ContentProvider base class,

implementing a standard set of methods that enable other applications to

retrieve and store data of the type it controls. ! Applications must use a ContentResolver object to call those methods.

! A ContentResolver can communicate with any content provider.

! Content providers are activated when they're targeted by a request from a

ContentResolver.

Content providers

MAS HS12 14

The visual content of an activity's window is provided by a hierarchy of views,

i.e. objects derived from the base class.

Views allow activities to interact with the user.

A view hierarchy is placed within an activity's window by the following method:

. The content view is the object at the

root of the hierarchy.

Views (1)

MAS HS12 15

! Each view controls a particular rectangular space within the window.

! Parent views contain and organize the layout of their children.

! Child views draw in the rectangles they control and respond to user actions

directed at that space. ! Android has a number of ready-made views — including buttons, text

fields, scroll bars, menu items, check boxes, and more.

Button

Text field

Menu items

Views (2)

MAS HS12 16

Activities, services, and broadcast receivers are activated by asynchronous messages called intents. An intent is an Intent object that holds the content of

a message.

For activities and services, the message consists of the action being requested

and specifies the URI of the data to act upon.

For broadcast receivers, the object names the action being announced.

Activating components

MAS HS12 17

An Android application consists of:

! Collection of components

! Components share a set of resources

resource files, preferences,

databases, storage files

! Components communicate via intents

! Every component has a managed

lifecycle

Android application

MAS HS12 18

Application: An application is made up from different components packaged

within a single file. The components of an application can call

components outside the limits of the starting process.

Task: A task is what the user experiences as “application”

Process: When the first component of an application is run, the Android OS

starts a Linux process with a single thread of execution.

Thread: The thread that host an activity should not also host time-

consuming operations like lengthy calculations or network downloads. It is

better to start different threads that are responsible for that and communicate

with the main one via call-back. See the Sieve of Eratosthenes example.

Android glossary (1)

MAS HS12 19

URIs in Android

Android uses URI strings as the basis for requesting data in a content

provider (such as to retrieve a list of contacts) and for requesting actions

in an Intent (such as opening a Web page in a browser). The URI

scheme and format is specialized according to the type of use, and an

application can handle specific URI schemes and strings in any way it

wants. Some URI schemes are reserved by system components. For

example, requests for data from a content provider must use the

content:// . In an Intent, a URI using an http:// scheme will be

handled by the browser.

Android glossary (2)

MAS HS12 20

Intra components messages passing: intents

MAS HS12 21

Intents are used to communicate intra components and to pass information

between them.

! An activity is launched (or given something new to do) by passing an

Intent object to .

! The responding activity can look at the initial intent that caused it to be

launched by calling its method.

! If an activity expects a result back from the activity it's starting, it calls

the method instead of

.

! The result is returned in an Intent object that's passed to the calling

activity's method.

Intents = message passing between components

MAS HS12 22

An Intent object contains two kinds of information:

1. Information for the component that receives the intent (such as the

action to be taken and the data to act on) and

2. Information of interest to the Android system (such as the category of

component that should handle the intent and instructions on how to

launch a target activity).

Basically an intent consists of:

a) Component name (fully qualified class name of the target component

that should handle the intent )

b) Action to be performed ( …) c) Data to act upon (URI)

d) Categories (additional information about the kind of component that

should handle the intent )

e) Extras (key-value pairs for additional information )

f) Flags (e.g. instructs the Android system on how to launch an activity)

Intents (1)

MAS HS12 23

Depending upon what type of action and data the user wishes, different Intent

constructors can be used.

Implicit intent:

Explicit intent:

Intents (2)

MAS HS12 24

Examples:

Categories, Flags and Extras can be set to the Intent object as well using its

different methods, such as:

Example

MAS HS12 25

Launch a new activity without expecting a result:

Launch a new activity expecting a result:

The new activity replies using its method.

If the was >=0, this code will be returned to the

method of the calling activity.

When the new activity exits, the method of the activity expecting a result is called with a given (int >0).

Starting activity via intents

MAS HS12 26

! Explicit intents are typically used for application-internal messages,

such as an activity starting a service or launching a sister activity.

Android delivers an explicit intent to an instance of the designated target

class.

! Implicit intents do not name a target. They are often used to activate

components in other applications, since component names will generally

not be known to developers of other applications. In this case, the

Android system must find the best component (or components) to

handle the intent. It thus compares the following contents of the

object to intent filters: ! action

! data (both URI and data type)

! category.

Different kinds of intents

MAS HS12 27

Intent filters are structures associated with components that can potentially

receive intents. Since the Android system must know about the capabilities of

a component before it can launch that component, intent filters are generally set

up with the tag <intent-filter> in the AndroidManifest.xml file.

To inform the system which implicit intents they can handle, activities, services,

and broadcast receivers can have one or more intent filters.

An intent filter is an instance of the IntentFilter class.

A filter contains elements that parallel the action, data, and category fields of

an Intent object. An implicit intent is tested against the filter in all three

areas. The implicit intent is only delivered to the component that owns the filter,

if it musters all three tests. If it fails even one of them, the Android OS won't

deliver it to the component: at least not on the basis of that filter.

How does Android resolves intents?

MAS HS12 28

An example of intent filters supposed to handle different implicit intents:

Note that in order that an implicit intent can pass a given filter, that filter must contain:

Intents filters (3)

MAS HS12 29

Beside the most important actions as and the

following current standard actions are used by Android. They are launched

usually through .

Standard intent actions

MAS HS12 30

Components’ lifecycles

MAS HS12 31

An activity can keep or lose its state depending on how the user leaves the activity,

either by the HOME or BACK key.

Starting the activity again,

will bring it to the foreground (changing it

from stopped to running), and display it

in the state it was left.

The activity has to be

started anew.

Application lifecycle examples: manual switch

MAS HS12 32

This allows multitasking:

If the user presses Home and

then Maps, the system returns

to the map, which will have by

now has fully loaded.

Takes too long… Start something else…

Application lifecycle examples: multitasking

MAS HS12 33

Multitasking and switching between

different tasks is controlled by a FSM

(Finite State Machine: see Real Time

Pattern Chapter) that handles how the

state of an activity may change.

Activity lifecycle: FSM

MAS HS12 34

An activity has essentially three (four) states:

Active / Running ! Activity is in foreground

! Activity has focus

Paused

! Still visible, partially overlaid

! Focus lost

! Fully alive

Stopped

! Activity is not visible

! Retains all state and member information

Destroyed

! Activity was terminated or killed

If an activity is paused or stopped, the system can

drop it from memory. When it is displayed again to

the user, it must be completely restarted and restored

to its previous state.

Activity lifecycle

MAS HS12 35

As an activity passes from one state to another,

it is notified of the change by calls to the

protected methods, displayed in the graphic.

All these methods are hooks that one can

override to do appropriate work when the state

changes.

But all activities must implement the

method to do the initial setup

when the object is first instantiated.

Many will also implement to

commit data changes and otherwise prepare to

stop interacting with the user.

Notice:

An implementation of any activity lifecycle

method should always first call the superclass version (e.g. ).

Lifecycle methods

MAS HS12 36

When the system, rather than the user, shuts down an activity to conserve memory, the

user may expect to return to the activity and find it in its previous state.

To capture the state before the activity is killed, one can implement its method called

. Android calls this method before is called. It

passes the method a object where one can record the dynamic state of the

activity as name-value pairs. When the activity is again started, the object is

passed both to and to a method that's called after

so that either or both of them can recreate the

captured state.

Unlike and all the other methods, and

are not lifecycle methods. They are not always called.

Thus one should use only to record the transient state of

the activity, not to store persistent data. Use for that purpose instead.

Methods for saving the state of an activity

MAS HS12 37

The following methods governs the FSM of an activity:

! Called when activity is first created (with null parameter) or when activity

was killed (called with a object)

! Initialization of views

! Called when activity was stopped only

! Activity becomes visible to user, animations could be started

! Restore view state

! New activity becomes visible or a paused/stopped one comes to the

foreground again

Methods of the Activity’s FSM (1)

MAS HS12 38

The following methods are called on pausing or stopping an activity:

onSaveInstanceState() ! Save the dynamic state of activity

)

)

! Not called, if an application is explicitly finished, such as user pressing the

key

! Called before

onPause() ! Activity no longer in the foreground, but still visible

! Used to commit unsaved changes to persistent data, stop animations and

other things that may consume too much CPU time and battery. ! Should be quick, as the new activity is not started until returns

onStop() ! Activity is no longer visible

onDestroy() ! Release all resources

! It is not guaranteed that this method is called

Methods of the Activity’s FSM (2)

MAS HS12 39

Task: Open Child Activity ! ! ! [Open Child Activity]

! ! ! [Close Child Activity]

! !

Task: Turn Display ! ! ! [Turn Display]

! ! !

! ! !

!

Examples of transitions in the activity’s FSM (1)

MAS HS12 40

Task: Pressing Home Button ! ! ! [Home Button]

! ! ! [Start App]

! !

Task: Phone Call Interrupt ! ! ! [Phone Call]

! ! ! [Hang Up or press

Back] ! !

Examples of transitions in the activity’s FSM (2)

MAS HS12 41

Characteristics

Execution of long running tasks without visual user interface: ! E.g. a background task that has to download data periodically

Services can explicitly be started and stopped.

Communication with service: ! In-process if service runs in same APK

! Inter-Process Communication across APKs (AIDL)

Services: some more details

MAS HS12 42

Explicit control > startService(intent) ! onCreate() ! onStart() > stopService(intent)

! onDestroy()

Implicit control (persistent connection

of a client to a service)

> bindService(intent,conn,flags)

! onCreate() ! onBind()

> unbindService(conn)

! onUnbind()! onDestroy() Remark: onBind(Intent) method returns

an IBinder object, allowing the client to

make calls back to the service.

Service lifecycle

MAS HS12 43

Binder connects the

Linux Kernel with the process

(where the application lies!)

AIDL tool can handle primitive

types,

.

The non primitive Java

parameters in the file

require a directional tag

indicating which way the data

will go:

(Primitives are by default).

Implicit Service control via Binder (1)

MAS HS12 44

Binder connects the Linux Kernel with the process (where the application lies!)

Implicit Service control via Binder (2)

MAS HS12 45

A broadcast receiver component has a single callback method:

When a broadcast message arrives for the receiver, Android calls its

method and passes it the Intent object containing the message.

The broadcast receiver is considered to be active only while it is executing this method. When returns, it becomes inactive.

A process with an active broadcast receiver is protected from being killed. But a process

with only inactive components can be killed by the system at any time, when the memory it

consumes is needed by other processes. This presents a problem when the response to a

broadcast message is time consuming and, therefore, something that should be done in a

separate thread, away from the main thread where other components of the user interface

run.

If spawns the thread and then returns, the entire process,

including the new thread, is considered inactive (unless other application components are active), putting it on the kill list. The solution is for

to start a service and let the service do the job, so the system knows that there is

still active work being done in the process.

Broadcast receiver lifecycle

MAS HS12 46

Content provider

MAS HS12 47

Content providers store and retrieve data and make it accessible to all applications.

They are the only way to share data across applications.

A number of content providers for common data types (audio, video, images,

personal contact information, etc.) are included in the package.

To make your own data public, you have two options:

You can either (i) create your own content provider (a subclass) or

(ii) you can add the data to an existing provider, if there is one that controls the same type

of data and you have permission to write to it.

Any form of storage can be used: ! SQLite DB

! Files

! Remote Store

Remark: A content provider is only required if data should be shared between multiple applications, otherwise use a database directly via .

Content providers (1)

MAS HS12 48

All content providers implement a common interface to provide access to the data. Clients use this interface only indirectly, most generally through

objects, calling the method from an activity or other

application component.

One can then use the ContentResolver's methods to interact with any content provider.

When a query is initiated, the Android system identifies the content provider that is the

target of the query and makes sure that it is up and running. Actually, it is the system that

instantiates all objects; you never need to do it on your own.

Typically, there's just a single instance of each type of . But it can

communicate with multiple objects in different applications and

processes.

Content providers (2)

MAS HS12 49

The most important methods that need to be implemented, when designing a

, are:

Content provider interface

MAS HS12 50

Content providers expose their data as a simple table on a database model, where each

row is a record and each column is data of a particular type and meaning, such as for

example a table containing names of people and their phone numbers:

A query returns a object that can move from record to record and column to

column to read the contents of each field. It has specialized methods for reading each

type of data.

_ID NUMBER NAME TYPE

23 044 444 444 Bob TYPE_WORK

45 062 222 222 Alice TYPE_HOME

Data model

MAS HS12 51

Each content provider exposes a public URI (wrapped as an Uri object) that uniquely

identifies its data set. A content provider that controls multiple tables exposes a separate

URI for each one. All URIs for providers begin with the string " ", which

identifies the data as being controlled by a content provider.

When defining a content provider it's best to define a constant for its URI, the

. It’s value must be a unique string, such as the fully-qualified class name of

the content provider class (made lowercase). For example, for the class

:

If the provider has sub-tables, one has to define constants for each of them.

These URIs should all have the same authority (since that identifies the content provider;

in red), and be distinguished only by their paths (in blue):

The URI constant is used in all interactions with the content provider. Every method takes the URI as its first argument.

URI

MAS HS12 52

To query a content provider, one needs three pieces of information :

! The URI that identifies the provider

! The names of the data fields one whishes to receive

! The data types for those fields

If one looks up a particular record, the ID for that record is also needed, such as:

To make a query, one can use either the ContentResolver.query() method or the

Activity.managedQuery() method. Both methods take the same set of arguments, and

both return a Cursor object. However, managedQuery() causes the activity to manage the

life cycle of the Cursor. A managed Cursor handles all of the niceties, such as unloading

itself when the activity pauses, and re-querying itself when the activity restarts.

Querying a content provider

MAS HS12 53

NUMBER NAME _ID TYPE

062 222 222 Alice 45 TYPE_HOME

044 444 444 Bob 23 TYPE_WORK

The following query:

returns:

The retrieved data is exposed by a Cursor object that can be used to iterate backward or

forward through the result set. One can use this object only to read the data. To add, modify, or delete data, one must use a ContentResolver object.

What a query returns

MAS HS12 54

The object returned by a query provides access to the set of results. The set

will contain either a single value, multiple values or be empty, if there was no match.

Since the Cursor object has separate methods for reading different types of data, such as

, , and , one has to know the data type of each

field to retrieve them.

The following Cursor methods are also useful for retrieval of data:

returns the zero-based index for the given

column name, or -1 if the column doesn't

exist returns the column name at the given zero-

based column index

return total number of columns

returns the numbers of rows in the cursor

Reading retrieved data (1)

MAS HS12 55

The following code demonstrates how to read names and phone numbers from our query:

Reading retrieved data (2)

MAS HS12 56

Security step 1: Signing

MAS HS12 57

Security step 2: Application sandbox

MAS HS12 58

Security step 2: Linux and ACL

Two forms of security enforcement

– Each application executes with its own user identity as Linux

process

– Android middleware has a reference monitor that mediates the

establishment of inter-component communication (ICC)

First is straightforward to implement, second requires careful consideration

of mechanisms and security policy

MAS HS12 59

Android policy enforcement

Android focuses on Inter Component Communication (ICC) whose security

policy is defined in the Android manifest file. It allows developers to specify

an high-level ACL to access the components:

1. Each component can be assigned an access permission label

2. Each application requests a list of permission labels (fixed at

install)

AndroidManifest.xml

From: Enck, et al. IEEE Security & Privacy, Jan./Feb.(2009) p.50-57

AndroidManifest.xml

MAS HS12 60

Android manifest file

Each Android application has an file which

describes all the components it uses.

Components cannot execute unless they are listed. In the file we specify:

Rules for “auto-resolution”

Runtime dependencies

Optional runtime libraries

Access rules

Required system permissions

The manifest file spells out the security policy of the whole application

MAS HS12 61

Android manifest file is a security policy file!

<?xml version="1.0" encoding="utf-8" ?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package=“ch.fhnw.apsi.friendviewer" android:versionCode="1" android:versionName="1.0.0">

<application android:icon="@drawable/icon" android:label="@string/app_name">

<uses-library android:name="com.google.android.maps" />

<activity android:name=".FriendViewer" android:label="@string/app_name">

<intent-filter>

<action android:name="android.intent.action.MAIN" />

<category android:name="android.intent.category.LAUNCHER" />

</intent-filter>

</activity>

<activity android:name="FriendMap" android:exported="false" />

<receiver android:name="FriendReceiver“

android:permission="ch.fhnw.apsi.permission.BROADCAST_FRIEND_NEAR">

<intent-filter>

<action android:name="ch.fhnw.apsi.action.FRIEND_NEAR" />

</intent-filter>

</receiver>

</application>

<uses-permission android:name="android.permission.INTERNET" />

<uses-permission android:name="ch.fhnw.apsi.permission.READ_FRIENDS" />

<uses-permission android:name="ch.fhnw.apsi.permission.FRIEND_NEAR" />

</manifest>

API protection

MAS HS12 62

Android components’ interaction

From: Enck, et al. IEEE Security & Privacy, Jan./Feb.(2009) p.50-57

MAS HS12 63

Android public and private components

The components of an application can be public or private.

The manifest schema defines an exported attribute. It specifies whether

the activity can be launched by components of other applications (true|false). If false, the activity can be launched only by components

of the same application or applications with the same user ID.

Unfortunately the default depends on complicated “intent-filter” rules!

Implication: Components may unknowingly be (or become) accessible to

other applications.

<activity android:name="FriendMap" android:exported="false" />

Always set the exported attribute explicitly to true or false,

especially if a “sub-Activity” returns a result.

MAS HS12 64

Android implicitly opens components

If the manifest file does not specify an access permission on a public

component, any component in any application can access it.

This is defensible when for instance some components provide “global”

access: e.g., the main Activity for an Application.

Implication: Unprivileged applications have access

<activity android:name="FriendMap" android:exported="false" />

Components without access permissions should be exceptional cases,

and possible inputs must be carefully analysed (consider splitting

components).

MAS HS12 65

Android intent broadcast permissions

The code broadcasting an Intent can set an access permission restricting

which Broadcast Receivers can access the Intent.

Thus we specify explicitly which application can read the broadcast.

Implication: If no permission label is set on a broadcast, any unprivileged

application can read it.

Always specify an access permission on Intent broadcasts (unless you

specify the destination explicitly).

MAS HS12 66

Android content provider permissions

Content Providers have two additional security features: (i) separate “read”

and “write” access permission labels, and (ii) URI permissions to specify which

data subsets of the parent content provider permission can be granted for.

These features give more control over application data

Implication: Content sharing need not be all or nothing. URI permissions allow

delegation (must be allowed by Provider)

Always define separate read and write permissions. Use URI

permissions to delegate rights to other components.

MAS HS12 67

Android service hooks

A Service may arbitrarily invoke the checkCallingPermission() method

to expand the ICC reference monitor.

Allows Services to differentiate access to specific methods.

Implication: The application developer can add reference monitor hooks

Use to mediate “administrative”

operations. Alternatively, create separate Services.

MAS HS12 68

Permission categories

Permissions can be: (1) normal : always granted; (2) dangerous : requires

user approval; (3) signature : matching signature key; (4)

signatureOrSystem: same as signature, but also system apps (legacy

compatibility)

Defence against malicious applications that may request sensitive

informations.

Implication: Users may not understand implications when explicitly granting

permissions.

Use signature permissions for application “suites” and dangerous

permissions otherwise and always include informative descriptions

Defined in string.xml