Company Internal DESCRIPTION

Document number

1(25)
Revision

1/1050-LXE 110 1442 Uen

Prepared by Date

PA4

SEM/CTFCB CARL SJSTRM

Contents responsible if other than preparer

2010-04-21
Remarks

Error! Unknown document property name.

Approved by

This document is managed in metaDoc. Error! Unknown document property name.

1
1.1 1.2 1.3 1.4 1.5
1

Introduction
Abstract Content Scope Audience Reference

Guidelines: Software Architecture Document http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/modguide/md_sad.htm#Contents

Application components http://developer.android.com/guide/topics/fundamentals.html#appcomp

Android telephony architecture http://www.netmite.com/android/mydroid/development/pdk/docs/telephony.html

4 5 6

U8500 Linux Modem adaptation software architecture, 15/15935-3/FCP1190935 Linux Memory management, http://www.informit.com/content/images/0131453483/downloads/gorman_book.pdf An introduction to embedded multicore, http://www.freescale.com/files/32bit/doc/ref_manual/EMBMCRM.pdf Android Porting: http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Porting-Android-toa-new-device/, http://pdk.android.com Wake Locks, http://developer.android.com/reference/android/os/PowerManager.WakeLock.html Linux Driver model, http://lwn.net/Kernel/LDD3/

8 9

10 System map, Delta (Qualcomm MSM 7227) http://metadoc.sonyericsson.net/login_link.asp?doc=1/1050-1/FCP1190794&rev=latest 11 Inside the Linux boot process, http://www.ibm.com/developerworks/library/l-linuxboot/index.html 12 Android Memory Management, http://metadoc.sonyericsson.net/login_link.asp?doc=12/1597LXE108005&rev=latest

Note: Any hard copy of this document is for reference only. Due to template and application dependencies the header and footer may fail to display correct data. It is the responsibility of the user to ensure that they have a correct and valid version. Any outdated hard copy is invalid and must be removed from possible use.

Company Internal DESCRIPTION

Document number

