Download Android Component Model

Android Component Model
Carlo U. Nicola, IMVS FHNW
With extracts from the :
Android Developers Guide
Android architecture
Java
C/C++
Kernel
MAS HS12 2
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 3
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 4
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 5
Component model
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.
Interprocess
Intraprocess
Puzzle pieces: Components ! Android: Activities
Binding glue (double arrow line): Messages ! Android: Intents
MAS HS12 6
Android component model
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.
MAS HS12 7
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 8
How applications run
! 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.
MAS HS12 9
Activities
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.
MAS HS12 10
Services
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).
MAS HS12 11
Broadcast receivers
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.
MAS HS12 12
Content providers
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.
MAS HS12 13
Views (1)
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.
MAS HS12 14
Views (2)
! 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.
Menu items
Button
Text field
MAS HS12 15
Activating components
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.
MAS HS12 16
Android application
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
MAS HS12 17
Android glossary (1)
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 timeconsuming 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.
MAS HS12 18
Android glossary (2)
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.
MAS HS12 19
Intra components messages passing: intents
MAS HS12 20
Intents = message passing between components
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.
MAS HS12 21
Intents (1)
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)
MAS HS12 22
Intents (2)
Depending upon what type of action and data the user wishes, different Intent
constructors can be used.
Implicit intent:
Explicit intent:
MAS HS12 23
Example
Examples:
Categories, Flags and Extras can be set to the Intent object as well using its
different methods, such as:
MAS HS12 24
Starting activity via intents
Launch a new activity without expecting a result:
Launch a new activity expecting a result:
The new activity replies using its
If the
method.
was >=0, this code will be returned to the
method of the calling activity.
When the new activity exits, the
activity expecting a result is called with a given
method of the
(int >0).
MAS HS12 25
Different kinds of intents
! 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.
MAS HS12 26
How does Android resolves intents?
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.
MAS HS12 27
Intents filters (3)
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:
MAS HS12 28
Standard intent actions
Beside the most important actions as
and
the
following current standard actions are used by Android. They are launched
usually through
.
MAS HS12 29
Components’ lifecycles
MAS HS12 30
Application lifecycle examples: manual switch
An activity can keep or lose its state depending on how the user leaves the activity,
either by the HOME or BACK key.
The
started anew.
activity has to be
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.
MAS HS12 31
Application lifecycle examples: multitasking
This allows multitasking:
Takes too long…
Start something else…
If the user presses Home and
then Maps, the system returns
to the map, which will have by
now has fully loaded.
MAS HS12 32
Activity lifecycle: FSM
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.
MAS HS12 33
Activity lifecycle
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.
MAS HS12 34
Lifecycle methods
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.
).
MAS HS12 35
Methods for saving the state of an activity
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.
MAS HS12 36
Methods of the Activity’s FSM (1)
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
MAS HS12 37
Methods of the Activity’s FSM (2)
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
MAS HS12 38
Examples of transitions in the activity’s FSM (1)
Task: Open Child Activity
!
!
!
!
!
! [Open Child Activity]
! [Close Child Activity]
!
Task: Turn Display
!
!
!
!
!
!
!
! [Turn Display]
!
!
MAS HS12 39
Examples of transitions in the activity’s FSM (2)
Task: Pressing Home Button
!
!
!
!
!
Task: Phone Call Interrupt
!
!
! [Home Button]
! [Start App]
!
! [Phone Call]
! [Hang Up or press
!
!
Back]
!
!
MAS HS12 40
Services: some more details
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)
MAS HS12 41
Service lifecycle
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.
MAS HS12 42
Implicit Service control via Binder (1)
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).
MAS HS12 43
Implicit Service control via Binder (2)
Binder connects the Linux Kernel with the process (where the application lies!)
MAS HS12 44
Broadcast receiver lifecycle
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.
MAS HS12 45
Content provider
MAS HS12 46
Content providers (1)
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
.
MAS HS12 47
Content providers (2)
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.
MAS HS12 48
Content provider interface
The most important methods that need to be implemented, when designing a
, are:
MAS HS12 49
Data model
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:
_ID
NUMBER
NAME
TYPE
23
044 444 444
Bob
TYPE_WORK
45
062 222 222
Alice
TYPE_HOME
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.
MAS HS12 50
URI
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.
MAS HS12 51
Querying a content provider
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.
MAS HS12 52
What a query returns
The following query:
returns:
NUMBER
NAME
_ID
TYPE
062 222 222
Alice
45
TYPE_HOME
044 444 444
Bob
23
TYPE_WORK
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.
MAS HS12 53
Reading retrieved data (1)
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 zerobased column index
return total number of columns
returns the numbers of rows in the cursor
MAS HS12 54
Reading retrieved data (2)
The following code demonstrates how to read names and phone numbers from our query:
MAS HS12 55
Security step 1: Signing
MAS HS12 56
Security step 2: Application sandbox
MAS HS12 57
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 58
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
AndroidManifest.xml
From: Enck, et al. IEEE Security & Privacy, Jan./Feb.(2009) p.50-57
MAS HS12 59
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 60
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" />
API protection
<uses-permission android:name="ch.fhnw.apsi.permission.FRIEND_NEAR" />
</manifest>
MAS HS12 61
Android components’ interaction
From: Enck, et al. IEEE Security & Privacy, Jan./Feb.(2009) p.50-57
MAS HS12 62
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.
Always set the exported attribute explicitly to true or false,
especially if a “sub-Activity” returns a result.
<activity android:name="FriendMap" android:exported="false" />
MAS HS12 63
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
Components without access permissions should be exceptional cases,
and possible inputs must be carefully analysed (consider splitting
components).
<activity android:name="FriendMap" android:exported="false" />
MAS HS12 64
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 65
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 66
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 67
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
MAS HS12 68