23-02-2012, 02:56 PM
Analysis of the Android Architecture
Deutsche Zusammenfassung
Die vorliegende Studienarbeit besch¨aftigt sich mit dem Android Betriebsystem
f¨ur mobile Systeme. Die Arbeit stellt das System grunds¨atzlich vor und zeigt an
einigen Stellen Besonderheiten und spezielle Anpassungen von Android auf.
Als Betriebsystem f¨ur mobile Systeme wie Smartphones und Tablets liegen bei
Android Schwerpunkte auf Energieeffizienz und Energieverwaltung. Diese Schwerpunkte
treten an vielen Stellen in den Vordergrund bei Designentscheidungen und
pr¨agen daher das System sehr stark.
Android basiert auf Linux und verschiedenen typischen Bibliotheken und Diensten
im Linux Umfeld auf, z.B. libSSL, FreeType und SQLite. Diese Infrastruktur
bildet die Basis f¨ur eine Laufzeitumgebung in der Java Programme ausgef¨uhrt
werden. Die Laufzeitumgebung Dalvik f¨uhrt modifizierte Java class Dateien aus,
wobei jedes Programm in einer eigenen Dalvik Instanz in einem eigenen Prozess
l¨auft. Dalvik ist spezialisiert und optimiert auf die besonderen Gegebenheiten und
Limitierungen von mobilen Systemen, wie begrenzter Speicherplatz und Energiebedarf.
Anwendungen in Android sind aus verschiedenen Komponenten aufgebaut,
wobei die einzelnen Komponenten klar getrennte Aufgabenbereiche haben. Diese
Modularisierung erlaubt es, daß sich Anwendungen bestimmte Komponenten teilen
k¨onnen und daß einzelne Komponenten im System ausgetauscht werden k¨onnen.
Alle Anwendungen sind voneinander getrennt und k¨onnen im Normalfall nicht auf
Daten anderer Anwendungen zugreifen.
In den Kernel sind einige A¨ nderungen eingeflossen die den Android Kernel
haupts¨achlich um neue Funktionen in Bereichen der Energieverwaltung und
Speicherverwaltung erweitern. Die weitreichenste A¨ nderung betrifft die Energieverwaltung
in Form der neu eingef¨uhrten wake locks, welche es erlauben, dem
System bestimmte Schlaf- und Ruhezust¨ande vorzuenthalten. Weiterhin sind neue
Treiber und Anpassungen f¨ur die Android Infrastruktur in den Kernel gelangt.
F¨ur die Anwendungsentwicklung stehen eine Vielzahl von Programmierschnittstellen
bereit, welche viele Java Standard Schnittstellen abdecken und teilweise
erweitern. Android bietet weitreichende Netzwerkunterst¨utzung und ein erweiterbares
Framework f¨ur verschiedenste Medienformate. Zur Datenspeicherung und
iii
iv DEUTSCHE ZUSAMMENFASSUNG
Datenverwaltung stehen sowohl normale Dateien als auch SQLite Datenbankdateien
samt Mitteln zur Sicherung von Daten und Einstellungen zur Verf¨ugung.
Um die Entwicklungsarbeit zu erleichtern, gibt es eine Vielzahl von Werkzeugen
die in einem Software Development Kit (SDK) mitgeliefert werden. Zu diesen
Werkzeugen geh¨oren u.a. ein Emulator, ein Eclipse Plugin und eine Debug Shell
samt Debug Monitor. Zum Testen und Debuggen gibt es sowohl Werkzeuge, als
auch ein Instrumentation Framework und angepasste JUnit Tests.
Hiermit erkl¨are ich, die vorliegende Arbeit selbstst¨andig verfasst und keine anderen
als die angegebenen Literaturhilfsmittel verwendet zu haben.
I hereby declare that this thesis is a work of my own, and that only cited sources
have been used.
Karlsruhe, 6. Oktober 2010
Introduction and overview of
Android
As smartphones and tablets become more popular, the operating systems for those
devices become more important. Android is such an operating system for low
powered devices, that run on battery and are full of hardware like Global Positioning
System (GPS) receivers, cameras, light and orientation sensors, WiFi and UMTS
(3G telephony) connectivity and a touchscreen. Like all operating systems, Android
enables applications to make use of the hardware features through abstraction and
provide a defined environment for applications.
Unlike on other mobile operating systems like Apple’s iOS, Palm’s webOS or
Symbian, Android applications are written in Java and run in virtual machines. For
this purpose Android features the Dalvik virtual machine which executes it’s own
byte code. Dalvik is a core component, as all Android user applications and the
application framework are written in Java and executed by Dalvik. Like on other
platforms, applications for Android can be obtained from a central place called
Android Market.
The platform was created by Android Inc. which was bought by Google and
released as the Android Open Source Project (AOSP) in 2007. A group of 78
different companies formed the Open Handset Alliance (OHA) that is dedicated
to develop and distribute Android. The software can be freely obtained from a
central repository [12] and modified in terms of the license which is mostly BSD
and Apache. [11, 8, 6, 7]
The development of Android takes place quickly, as a new major release
happens every few months (see section 1.2). This leads to a situation where
information about the platform becomes obsolete very quickly and sources like
books and articles can hardly keep up with the development. Sources that keep up
with the pace are foremost the extensive SDK documentation, documentation in
and the source code itself as well as blogs.
3
4 CHAPTER 1. INTRODUCTION AND OVERVIEW OF ANDROID
1.1 Structural overview
The Android software stack as shown in figure 1.1 can be subdivided into five
layers: The kernel and low level tools, native libraries, the Android Runtime, the
framework layer and on top of all the applications.
Figure 1.1: Android system architecture. Green items are written in C/C++, blue
items are written in Java and run in the Dalvik VM. Image taken from [22, What is
Android?].
The kernel in use is a Linux 2.6 series kernel, modified for special needs in
power management, memory management and the runtime environment. Right
above the kernel run some Linux typical daemons like bluez for Bluetooth support
and wpa supplicant for WiFi encryption.
As Android is supposed to run on devices with little main memory and low
powered CPUs, the libraries for CPU and GPU intensive tasks are compiled to
device optimized native code. Basic libraries like the libc or libm were developed
especially for low memory consumption and because of licensing issues on Android.
In this layer the surface manager handles screen access for the window manager
from the framework layer. Opposing to other frameworks, the media framework
1.2. BRIEF VERSION HISTORY 5
resides in this layer, as it includes audio and video codecs that have to be heavily
optimized.
The Android Runtime consists of the Dalvik virtual machine and the Java core
libraries. The Dalvik virtual machine is an interpreter for byte code that has been
transformed from Java byte code to Dalvik byte code. Dalvik itself is compiled to
native code whereas the the core libraries are written in Java, thus interpreted by
Dalvik.
Frameworks in the Application Framework layer are written in Java and provide
abstractions of the underlying native libraries and Dalvik capabilities to
applications. Android applications run in their own sandboxed Dalvik VM and
can consist of multiple components: Activities, services, broadcast receivers and
content providers. Components can interact with other components of the same or
a different application via intents.
[b]1.2 Brief version history[/b]
Android is a young platform and the development is very rapid, as new major
releases come out every few months. The following list shows the major Android
versions and bigger changes in each version. More detailed information about
the changes in each Android version can be found in [22, Android x.y Platform
Highlights].
1.1 – February 2009 – Initial release
1.5 (Cupcake) – April 2009 – User Interface (UI) updates for all core elements,
accelerometer-based application rotations, on-screen soft keyboard, video
recording & playback, Bluetooth (A2DP and AVCRP profiles), based on
kernel 2.6.27
1.6 (Donut) – September 2009 – Gesture support, support for higher screen resolutions
(WVGA), text-to-speech engine, Virtual Private Network & 802.1x
support, based on kernel 2.6.29
2.0 (E´ clair) – October 2009 – Major UI update, Bluetooth 2.1 (new OPP and
PBAP profiles), media framework improvements, Microsoft Exchange support,
based on kernel 2.6.29
2.1 (E´ clair) – January 2010 – Minor update, UI tweaks, based on kernel 2.6.29
2.2 (Froyo) – May 2010 – Performance optimizations, just in time compiler, tethering
and WiFi hotspot capability, Adobe Flash support, enhanced Microsoft
Exchange support, OpenGL ES 2.0 support, based on kernel 2.6.32
6 CHAPTER 1. INTRODUCTION AND OVERVIEW OF ANDROID
This study thesis is based on Android version 2.2. which is the latest release as of
writing.
Application anatomy
Running applications is a major goal of operating systems and Android provides
several means on different layers to compose, execute and manage applications.
For this purpose Android clearly differentiates the terms application, process, task
and thread. This chapter explains each term by itself as well as the correlation
between the terms.
2.1 Processes & threads
Five types of processes are distinguished in Android in order to control the behavior
of the system and it’s running programs. The various types have different importance
levels which are strictly ordered. The resulting importance hierarchy for
process classes looks like this (descending from highest importance, from [22, Application
Fundamentals]):
Foreground A process that is running an Activity, a Service providing the Activity,
a starting or stopping Service or a currently receiving BroadcastReceiver.
Visible If a process holds a paused but still visible Activity or a Service bound to
a visible Activity and no foreground components, it is classified a visible
process.
Service A process that executes an already started Service.
Background An Activity that is no longer visible is hold by a background process.
Empty These processes contain no active application components and exists only
for caching purposes.
If the system is running low on memory, the importance of a process becomes
a crucial part in the system’s decision which process gets killed to free memory.
7
8 CHAPTER 2. APPLICATION ANATOMY
Therefore empty processes are killed most likely followed by background processes
and so on. Usually only empty and background processes are killed so the user
experience stays unaffected. The system is designed to leave everything untouched
as long as possible that is associated with a visible component like an Activity. [24]
Processes can contain multiple threads, like it is usual on Linux based systems.
Most Android applications consist of multiple threads to separate the UI from input
handling and I/O operations or long running calculations, hence the underlying
processes are multi-threaded. The threads used on application level are standard
Java threads running in the Dalvik VM.
2.2 Applications & tasks
Android applications are run by processes and their included threads. The two
terms task and application are linked together tightly, given that a task can be seen
as an application by the user. In fact tasks are a series of activities of possibly
multiple applications. Tasks basically are a logical history of user actions, e.g.
the user opens a mail application in which he opens a specific mail with a link
included which is opened in a browser. In this scenario the task would include two
applications (mail and browser) whereat there are also two Activity components of
the mail application and one from the browser included in the task. An advantage
of the task concept is the opportunity to allow the user to go back step by step like
a pop operation on a stack.
2.3 Application internals
The structure of an Android application is based on four different components,
which are: Activity, Service, BroadcastReceiver and ContentProvider. An application
does not necessarily consists of all four of these components, but to present a
graphical user interface there has to be at least an Activity.
Applications can start other applications or specific components of other applications
by sending an Intent. These intents contain among other things the name of
desired executed action. The IntentManager resolves incoming intents and starts
the proper application or component. The reception of an Intent can be filtered by
an application.
Services and broadcast receivers allow applications to perform jobs in the
background and provide additional functionality to other components. Broadcast
receivers can be triggered by events and only run a short period of time whereas a
service may run a long time.
The compiled code of the application components and additional resources
2.3. APPLICATION INTERNALS 9
like libraries, images and other necessary data is packed into a single .apk file that
forms the executable Android application.
2.3.1 AndroidManifest.xml
All Android Dalvik applications need to have a XML document in the application’s
root directory called AndroidManifest.xml. This document is used by various
facilities in the system to obtain administrative and organizational information
about the application.
In the manifest file 23 predefined element types are allowed to specify among
other things the application name, the components of the application, permissions,
needed libraries and filters for intents and broadcasts. During development the
manifest file holds the control information for instrumentation support (see section
6.2).
Some of the elements in the manifest file are discussed in more detail in other
chapters, where it matches the context. Detailed information on all elements can
be found at [22, The AndroidManifest.xml File].
2.3.2 Activities
An Activity is a single screen of an application like a browser window or a settings
page. It contains the visual elements that present data (like an image) or allow user
interaction (like a button). Each application can have multiple activities whereat
the transition between the different activities is initiated via intents.
All activities are subclasses from android.app.Activity and their life cycle is
controlled by the onXYZ() methods. This concept is needed by Android’s way of
handling multitasking and helps dealing with low memory situations (see section
2.3.6 for more detailed information about the life cycle). The main functions are:
onCreate() The initial method to set up an Activity.
onDestroy() The counterpart to onCreate().
onResume() This method is called if the Activity is visible in the foreground and
ready to get and process user input.
onPause() The method has to quickly save uncommitted data and stop CPU intensive
work to prepare the Activity to lose the focus and going to background.
onRestart() This method has to restore a previously saved state of the Activity, as
it is called after an activity was completely stopped and is needed again.
10 CHAPTER 2. APPLICATION ANATOMY
2.3.3 Intents, Intent filters and receivers
Unlike ContentProviders, the other three component types of an application (activities,
broadcast receivers and services) are activated through intents. An Intent
is an asynchronously sent message object including the message that should be
transported.
The contained message either holds the name of the action that should be performed,
or the name of the action being announced. The former applies to activities
and services, the latter to broadcast receivers. The Intent class has some actions
like ACTION EDIT and ACTION VIEW or for broadcasts ACTION TIME TICK
included already. In addition to the action, the message contains an Uniform Resource
Identifier (URI) that specifies the data used for the given action. Optionally
the Intent object can hold a category, a type, a component name, extra data and
flags. [22, Intents and Intent Filters]
Android utilizes different hooks in the application components to deliver
the intents. For an activity, it’s onNewIntent() method is called, at a service
the onBind() method is called. Broadcast actions can be announced using Context.
sendBroadcast() or similar methods. Android sends the Intent to the onReceive()
method of all matching registered receivers.
Intents can be filtered by an application to specify which intents can be processed
by the application’s components. The list of filters is set in the application’s
manifest file, thus Android can determine the allowed intents before starting an
application.