2(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

1.6

Terms and Abbreviation

2 3

Android Software Architecture Logical view

The logical architecture primarily supports the functional requirementswhat the system should provide in terms of services to its users. The system is decomposed into a set of key abstractions, taken (mostly) from the problem domain, in the form of objects or object classes. They exploit the principles of abstraction, encapsulation, and inheritance. This decomposition is not only for the sake of functional analysis, but also serves to identify common mechanisms and design elements across the various parts of the system.
Architectural BlueprintsThe 4+1 View Model of Software Architecture

Since the Android system is very large, presentation of the logical view of the entire system in terms of objects or classes is not feasible for this document. This chapter will therefore restrict the logical view description of the platform to a list of applications with brief descriptions: the Android standard applications and the differentiating applications that Sony Ericsson adds to the platform. Even in this very high level there are certain uncertainties it is simply not decided which applications that will be supported on this platform and the Android applications development is going on continuously. Android have the slogan All apps are equal which is a big difference compared to what one might be used to from previous mobile phone systems. This means that all applications have the same rights and that all applications can be exchanged. Even though it is possible to prevent the user from deleting certain applications, it is always possible to install a new application beside the original one and thereby change the system so that the standard apps are not used. There are, for example, several different home screen applications on the Android Market that can be downloaded and used instead of the pre-installed home screen.

3.1

Process overview
Below the running processes are illustrated. The image also depicts which process creates/owns which. Basically the init process starts the kernel process kthreadd and then starts the native user space daemons. For more information see 7.1.

Company Internal DESCRIPTION

Document number

3(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

Figure 1 Processes running in an Android system.

3.1

Android Standard Applications

The Android Platform contains several applications that can be used as is or customized. AlarmClock Browser Calculator Calendar Camera Contacts Email GoogleSearch HTMLViewer IM

Company Internal DESCRIPTION

Document number

4(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

Launcher Mms Music PackageInstaller Phone Settings SoundRecorder Stk Sync Updater VoiceDialer

Company Internal DESCRIPTION

Document number

5(25)
Revision

1/1050-LXE 110 1442 Uen

Prepared by Date

PA4

SEM/CTFCB CARL SJSTRM

Contents responsible if other than preparer

2010-04-21
Remarks

Error! Unknown document property name.

Approved by

This document is managed in metaDoc. Error! Unknown document property name.

3.2

Google Licensed Applications (GMS)

In addition to the open source applications available within the Android Software system, Google provide a set of additional applications that has to be licensed separately. Some of these apps are available on the Android Market but they are still not available in the Android open source project. Android Market Gmail Google Earth Google Maps GoogleTalk Picasa YouTube

3.3

Native services (daemons)

The following processes are launched by the init process at boot time.

3.3.1

console (/system/bin/sh) This is the command interpreter launched as a service. It reads commands from the /dev/console as its stdin and executes them as root. The purpose of the service is to be able to execute commands in a shell.

3.3.2

servicemanager (/system/bin/servicemanager) The service manager is keeping track all the services in the native framework. The services such as SurfaceFlinger are registered here and can be accessed by clients via the servicemanager API. The service manager API is not exposed to the upper layers and is intended as a native framework service. (ref /frameworks/base/cmds/servicemanager/).

3.3.3

vold (/system/bin/vold) Vold is a service to handle mounting of volumes such as the SDCard. It is a substitute for mountd which was used in early releases of the Android platform. Vold reads its configuration from a platform specific configuration file normally located in /vendor/<company>/<product>/vold.conf.

Note: Any hard copy of this document is for reference only. Due to template and application dependencies the header and footer may fail to display correct data. It is the responsibility of the user to ensure that they have a correct and valid version. Any outdated hard copy is invalid and must be removed from possible use.

Company Internal DESCRIPTION

Document number

6(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

3.3.4

debuggerd (/system/bin/debuggerd) debuggerd is daemon monitoring native crashes and logs the crash dump. It is possible to access it via the gdbserver application.

3.3.5

ril-daemon (/system/bin/rild) Is the Radio Interface Layer Daemon and handle requests to the device modem. (ref hardware/ril/rild/rild.c). The commands are listed in /hardware/ril/libril/ril_commands.h and some examples are get signal strength, hangup, dial etc. The Android radio layer interface provides an abstraction between telephony services (android.telephony classes) and the radio hardware. The diagram below illustrates the RIL in the context of Android's Telephony system architecture.

The general Android telephony architecture is described in reference [3]. See reference [4], U8500 Linux Modem adaptation software architecture, for a description of how this is integrated in the U8500 architecture.

Company Internal DESCRIPTION

Document number

7(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

3.3.6

hfag (/system/bin/sdptool) The sdptool is a tool to search for SDP services such as HFAG. HFAG is the bluetooth handsfree profile (more accurately Handsfree Audio Gateway profile). (ref Linux man pages - http://linux.die.net/man/1/sdptool)

3.3.7

hsag (/system/bin/sdptool) The sdptool is a tool to search for SDP services such as HSAG. HSAG is the bluetooth headset profile (more accurately Headset Audio Gateway profile). (ref Linux man pages - http://linux.die.net/man/1/sdptool)

3.3.8

installd (/system/bin/installd) The install daemon handles the installation of apk packages. (ref <android src root>/frameworks/base/cmds/installd)

3.3.9

flash_recovery (/system/bin/flash_image) This is a service to install the recovery image. It basically reads raw data from an image and writes it to a specific partition. (ref /recovery/mtdutils)

3.4

What else is going on?

So, apart from the services in the previous section what is running on the device? Below is a listing of the running processes (taken from a clean cupcake build, linux kernel 2.6.27 on an ADP1). These are kernel processes and spawned by the kthreadd process.

3.4.1

init The Init process is the grand-father of all other processes.

3.4.2

kthreadd The kernel thread daemon, the parent of all kernel threads. It is created by the init process.

3.4.3

ksoftirqd This is the softirq daemon. ksoftirqd is a per-cpu kernel thread that runs when the machine is under heavy soft-interrupt load. Soft interrupts are normally serviced on return from a hard interrupt, but it's possible for soft interrupts to be triggered more quickly than they can be serviced. If a soft interrupt is triggered for a second time while soft interrupts are being handled, the ksoftirq daemon is triggered to handle the soft interrupts in process context. If ksoftirqd is taking more than a tiny percentage of CPU time, this indicates the machine is under heavy soft interrupt load. (ref Linux programmers manual http://www.tin.org/bin/man.cgi?section=9&topic=ksoftirqd)

Company Internal DESCRIPTION

Document number

8(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

3.4.4

watchdog watchdog is a software watchdog daemon. The Linux kernel can reset the system if serious problems are detected. This can be implemented via special watchdog hardware, or via a slightly less reliable software-only watchdog inside the kernel. Either way, there needs to be a daemon that tells the kernel the system is working fine. If the daemon stops doing that, the system is reset. watchdog is such a daemon. It opens /dev/watchdog, and keeps writing to it often enough to keep the kernel from resetting, at least once per minute. Each write delays the reboot time another minute. (ref man pages http://linux.die.net/man/8/watchdog)

3.4.5

events daemon handling an events queue <unknown>

3.4.6

khelper The khelper process is handling recovery images.

3.4.7

suspend <unknown>

3.4.8

kblockd Daemon handling work queue used by block devices

3.4.9

kmmcd kernel mmc daemon.

3.4.10

btaddconn Thread handling Bluetooth work queue additions.

3.4.11

btdelconn Thread handling Bluetooth work queue deletions.

Company Internal DESCRIPTION

Document number

9(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

3.4.12 3.4.13 3.4.14 3.4.15 3.4.16 3.4.17 3.4.18

kondemand qmi rpcrouter detection krpcserverd pdflush kswapd kswapd is the page swapper daemon responsible for swapping memory out to disk. It is normally sleeping but awakes when memory is running low. If the pressure is high, the process will free up memory synchronously, sometimes referred to as the direct-reclaim path. We do not have any swap in our embedded environment and one can reckon that the kswapd process is not necessary. However, kswapd still go through the memory pages and toss the ones that has not been used recently to free up memory. Note that swapping should not be confused with demand paging. Demand paging is when a code page is loaded only when it is needed. It is not swapped out to disk again. Also, demand paging is only used in user space i.e. no kernel code. See reference [5] for more information on Linux memory handling.

3.4.19

aio TBD

3.4.20

kadspd TBD

3.4.21

panel_on TBD

3.4.22

mtdblockd TBD

3.4.23

USB mass_storag TBD

3.4.24

synaptics_wq TBD

3.4.25

kstriped TBD

Company Internal DESCRIPTION

Document number

10(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

3.4.26

krfcommd TBD

3.4.27

mmcqd TBD

Process view
The process architecture takes into account some non-functional requirements, such as performance and availability. It addresses issues of concurrency and distribution, of systems integrity, of fault-tolerance, and how the main abstractions from the logical view fit within the process architectureon which thread of control is an operation for an object actually executed.
Architectural BlueprintsThe 4+1 View Model of Software Architecture

TBD

Development view
Subsystem decomposition The development architecture focuses on the actual software module organization on the software development environment. The software is packaged in small chunksprogram libraries, or subsystemsthat can be developed by one or a small number of developers. The subsystems are organized in a hierarchy of layers, each layer providing a narrow and well-defined interface to the layers above it.
Architectural BlueprintsThe 4+1 View Model of Software Architecture

Company Internal DESCRIPTION

Document number

11(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

Android consist of 5 software layers from Application on top and to Linux Kernel on bottom.

5.1

Application layer
Application layer is composed of phone applications email client, SMS, contacts, calendar, browser, and others. Those applications can be either Android standard applications or Google licensed applications or applications downloaded at Android market or others. All of them are written in Java Language.

5.2

Application framework layer

Android application framework provides reusable and common functionalities for applications. Those comprise Activities, Services, Broadcast receivers and Content providers. See [2] for more details.

5.3

Native services and library layer

Android includes a set of C/C++ libraries, for instance BSD-derived implementation of the standard C libraries (libc), browsing engine based on Webkit, SQLite relational database engine, and etc. Those libraries are compiled to ARM native code and are exposed to Java applications through Android application framework. (ref http://developer.android.com/guide/basics/what-is-android.html)

5.4

Android runtime
Android includes a set of core libraries which are available for Java applications.

Company Internal DESCRIPTION

Document number

12(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

Dalvik is the virtual machine and runs application code which has been converted to Dalvik Executable (.dex) which is not compatible to Java byte code. Unlike true Java VMs developed by Sun Microsystems, Dalvik is a register machine and it does not support just-in time compiler. (ref http://developer.android.com/guide/basics/what-is-android.html) (ref http://en.wikipedia.org/wiki/Dalvik_virtual_machine)

5.5

Linux kernel and Android modifications

Android relies on Linux version 2.6 for core system services such as security, memory management, process management, network stack, and driver model. In this section core Linux functionality is described along with the Android modifications. (ref http://developer.android.com/guide/basics/what-is-android.html)

5.5.1

Scheduling Below is a short description of the Linux kernel scheduler. There are many sources of information in this area so further reading is referred to those. (ref http://oreilly.com/catalog/linuxkernel/chapter/ch10.html) (ref http://sop4f.files.wordpress.com/2008/04/bab-1-3.pdf) Linux scheduling is based on the time-sharing technique where several processes are allowed to run "concurrently". This means that the CPU time is roughly divided into "slices," one for each runnable process. Of course, a single processor can run only one process at any given instant. If a currently running process is not terminated when its time slice or quantum expires, a process switch may take place. Time-sharing relies on timer interrupts and is thus transparent to processes. No additional code needs to be inserted in the programs in order to ensure CPU timesharing. The scheduling policy is also based on ranking processes according to their priority. Complicated algorithms are sometimes used to derive the current priority of a process, but the end result is the same: each process is associated with a value that denotes how appropriate it is to be assigned to the CPU. In Linux, process priority is dynamic. The scheduler keeps track of what processes are doing and adjusts their priorities periodically; in this way, processes that have been denied the use of the CPU for a long time interval are boosted by dynamically increasing their priority. Correspondingly, processes running for a long time are penalized by decreasing their priority. Processes are traditionally classified as "I/O-bound" or "CPU-bound." The former make heavy use of I/O devices and spend much time waiting for I/O operations to complete; the latter are number-crunching applications that require a lot of CPU time. Linux (like all Unix kernels) implicitly favors I/O-bound processes over CPUbound ones.

Company Internal DESCRIPTION

Document number

13(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

Some real-time operating systems feature a preemptive kernel, which means that a process running in Kernel Mode can be interrupted after any instruction, just as it can in User Mode. The Linux kernel is not preemptive, which means that a process can be preempted only while running in User Mode; nonpreemptive kernel design is much simpler, since most synchronization problems involving the kernel data structures are easily avoided. 5.5.1.1 SMP scheduling The Linux scheduler is modified in order to support the symmetric multiprocessor (SMP) architecture. Actually, each processor schedules on its own, but processors must exchange information in order to boost system performance. When the scheduler computes the goodness of a runnable process, it considers whether that process was previously running on the same CPU or on another one. A process that was running on the same CPU is always preferred, since the hardware cache of the CPU could still include useful data. This rule helps in reducing the number of cache misses. Let us suppose, however, that CPU 1 is running a process when a second, higherpriority process that was last running on CPU 2 becomes runnable. Now the kernel is faced with an interesting dilemma: should it immediately execute the higherpriority process on CPU 1, or should it defer that process's execution until CPU 2 becomes available? In the former case, hardware caches contents are discarded; in the latter case, parallelism of the SMP architecture may not be fully exploited when CPU 2 is running the idle process. In order to achieve good system performance, Linux/SMP adopts an empirical rule to solve the dilemma. The adopted choice is always a compromise, and the trade-off mainly depends on the size of the hardware caches integrated into each CPU: the larger the CPU cache is, the more convenient it is to keep a process bound on that CPU. A good introduction to SMP concepts can be found in [6]. 5.5.1.2 Android changes The Android kernel contains slight changes to the CPU process scheduler and timekeeping algorithms. It is not clear why this has been done. See reference [7] for more description of Android porting/changes to standard Linux. 5.5.2 Memory management To describe the Linux memory management a whole book would be required (see reference [5]). We will only scratch the surface of the memory management here. To understand more about Android memory management, refer to [12]. 5.5.3 Sharing memory (ashmem) Android has a specific implementation of sharing memory called ashmem. Ashmem stands for Anonymous Shared Memory and is an implementation of how to share memory between processes through named memory blocks. (ref kernel/mm/ashmem.c)

Company Internal DESCRIPTION

Document number

14(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

As an example, the system could use Ashmem to store icons, which multiple processes could then access when drawing their UI. The advantage of Ashmem over traditional Linux shared memory is that it provides a means for the kernel to reclaim these shared memory blocks if they are not currently in use. If a process then tries to access a shared memory block the kernel has freed, it will receive an error, and will then need to reallocate the block and reload the data. 5.5.4 Physically contiguous memory The pmem driver is used to manage large (1-16+MB) physically contiguous regions of memory shared between userspace and kernel drivers (dsp, gpu, etc). It was written specifically to deal with hardware limitations of the MSM7201A (dream/G1), but could be used for other chipsets as well. The pMEM driver is also used for some of the contiguous memory areas in U8500, e.g. graphics memory. (ref <kernel> /drivers/misc/pmem.c> (ref http://groups.google.com/group/androidkernel/browse_thread/thread/534e6e1115a43ca8) 5.5.5 Linux Out Of Memory killer The Linux kernel Out of Memory (OOM) killer is not usually invoked on desktop and server computers, because those environments contain sufficient resident memory and swap space, making the OOM condition a rare event. However, swapless embedded systems typically have little main memory and no swap space. In such systems, there is usually no need to allocate a big memory space; nevertheless, even relatively small allocations may eventually trigger the OOM killer. The process selection algorithm used by the kernel-based OOM killer was designed for desktop and server computer needs. Thus, it may not work properly on swapless embedded systems, because at any moment it can kill applications that a user may be interacting with. This was most likely the reason why the Google Android team decided to build the Android low memory killer. (ref http://www.linuxjournal.com/article/8502) 5.5.5.1 Low memory killer Based on hints from the userspace, the low memory killer can kill off processes to free up memory as necessary. It is designed to provide more flexibility than the Out Of Memory (OOM) killer in the standard kernel. [TO DO: check the reference can work] See reference [Error! Reference source not found.28], section Source Code Overview, for more information on this. 5.5.6 Power management Android supports its own Power Management (on top of the standard Linux Power Management) designed with the premise that the CPU shouldn't consume power if no applications or services require power.

Company Internal DESCRIPTION

Document number

15(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

Android requires that applications and services request CPU resources with "wake locks" through the Android application framework and native Linux libraries. If there are no active wake locks, Android will shut down the CPU. The image below illustrates the Android power management architecture.

[TO DO: check the reference can work] See reference [Error! Reference source not found.28] for more information on Android Power Management. 5.5.6.1 WakeLock Wakelock is a mechanism to force the device to be on or force it to awake. The wakelock is implemented in the <kernel>/power/wakelock.c and is exposed to the Java layer with the class android.os.PowerManager.WakeLock. It is possible to set different levels of locks. One can for example let the CPU continue to run while the screen is turned off or one can force the device not to enter sleep mode at all. Wake Locks are described in [8].

Company Internal DESCRIPTION

Document number

16(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

5.5.6.2

Linux power management The Linux Power Management is described in <kernel>/Documentation/power/pm.txt

5.5.7

Binder (Inter process calls) The IPC Binder is an Inter-Process Communication (IPC) mechanism. It allows processes to provide services to other processes via a set of higher-level APIs than are available in standard Linux. Information such as state, stats, transactions and logs from the binder can be read from Linux vfs /proc/binder. This is also somewhat described in [7].

5.5.8

Driver model The Linux Kernel Driver Model is a unification of all the disparate driver models that were previously used in the kernel. It is intended to augment the bus-specific drivers for bridges and devices by consolidating a set of data and operations into globally accessible data structures. Traditional driver models implemented some sort of treelike structure (sometimes just a list) for the devices they control. There wasn't any uniformity across the different bus types. The current driver model provides a common, uniform data model for describing a bus and the devices that can appear under the bus. The unified bus model includes a set of common attributes which all busses carry, and a set of common callbacks, such as device discovery during bus probing, bus shutdown, bus power management, etc. Below is an overview image of the driver model programming architecture.

Figure 2 Linux driver model. See coming chapters for an explanation of the different parts.

This is described in <kernel>/Documentation/driver-model and reference [9].

Company Internal DESCRIPTION

Document number

17(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

5.5.8.1

Bus The Bus type in the kernel is a programmatic representation of a real hardware bus for example i2c, mmc and sdio. The Bus type has references to many devices and drivers that are utilizing the bus.

5.5.8.2

Device The Device type is the programmatic representation of the physical component. It keeps a list of the buses and the device drivers which is associated with it.

5.5.8.3

Device driver The device driver is of course the code that actually controls the hardware device.

5.5.8.3.1

Sysfs When a driver is registered, a sysfs directory is created in its bus's directory. In this directory, the driver can export an interface to userspace to control operation of the driver on a global basis; e.g. toggling debugging output in the driver.

5.5.8.4

Device class The driver model in Linux classifies all devices in one of the three classes, character modules, block modules and network modules

5.5.8.4.1

Character modules Character modules are stream oriented devices such as a console (/dev/console) and serial ports (/dev/ttyS0.). They support commands such as read, write, open and close.

5.5.8.4.2

Block modules was historically (Unix) a device that could host a filesystem and where it was only possible to read and write whole blocks of data. The Linux implementation has deviated from the Unix original and it is now possible to transfer any number of bytes at any time. The only difference between the two now is how the data is handled internally in the driver and kernel. It is transparent to the user. Block devices are, like character devices, accessed through the file system (/dev/). Network interfaces All network communication is done through a network interface. These interfaces normally correspond to a hardware device (exception is e.g. the loopback interface, 127.0.0.1). They are different from the character and block devices since they have no natural place in the file system since they are not stream oriented (they handle packets). The kernel gives network interfaces names (such as eth0 or wlan0) and access them through functions related to packet transmission instead of read and write calls.

5.5.8.4.3

5.5.8.5

Device interface Device interfaces are the logical interfaces of device classes that correlate directly to userspace interfaces, like device nodes.

Company Internal DESCRIPTION

Document number

18(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

Each device class may have multiple interfaces through which you can access the same device. For example, an input device may support the mouse interface, the 'evdev' interface (generic input event interface), and the touchscreen interface.

5.5.8.6

User interface By virtue of having a complete hierarchical view of all the devices in the system, exporting a complete hierarchical view to userspace becomes relatively easy. This has been accomplished by implementing a special purpose virtual file system named sysfs. It is hence possible for the user to mount the whole sysfs filesystem anywhere in userspace. In Android Linux this is mounted at the default location of /sys. Listing the contents of this directory one can see the top level of the driver tree.

5.5.9

Bionic Small custom c-library tailored specifically for Android. Libs Libdl Libm Libstdc++ Libthread_db Linker

5.5.10

Arm specifics ARM specifics are described in <kernel>/Documentation/arm.

Company Internal DESCRIPTION

Document number

19(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

Physical view
The physical architecture takes into account primarily the non-functional requirements of the system such as availability, reliability (fault-tolerance), performance (throughput), and scalability. The software executes on a network of computers, or processing nodes (or just nodes for short). The various elements identified networks, processes, tasks, and objects need to be mapped onto the various nodes. We expect that several different physical configurations will be used: some for development and testing, others for the deployment of the system for various sites or for different customers. The mapping of the software to the nodes therefore needs to be highly flexible and have a minimal impact on the source code itself.
Architectural BlueprintsThe 4+1 View Model of Software Architecture

It is stated that the minimal hardware requirements for Android are 32MB of RAM, 32MB of Flash memory and 200MHz online-processor. However, the hardware requirements of course depends on the features to be implemented on the target phone and no commercial phones with such minimal hardware specifications are observed in the market as of writing this document. There are attempts to illustrate deployment of Android to the actual hardware within the company and here is one self-explanatory example. [10].

Key system use cases

System Level UCs such as System boot Application process start-up Application process termination Application installation System shutdown

7.1
7.1.1

System startup (boot)

Before Kernel starts When the power is turned on the BOOT ROM code starts and it then hands over to the boot loader which loads kernel code. See [TO DO] 2/1050-1/APX 901 358 for more
details on the boot before kernel code is loaded.

7.1.2

Kernel When the kernel is loaded, it immediately initializes and configures the hardware attached to the system, including all processors, I/O subsystems, and storage devices.

Company Internal DESCRIPTION

Document number

20(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

It then starts the first user-space application. This is the first program invoked that is compiled with the standard C library (in our case that is bionic). Prior to this point in the process, no standard C applications have been executed. In the Android Linux system, the first application (process) started is the init application (/init). A good description of the Linux boot process can be found in reference [11].

7.1.3

The init process The init process is the root parent of all other processes in the system. It starts with creating the kthreadd process which in turn will launch all kernel processes which runs in kernel space. The init process then parses the init.rc file (/etc/init.rc) which contains information of what should be created or initiated by the init process. This includes environment variables mount points file system directories and access rights property settings daemons to be started One special daemon that is started by init on the Android system is the Zygote process.

7.1.4

Zygote Zygote provides access to the Dalvik "zygote" feature, which allows a VM instance to be partially initialized and then fork()'d from the partially initialized state.

Company Internal DESCRIPTION

Document number

21(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

The Zygote launches the first actual Java process called system_server. The system_server that then starts the Android Java services. (ref http://developer.android.com/reference/dalvik/system/Zygote.html)

7.2

System shutdown
TBD

7.3

Application process start-up

When an application needs to run, Android spawns a Linux process with a single thread of execution by default. However, it is configurable how application components are wrapped in process and thread. For instance, all related components of the application run in single process and thread, or component elements - <activity>, <service>, <receiver> and <provider> - are given individual process per each. An application lifecycle is determined by the component lifecycle where transitions from state to state are defined and state changes are triggered by callback methods being called. (ref http://developer.android.com/guide/topics/fundamentals.html)

7.4

Application process termination

An application process is maintained as long as possible by Android even though the phone user leaves the application and starts up something else. However, the process is terminated eventually when memory runs out. Processes of the lowest importance are terminated first and the order of importance is defined according to the nature of process, for instance foreground process or empty process. (ref http://developer.android.com/guide/topics/fundamentals.html#proclife)

7.5

Company Internal DESCRIPTION

Document number

22(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

Licensing overview
Below is an overview of the license model of the Android system. Most of the software stack is licensed according to the Apache 2 license. The native libraries are collected work from different sources and follow many different license models. The Apache 2 license parts within the kernel are made by Google and are therefore licensed according to Apache 2.

The Special box in the picture above special cases of the existing license models e.g. License based on a open source license but is modified or restricted Several licenses applies and the user can select which one to use Note that this license analysis is based on a standard Android cupcake release and it may be different from a QCT release. A more detailed analysis is found in reference [Error! Reference source not found.3].

Company Internal DESCRIPTION

Document number

23(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

9
9.1

File System
Mounts and partitions
The figure below shows the structure of the standard Android partitions

Cache

/data

etc

/sbin

/proc

/sys

/dev

/system

/sdcard

app

data

app

bin

etc

frame work

lib

usr

xbin

*.apk

<app>

*.apk

databases

<app>.db

Cache partition

Root system, config, VFS Preinstalled system partition User data on SD card

Data partition, cleared during system factory reset

Figure 3 Device file system. All user and runtime changed data is consolidated under /data System apps are stored under /system/app New apps stored as original *.apk under /data/app Applications are storing data under /data/data Factory reset wipes /data USB mass storage mounts to /sdcard no internal partitions are exposed via USB user media is only stored on SD card. /system stores the actual Android system. It is written at the factory (or by OTA updates), mounted read-only, and never modified during normal operation. /data, which stores the user's data: email, calendar, preferences, contacts, etc. Empty when the device first boots, written by the system and applications. Each application gets a subdirectory (/data/data/app.package.name) to use which is rwx for the application only (rwx------). /cache, which is reserved by the system as temporary storage for downloads, and to buffer OTA updates (in standard Android OTA solution). Applications don't get to write directly to /cache.

Company Internal DESCRIPTION

Document number

24(25)
Revision

1/1050-LXE 110 1442 Uen

PA4

The /system, /data and /cache partitions are the basic Unix filesystem on the device, using the YAFFS2 filesystem. The actual root directory, /tmp, /dev, /etc. are stored on a ramdisk, which is reinitialized at every boot (and not writable by applications in any case). Android implementations should also include a separate file system for user media (photos,videos, music, documents), which is typically implemented with a micro-SD card, which is mounted on /sdcard if present, using the FAT file system for compatibility with external systems. This partition can be configured (in system settings UI) as a sharable drive exposed over USB Mass Storage. If an application is writing data, it is probably writing to /data or /sdcard Google plan to add a possibility to store downloaded apps on the SD card (starting with FroYo) but t is not known yet what that solution will look like.

Company Internal DESCRIPTION

Document number

25(25)
Revision

1/1050-LXE 110 1442 Uen

PA4