Android Sw RAJ

7/30/2019 Android Sw RAJ

1/25

Company InternalDESCRIPTION

1(25)

Document number Revision

1/1050-LXE 110 1442 Uen PA4Prepared by Date

SEM/CTFCB CARL SJSTRM 2010-04-21Contents responsible if other than preparer Remarks

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

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 isthe 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.

1 Introduction

1.1 Abstract

1.2 Content

1.3 Scope

1.4 Audience

1.5 Reference

1 Guidelines: Software Architecture Document

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

2 Application components

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

3 Android telephony architecture

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

4 U8500 Linux Modem adaptation software architecture,15/15935-3/FCP1190935

5 Linux Memory management,http://www.informit.com/content/images/0131453483/downloads/gorman_book.pdf

6 An introduction to embedded multicore,http://www.freescale.com/files/32bit/doc/ref_manual/EMBMCRM.pdf

7 Android Porting:http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Porting-Android-to-a-new-device/,http://pdk.android.com

8 Wake Locks,http://developer.android.com/reference/android/os/PowerManager.WakeLock.html

9 Linux Driver model,http://lwn.net/Kernel/LDD3/

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/1597-LXE108005&rev=latest
http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/modguide/md_sad.htm#Contentshttp://www.ts.mah.se/RUP/RationalUnifiedProcess/process/modguide/md_sad.htm#Contentshttp://developer.android.com/guide/topics/fundamentals.html#appcomphttp://developer.android.com/guide/topics/fundamentals.html#appcomphttp://www.netmite.com/android/mydroid/development/pdk/docs/telephony.htmlhttp://www.netmite.com/android/mydroid/development/pdk/docs/telephony.htmlhttp://metadoc.sonyericsson.net/login_link.asp?doc=15/15935-3/FCP1190935&rev=latesthttp://metadoc.sonyericsson.net/login_link.asp?doc=15/15935-3/FCP1190935&rev=latesthttp://metadoc.sonyericsson.net/login_link.asp?doc=15/15935-3/FCP1190935&rev=latesthttp://www.informit.com/content/images/0131453483/downloads/gorman_book.pdfhttp://www.informit.com/content/images/0131453483/downloads/gorman_book.pdfhttp://www.freescale.com/files/32bit/doc/ref_manual/EMBMCRM.pdfhttp://www.freescale.com/files/32bit/doc/ref_manual/EMBMCRM.pdfhttp://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Porting-Android-to-a-new-device/http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Porting-Android-to-a-new-device/http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Porting-Android-to-a-new-device/http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Porting-Android-to-a-new-device/http://pdk.android.com/http://pdk.android.com/http://pdk.android.com/http://developer.android.com/reference/android/os/PowerManager.WakeLock.htmlhttp://developer.android.com/reference/android/os/PowerManager.WakeLock.htmlhttp://developer.android.com/reference/android/os/PowerManager.WakeLock.htmlhttp://lwn.net/Kernel/LDD3/http://lwn.net/Kernel/LDD3/http://lwn.net/Kernel/LDD3/http://metadoc.sonyericsson.net/login_link.asp?doc=1/1050-1/FCP1190794&rev=latesthttp://metadoc.sonyericsson.net/login_link.asp?doc=1/1050-1/FCP1190794&rev=latesthttp://www.ibm.com/developerworks/library/l-linuxboot/index.htmlhttp://www.ibm.com/developerworks/library/l-linuxboot/index.htmlhttp://www.ibm.com/developerworks/library/l-linuxboot/index.htmlhttp://metadoc.sonyericsson.net/login_link.asp?doc=12/1597-LXE108005&rev=latesthttp://metadoc.sonyericsson.net/login_link.asp?doc=12/1597-LXE108005&rev=latesthttp://metadoc.sonyericsson.net/login_link.asp?doc=12/1597-LXE108005&rev=latesthttp://metadoc.sonyericsson.net/login_link.asp?doc=12/1597-LXE108005&rev=latesthttp://metadoc.sonyericsson.net/login_link.asp?doc=12/1597-LXE108005&rev=latesthttp://metadoc.sonyericsson.net/login_link.asp?doc=12/1597-LXE108005&rev=latesthttp://www.ibm.com/developerworks/library/l-linuxboot/index.htmlhttp://metadoc.sonyericsson.net/login_link.asp?doc=1/1050-1/FCP1190794&rev=latesthttp://lwn.net/Kernel/LDD3/http://developer.android.com/reference/android/os/PowerManager.WakeLock.htmlhttp://pdk.android.com/http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Porting-Android-to-a-new-device/http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Porting-Android-to-a-new-device/http://www.freescale.com/files/32bit/doc/ref_manual/EMBMCRM.pdfhttp://www.informit.com/content/images/0131453483/downloads/gorman_book.pdfhttp://metadoc.sonyericsson.net/login_link.asp?doc=15/15935-3/FCP1190935&rev=latesthttp://www.netmite.com/android/mydroid/development/pdk/docs/telephony.htmlhttp://developer.android.com/guide/topics/fundamentals.html#appcomphttp://www.ts.mah.se/RUP/RationalUnifiedProcess/process/modguide/md_sad.htm#Contents


2/25


2(25)


1/1050-LXE 110 1442 Uen PA4

1.6 Terms and Abbreviation

2 Android Software Architecture

3 Logical view

The logical architecture primarily supports the functional requirementswhat thesystem should provide in terms of services to its users. The system isdecomposed into a set of key abstractions, taken (mostly) from the problemdomain, in the form of objects or object classes. They exploit the principles ofabstraction, encapsulation, and inheritance. This decomposition is not only forthe sake of functional analysis, but also serves to identify common mechanismsand 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 entiresystem in terms of objects or classes is not feasible for this document. This chapterwill therefore restrict the logical view description of the platform to a list ofapplications with brief descriptions: the Android standard applications and thedifferentiating applications that Sony Ericsson adds to the platform. Even in this veryhigh level there are certain uncertainties it is simply not decided which applicationsthat will be supported on this platform and the Android applications development isgoing on continuously.

Android have the slogan All apps are equal which is a big difference compared towhat one might be used to from previous mobile phone systems. This means that allapplications have the same rights and that all applications can be exchanged. Eventhough it is possible to prevent the user from deleting certain applications, it isalways possible to install a new application beside the original one and therebychange 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 bedownloaded and used instead of the pre-installed home screen.

3.1 Process overview

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


3/25


3(25)


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 orcustomized.

AlarmClock

Browser

Calculator

Calendar

Camera

Contacts

Email

GoogleSearch

HTMLViewer

IM


4/25


4(25)


1/1050-LXE 110 1442 Uen PA4

Launcher

Mms

MusicPackageInstaller

Phone

Settings

SoundRecorder

Stk

Sync

Updater

VoiceDialer


5/25


6/25


6(25)


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 ispossible 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. (refhardware/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 telephonyservices (android.telephony classes) and the radio hardware. The diagram belowillustrates 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 adescription of how this is integrated in the U8500 architecture.


7/25


7(25)


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 thebluetooth 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 thebluetooth headset profile (more accurately Headset Audio Gateway profile). (refLinux 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 /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 animage 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, linuxkernel 2.6.27 on an ADP1). These are kernel processes and spawned by thekthreadd 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 initprocess.

3.4.3 ksoftirqd

This is the softirq daemon. ksoftirqd is a per-cpu kernel thread that runs when themachine is under heavy soft-interrupt load. Soft interrupts are normally servicedon return from a hard interrupt, but it's possible for soft interrupts to be triggeredmore quickly than they can be serviced. If a soft interrupt is triggered for asecond time while soft interrupts are being handled, the ksoftirq daemon istriggered to handle the soft interrupts in process context. If ksoftirqd is takingmore than a tiny percentage of CPU time, this indicates the machine is under heavysoft interrupt load.

(ref Linux programmers manualhttp://www.tin.org/bin/man.cgi?section=9&topic=ksoftirqd)


8/25


8(25)


1/1050-LXE 110 1442 Uen PA4

3.4.4 watchdog

watchdog is a software watchdog daemon. The Linux kernel can reset the system ifserious problems are detected. This can be implemented via special watchdoghardware, 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 workingfine. If the daemon stops doing that, the system is reset.

watchdog is such a daemon. It opens /dev/watchdog, and keeps writing to it oftenenough to keep the kernel from resetting, at least once per minute. Each writedelays the reboot time another minute.

(ref man pages http://linux.die.net/man/8/watchdog)

3.4.5 events

daemon handling an events queue

3.4.6 khelper

The khelper process is handling recovery images.

3.4.7 suspend

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.


9/25


9(25)


1/1050-LXE 110 1442 Uen PA4

3.4.12 kondemand

3.4.13 qmi

3.4.14 rpcrouter

3.4.15 detection

3.4.16 krpcserverd

3.4.17 pdflush

3.4.18 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 ishigh, the process will free up memory synchronously, sometimes referred to as thedirect-reclaim path.

We do not have any swap in our embedded environment and one can reckon thatthe kswapd process is not necessary. However, kswapd still go through the memorypages 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 iswhen a code page is loaded only when it is needed. It is not swapped out to diskagain. 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


10/25


10(25)


1/1050-LXE 110 1442 Uen PA4

3.4.26 krfcommd

TBD

3.4.27 mmcqd

TBD

4 Process view

The process architecture takes into account some non-functional requirements,such as performance and availability. It addresses issues of concurrency anddistribution, of systems integrity, of fault-tolerance, and how the main abstractionsfrom the logical view fit within the process architectureon which thread of control isan operation for an object actually executed.


TBD

5 Development view

Subsystem decomposi t ion

The development architecture focuses on the actual software module organizationon the software development environment. The software is packaged in smallchunksprogram libraries, or subsystemsthat can be developed by one or asmall 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.



11/25


11(25)


1/1050-LXE 110 1442 Uen PA4

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

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 licensedapplications or applications downloaded at Android market or others. All of them arewritten in Java Language.

5.2 Application framework layer

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

5.3 Native services and library layer

Android includes a set of C/C++ libraries, for instance BSD-derived implementationof the standard C libraries (libc), browsing engine based on Webkit, SQLiterelational database engine, and etc.

Those libraries are compiled to ARM native code and are exposed to Javaapplications through Android application framework.

(ref http://developer.android.com/guide/basics/what-is-android.html)

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


12/25


12(25)


1/1050-LXE 110 1442 Uen PA4

Dalvik is the virtual machine and runs application code which has been converted toDalvik Executable (.dex) which is not compatible to Java byte code.

Unlike true Java VMs developed by Sun Microsystems, Dalvik is a register machineand it does not support just-in time compiler.


(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. Inthis section core Linux functionality is described along with the Androidmodifications.


5.5.1 Scheduling

Below is a short description of the Linux kernel scheduler. There are many sourcesof 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-sharingtechnique where several processesare allowed to run "concurrently". This means that the CPU time is roughly dividedinto "slices," one for each runnable process. Of course, a single processor can runonly one process at any given instant. If a currently running process is notterminated when its time slice orquantum expires, a process switch may take place.Time-sharing relies on timer interrupts and is thus transparent to processes. Noadditional code needs to be inserted in the programs in order to ensure CPU time-sharing.

The scheduling policy is also based on ranking processes according to their priority.Complicated algorithms are sometimes used to derive the current priority of aprocess, 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 processesare doing and adjusts their priorities periodically; in this way, processes that havebeen denied the use of the CPU for a long time interval are boosted by dynamicallyincreasing their priority. Correspondingly, processes running for a long time arepenalized by decreasing their priority.

Processes are traditionally classified as "I/O-bound" or "CPU-bound." The formermake heavy use of I/O devices and spend much time waiting for I/O operations tocomplete; the latter are number-crunching applications that require a lot of CPUtime. Linux (like all Unix kernels) implicitly favors I/O-bound processes over CPU-

bound ones.


13/25


13(25)


1/1050-LXE 110 1442 Uen PA4

Some real-time operating systems feature a preemptive kernel, which means that aprocess running in Kernel Mode can be interrupted after any instruction, just as itcan in User Mode. The Linux kernel is not preemptive, which means that aprocess can be preempted only while running in User Mode; nonpreemptive kerneldesign is much simpler, since most synchronization problems involving the kerneldata 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 processorsmust exchange information in order to boost system performance.

When the scheduler computes the goodness of a runnable process, it considerswhether that process was previously running on the same CPU or on another one. Aprocess 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 thenumber of cache misses.

Let us suppose, however, that CPU 1 is running a process when a second, higher-priority process that was last running on CPU 2 becomes runnable. Now the kernelis faced with an interesting dilemma: should it immediately execute the higher-priority process on CPU 1, or should it defer that process's execution until CPU 2becomes available? In the former case, hardware caches contents are discarded; inthe latter case, parallelism of the SMP architecture may not be fully exploited whenCPU 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-offmainly depends on the size of the hardware caches integrated into each CPU: thelarger the CPU cache is, the more convenient it is to keep a process bound on thatCPU.

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 time-keeping 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 (seereference [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 sharememory between processes through named memory blocks.

(ref kernel/mm/ashmem.c)


14/25


14(25)


1/1050-LXE 110 1442 Uen PA4

As an example, the system could use Ashmem to store icons, which multipleprocesses could then access when drawing their UI. The advantage of Ashmemover traditional Linux shared memory is that it provides a means for the kernel toreclaim these shared memory blocks if they are not currently in use. If a processthen tries to access a shared memory block the kernel has freed, it will receive anerror, 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 contiguousregions of memory shared between userspace and kernel drivers (dsp, gpu,etc). It was written specifically to deal with hardware limitations ofthe 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 /drivers/misc/pmem.c>

(refhttp://groups.google.com/group/android-kernel/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 andserver computers, because those environments contain sufficient resident memoryand swap space, making the OOM condition a rare event. However, swaplessembedded 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 designedfor desktop and server computer needs. Thus, it may not work properly on swaplessembedded systems, because at any moment it can kill applications that a user maybe interacting with.

This was most likely the reason why the Google Android team decided to build theAndroid low memory killer.

(refhttp://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 tofree up memory as necessary. It is designed to provide more flexibility than the OutOf Memory (OOM) killer in the standard kernel.

[TO DO: check the reference can work] See reference [Error! Reference sourcenot 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 PowerManagement) designed with the premise that the CPU shouldn't consume power ifno applications or services require power.
http://groups.google.com/group/android-kernel/browse_thread/thread/534e6e1115a43ca8http://groups.google.com/group/android-kernel/browse_thread/thread/534e6e1115a43ca8http://groups.google.com/group/android-kernel/browse_thread/thread/534e6e1115a43ca8http://groups.google.com/group/android-kernel/browse_thread/thread/534e6e1115a43ca8http://www.linuxjournal.com/article/8502http://www.linuxjournal.com/article/8502http://www.linuxjournal.com/article/8502http://www.linuxjournal.com/article/8502http://groups.google.com/group/android-kernel/browse_thread/thread/534e6e1115a43ca8http://groups.google.com/group/android-kernel/browse_thread/thread/534e6e1115a43ca8


15/25


15(25)


1/1050-LXE 110 1442 Uen PA4

Android requires that applications and services request CPU resources with "wakelocks" through the Android application framework and native Linux libraries. If thereare 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 sourcenot 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. Thewakelock is implemented in the /power/wakelock.c and is exposed to theJava layer with the class android.os.PowerManager.WakeLock.

It is possible to set different levels of locks. One can for example let the CPUcontinue to run while the screen is turned off or one can force the device not to entersleep mode at all.

Wake Locks are described in [8].


16/25


16(25)


1/1050-LXE 110 1442 Uen PA4

5.5.6.2 Linux power management

The Linux Power Management is described in/Documentation/power/pm.txt

5.5.7 Binder (Inter process calls)

The IPC Binder is an Inter-Process Communication (IPC) mechanism. It allowsprocesses to provide services to other processes via a set of higher-level APIs thanare available in standard Linux.

Information such as state, stats, transactions and logs from the binder can be readfrom 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 thatwere previously used in the kernel. It is intended to augment the bus-specific driversfor bridges and devices by consolidating a set of data and operations into globallyaccessible data structures. Traditional driver models implemented some sort of tree-like structure (sometimes just a list) for the devices they control. There wasn't anyuniformity across the different bus types.

The current driver model provides a common, uniform data model for describing abus and the devices that can appear under the bus. The unified bus model includesa set of common attributes which all busses carry, and a set of common callbacks,such as device discovery during bus probing, bus shutdown, bus powermanagement, 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 /Documentation/driver-modeland reference [9].


17/25


17(25)


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 hardwarebus for example i2c, mmc and sdio. The Bus type has references to many devicesand drivers that are utilizing the bus.

5.5.8.2 Device

The Device type is the programmatic representation of the physical component. Itkeeps 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 thisdirectory, the driver can export an interface to userspace to control operation of thedriver 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, charactermodules, 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, openand close.

5.5.8.4.2 Block modules was historically (Unix) a device that could host a filesystem andwhere it was only possible to read and write whole blocks of data. The Linuximplementation has deviated from the Unix original and it is now possible to transferany number of bytes at any time. The only difference between the two now is howthe 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/).

5.5.8.4.3 Network interfacesAll network communication is done through a network interface. These interfacesnormally 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 haveno natural place in the file system since they are not stream oriented (they handlepackets). The kernel gives network interfaces names (such as eth0 or wlan0) andaccess them through functions related to packet transmission instead of read andwrite calls.

5.5.8.5 Device interface

Device interfaces are the logical interfaces of device classes that correlate directly touserspace interfaces, like device nodes.


18/25


18(25)


1/1050-LXE 110 1442 Uen PA4

Each device class may have multiple interfaces through which you can access thesame 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. Thishas been accomplished by implementing a special purpose virtual file systemnamed sysfs. It is hence possible for the user to mount the whole sysfs filesystemanywhere in userspace.

In Android Linux this is mounted at the default location of /sys. Listing the contentsof 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 /Documentation/arm.


19/25


20/25


20(25)


1/1050-LXE 110 1442 Uen PA4

It then starts the first user-space application. This is the first program invoked that iscompiled with the standard C library (in our case that is bionic). Prior to this point inthe process, no standard C applications have been executed.

In the Android Linux system, the first application (process) started is the initapplication (/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 withcreating the kthreadd process which in turn will launch all kernel processes whichruns in kernel space.

The init process then parses the init.rc file (/etc/init.rc) which containsinformation 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 Zygoteprocess.

7.1.4 Zygote

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


21/25


21(25)


1/1050-LXE 110 1442 Uen PA4

The Zygote launches the first actual Java process called system_server. Thesystem_server that then starts the Android Java services.

(refhttp://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 singlethread of execution by default. However, it is configurable how applicationcomponents are wrapped in process and thread. For instance, all relatedcomponents of the application run in single process and thread, or componentelements - , , and - are given individual

process per each.

An application lifecycle is determined by the component lifecycle where transitionsfrom state to state are defined and state changes are triggered by callback methodsbeing called.

(refhttp://developer.android.com/guide/topics/fundamentals.html)

7.4 Application process termination

An application process is maintained as long as possible by Android even thoughthe phone user leaves the application and starts up something else. However, the

process is terminated eventually when memory runs out. Processes of the lowestimportance are terminated first and the order of importance is defined according tothe nature of process, for instance foreground process or empty process.

(refhttp://developer.android.com/guide/topics/fundamentals.html#proclife)

7.5
http://developer.android.com/reference/dalvik/system/Zygote.htmlhttp://developer.android.com/reference/dalvik/system/Zygote.htmlhttp://developer.android.com/reference/dalvik/system/Zygote.htmlhttp://developer.android.com/guide/topics/fundamentals.htmlhttp://developer.android.com/guide/topics/fundamentals.htmlhttp://developer.android.com/guide/topics/fundamentals.htmlhttp://developer.android.com/guide/topics/fundamentals.html#proclifehttp://developer.android.com/guide/topics/fundamentals.html#proclifehttp://developer.android.com/guide/topics/fundamentals.html#proclifehttp://developer.android.com/guide/topics/fundamentals.html#proclifehttp://developer.android.com/guide/topics/fundamentals.htmlhttp://developer.android.com/reference/dalvik/system/Zygote.html


22/25


22(25)


1/1050-LXE 110 1442 Uen PA4

8 Licensing overview

Below is an overview of the license model of the Android system. Most of thesoftware 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 thereforelicensed according to Apache 2.

The Special box in the picture above special cases of the existing license modelse.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 andit may be different from a QCT release.

A more detailed analysis is found in reference [Error! Reference source not

found.3].


23/25


23(25)


1/1050-LXE 110 1442 Uen PA4

9 File System

9.1 Mounts and partitions

The figure below shows the structure of the standard Android partitions

/

Cache etc /sbin /proc /sys /dev/data /sdcard/system

usrappdataapp

User data on SD cardPreinstalled system partition

Cache partition

Data partition, cleared during system factory reset

Root system, config, VFS

bin libetc xbinframe

work

*.apk*.apk

databases

.db

Figure 3 Device file system.

All user and runtime changed data is consolidated under /dataSystem apps are stored under /system/appNew apps stored as original *.apk under /data/appApplications are storing data under /data/dataFactory reset wipes /dataUSB mass storage mounts to /sdcardno internal partitions are exposed via USBuser 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 normaloperation.

/data, which stores the user's data: email, calendar, preferences,contacts, etc. Empty when the device first boots, written by the system andapplications. Each application gets a subdirectory (/data/data/app.package.name) touse which is rwx for the application only (rwx------).

/cache, which is reserved by the system as temporary storage for downloads, and tobuffer OTA updates (in standard Android OTA solution). Applications don't get to

write directly to /cache.


24/25


24(25)


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 storedon a ramdisk, which is reinitialized at every boot (and not writable by applications inany case).Android implementations should also include a separate file system for user media(photos,videos, music, documents), which is typically implemented with a micro-SDcard, which is mounted on /sdcard if present, using the FAT file system forcompatibility with external systems. This partition can be configured (in systemsettings 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 (startingwith FroYo) but t is not known yet what that solution will look like.


25/25


25(25)


1/1050-LXE 110 1442 Uen PA4

Documents

Android Sw RAJ