Porting the Android Platform Beyond Mobile Phone Applications

8/8/2019 Porting the Android Platform Beyond Mobile Phone Applications

1/16

e m b e d d e d s f w a e W

h

i

t

e

P

a

P

e

r

w w w . m e n t o r . c o m

p e add plafm

beyd mble pe applcas

Vlad buzV, se sfwae acec, me apcs


2/16


3/16

porting th anroi ptor bon moi phon aition

.ntor.o3

Application Framework

Applications

e lux keel

figr 1 shows how the Linux kernel is a fundamental part of Android architecture. It provides low-level operatingsystem functions to facilitate user applications needs. It includes process management, memory management,basic inter-process communication (IPC) methods, security mechanisms, network connectivity, and vast array ofdevice drivers.

For each of the Android releases, Google tends to pick up the most recent Linux kernel version, which is extendedwith additional features required to run the Android framework. In general, the modifications are implemented bya series of over one hundred patches which implement:

Android Power Management

Android Debug Bridge USB device

Android out-of-memory killer

New IPC methods:

Binder

Android Shared Memory (Ashmem)

The security mechanisms provided by the Linux kernel, such as user and group permissions to system resources(file system), are extensively used by the Android Framework to protect core system data and functions fromapplications running in the system. Android out-of-memory killer is intended to prevent out of memory situationscaused by an application, which could impact the overall system. New IPC methods are underlying mechanisms forhigh-level IPC implemented within the Android Framework for Android applications interaction. (IPC will bediscussed later in this paper. )

Figure 1: The Linux kernel.


4/16


.ntor.o4

lbaes

The next layer on top of the Linux kernel is the Android C library and other system libraries (figr 2), whichimplement core functions used by Android Framework and applications. Unlike Linux OS, which is based on GNU Clibrary, Google developed its own version of C library called Bionic. It is derived from various flavors of BSD OS. TheBionic libc provides only those functions, which are used by other Android libraries and applications. This makes it

inflexible for integrating software built for GNU environment.

Android does not use any GNU tools in runtime. Rather, it provides its own version of dynamic linker loader tosupport dynamically linked shard libraries as part of Bionic libc.

Other examples of key libraries include:

Multimedia libraries for audio and video

Graphics libraries

SQLite embedded database for applications data storage and sharing

WebKit for Internet HTML pages rendering with JavaScript engine

OpenSSL for secure communications

Figure 2: Libraries.


5/16


.ntor.o5

add ume

Android runtime is the most critical part of the Android OS (figr 3). Android is designed for straight-forwardsoftware reuse, which could be difficult to achieve if the Android Framework was implemented in C/C++ andre-compiled natively for each of the hardware platforms. In fact, all of the Android application framework andapplications are written in Java and run inside of the Google Dalvik virtual machine (DalvikVM).

The key distinguishing fact is that DalvikVM is not an Oracle Java VM. It implements its own register-based virtualarchitecture, as opposed to stack-based JavaVM, and executes its own byte code (DEX).

The way in which this works is all Java programs are converted to JavaVM byte code by the standard Oracle Javalanguage tools and then converted to a DalvikVM byte code with a special DEX compiler provided by Android.This allows the developer to remain compatible with Java language when adopting existent Java applications.

Unlike the Oracle JavaVM which is designed to work on top of different operating systems, the DalvikVM is tied tothe Linux kernel and directly uses interfaces provided by the Linux kernel and Bionic. For example, it relies on thepthreads library to implement threading in Java programs. Each Android application is executed by a separateinstance of the Java machine and communicates with the Android Framework and other applications using IPC.

DalvikVM implements the Java Native Interface (JNI) bridge for Java programs in order to call methodsimplemented in natively compiled libraries.

Figure 3: Android Runtime and the Dalvik VM.


6/16


.ntor.o6

applca famewk

The Android Application Framework(figr 4) is a Java-based set of services and systems supporting AndroidApplications. Some services are intended to manage applications in Android (Package Manager, Activity Manager,Window Manager) while others provide access to system functions and resources (Notification Manager, PowerManager). On top of that, the framework provides hundreds of APIs and standard Java libraries for application

development.

The Application Framework defines two types of applications: Activities and Services. Both manage applicationlifecycles in a system. An Activity is always associated with user interaction, while a Service is typically abackground process. There can be only one Activity running in a system at a given time the one the user selects.An Activity is an entry point to an application that could implement multiple Activities and Services. One Activitycould call other Activities that will stack on top of each other forming a Task. Thus, an Android Framework taskcould actually be formed by Activities belonging to different application packages and Linux processes.

An application user interface is represented by a ViewGroup and View objects, associated with an application. AView represents a user interface object, while a ViewGroup defines a user interface layout. A Window Managersystem service controls applications Views.

The Android Application Framework implements high-level IPC mechanisms Intents and Android InterfaceDefinition Language (AIDL). Intents look like one way messages used to launch Activities, Services, or broadcastevents to a system. AIDL is an Android Remote Procedure Call (RPC) mechanism that allows Services (application orsystem) to publish their capabilities for other applications. AIDL defines a meta-language to define an interface ofserver and client, which then gets compiled to stub Java classes. AIDL is based on Binder IPC that also allowscalling Services from outside of the Java-based framework.

Figure 4: The Android Application Framework.


7/16


.ntor.o7

applcas

Android Applications (figr 5) comprise a package (.apk) that includes application DalvikVM byte code andmetadata handled by the framework system services, such as Package Manager or Activity Manager. Metadataincludes all the necessary information to manage an application within the system such as list of Activities,Services, application entry point, user interface layout, and so on.

Android Applications work on top of the Application Framework APIs. Each application is represented by anActivity or a Service that runs in a separate instance of the DalvikVM and requests system services via AIDL/BinderIPC mechanisms.

All applications are Java programs. However, they may make use of native shared libraries via DalvikVM JNI bridge.

An application can implement a service and expose it for other applications. A good example of this is a phoneapplication that provides a Bluetooth handset profile service to control Bluetooth headsets. A phone application isone of the default applications set by Google, as well as SMS, Contacts, Calendar, Web Browser, and Email.

Android Applications also provides additional security mechanisms to protect core system services and applications.

It defines certain permission and/or permission groups and application needs in order to do certain things, such asmaking a phone call, accessing contacts information, etc. An Activity or Service can request specific permissionsand may require certain permissions to get accessed. Only if a calling application has the required permissions canit launch a specific Activity or bind to a specific Service.

Figure 5: Applications.


8/16


.ntor.o8

add deVelpme

The Android OS is distributed as a complete code base along with necessary configuration files and build scriptsto build and deploy the Android images on a real hardware device or emulator. The Android build system is notself-sufficient. Unlike the Android runtime environment, the build system relies on existing external tools such asGNU tool chain, GNU make, and Oracle Java SDK 1.5. The Android build system does not require a complete GNUtool chain since it does not depend on GNU libc.

The Android build system has a modular structure. It defines a common set of rules to build software packagesof various types such as native library or executable, Android framework library, or an Android application. Eachof the software packages has an associated Android.mk file that includes generic rules and provides necessaryinformation to build a module such as module source files, dependencies, type, and so on.

The build system is required to build the Android Framework and all software packages essential for systemfunctions. However, its not needed to develop external components, such as an Android application. One ofthe build system outputs is the Android Software Development Kit (SDK).

The Android SDK is a subset of the build system with pre-built components and tools required to develop Android

applications in Java. It provides nice debugging capabilities by utilizing the Android Debug Bridge (ADB) to com-municate with an Android device over USB or TCP/IP connection. The ADB allows for the collecting of device logs,accessing the Android shell, and installing and debugging applications. To facilitate the application developmentprocess, the SDK also provides a virtual QEMU-based target.

All SDK features are consolidated into an Eclipse-based Integrated Development Environment (IDE), which is anEclipse Android Development Tools (ADT) plug-in.

In some cases, its preferable to implement a part of an application as a shared library. For example, to achievebetter application performance or avoid porting an existing code to Java. The Android Native Development Kit(NDK) facilitates this process by providing a set of command line tools and prebuilt libraries.

add famewk deVelpmeThe Android source base, and in turn, its build system are managed with a mixture of existing open source toolsand tools developed and provided by Google. To keep the Android source code, Google utilizes an open sourcesoftware revisions control system git . Each of the Android software modules are kept in a dedicated git tree. Tomanage multiple git trees, Google provides a command line repo tool. The repo tool requires a XML manifest filethat describes what Android modules need to be checked out and their revisions.

Once checked out, a repo tool can track the changes introduced to different Android software modules andprepare them for submission to an Android code review and tracking system gerrit.

The Android code review process is based on multiple roles such as Author, Approver, and Verifier. It is performedusing the gerrit tool, which has a Web interface to track and review changes and is linked to the Android projectgit trees to apply the changes once approved.

add applcas deVelpme

Applications are developed outside of the build system using the Android SDK and NDK. Normally a developer willuse an Eclipse ADT. Its important to remember that all Android applications are actually Java programs developedwith standard Java tools. The complete Android API and Java libraries are available to develop applications.


9/16


.ntor.o9

The Eclipse ADT will set up a new Android project, assist to create an application user interface, build an applicationpackage (.apk), and deploy it on a virtual or real hardware target using ADB.

Sometimes a developer will make a decision to implement a portion of an application as a natively compiledlibrary. The Android NDK provides all the necessary tools to build a shared library, but its not integrated into the

Eclipse IDE. The library is separately installed to the Android target device and can be linked and accessed in run-time from Java code using DalvikVM JNI bridge.

accelea embedded deVelpme w add

The Android OS platform has been growing so fast that more companies and individuals are getting involved indevelopment and submitting their changes back to the Android project, which helps Google define the futuredirection of Android. The fact that Android is licensed under permissive open source licenses makes it attractivefor commercial vendors since it reduces risk of releasing proprietary software and sharing secrets.

Since its first commercial release (Cupcake), the Android platform has become a dominate mobile softwareplatform in the United States. But Android has found its way into non-handset devices as well and is nowimplemented by industrial-grade suppliers to deliver next generation products.

From a technical perspective, the Android OS is a complete application framework on top of the well-known Linuxkernel that supports many different architecture and processors. It has sophisticated functionality and providesnumerous capabilities to develop interactive user applications with attractive user interfaces such as games,Internet services, media players, and so on.

The key feature of the Android design is that its based on Java and gets converted to a machine independent bytecode thats simply re-used without explicit porting to any of the devices running Android. Therefore, the amount offoundation work required to build a product platform based on the Android OS is significantly less compared tomigrating and building a platform based on other existing operating systems such as Linux OS. figr 6 provides arelative comparison of the amount of foundation required to build devices based on Android versus Linux OS.

Figure 6: Android vs. Linux OS.


10/16


.ntor.o10

Android is available as a complete code base and is supplemented by a comprehensive set of tools to performdevelopment in the Android Framework and creating new Android applications. Android architecture makes itpossible to leverage thousands of available applications and create a home-grown Android application store, whichdoes not have to be limited to a specific set of applications certified to work on a device. An application store canbe easily expanding to provide any Android applications coming from various sources.

The Android OS implements security features on different levels. Starting from the Linux kernel which providesbasic permission mechanisms to system resources all the way up to the framework level ensuring that anapplication cannot access system capabilities (Services) without having required permissions. The Android OS isdesigned in a way to protect system core functions from applications that could potentially misbehave.

callees p e add s

The Android OS has a great many design trade-offs, which make it flexible and scalable to satisfy the requirementsand needs of a variety of embedded systems. However, it should always be taken into account that Android wascreated and implemented for mobile phones. Consequently, there are certain boundaries that can curtailimplementation decisions. On the surface, this might make the Android porting task more complicated, butthats simply not the case.

The phone stack is a major component of the Android Framework. There are phone-specific events and interfacesdefined at the framework level and implemented by the phone application and Services. A certain portion of theBluetooth API, namely support for the Bluetooth headset, is delegated to the phone application rather than makingit a general purpose API. Thus, making an embedded device equipped with a Bluetooth headset, used for non-phone communications, is not straightforward with Android. The Contacts application is tied to phonefunctionality and implements a phone dialer. While its reasonably straight forward to make a phone, this mightnot work so well for other devices.

The Android stack assumes that certain I/O devices are present in a system. For example, a SD card is used as adefault non-volatile application data and content storage. Audio hardware is expected to be present and ifBluetooth connectivity is presented, it has to be connected to audio over a hardware PCM link. User notificationmechanisms use LEDs and vibrator.

The following are a few key challenges developers might encounter when porting Android.

1 add uma mace ad use efaces

The user interface is a key distinguishing feature for most embedded products, especially in the consumer marketwhere many suppliers are making similar gadgets. On one hand, Android is designed for easy software reuse.However, it also leads to a problem as making an Android port to an embedded device wont be enough becauseits not going to look different from the others. The Android SDK does offer basic GUI customization, while themajor components such as Notification Bar and Home Applications have to be re-worked. It gets furthercomplicated by the fact that modifications might be required at the Android Framework level.

A user interacts with the Android OS using certain input methods such as a touch screen, track ball, and buttons.

Some buttons are handled at the Android Framework level, and in fact, play an important role in Androidarchitecture. Namely, home and back buttons, which are essential for Android operations since they are necessaryto manipulate tasks running in the system. Since Android operation relies on the buttons they have to be somehowpresent in a system, i.e. either available at hardware level or emulated. However, the buttons that are emulatedmight not be easy and implementation may vary depending on device requirements and use cases.


11/16


.ntor.o11

2 pwe maaeme

The Android OS implements a layered power management model working on top of standard Linux PowerManagement capabilities controlled by the Android Framework and applications. The Android Power Managerservice implements a wakelock concept when applications request and hold wakelocks preventing the systemfrom entering sleep state.

The default Power Manager implementation controls backlight brightness and dims the backlight when there areno applications active in a system. This achieves a good balance between device responsiveness and powersavings while idling, which is essential for a mobile phone. However, different embedded devices might havedifferent requirements where a different power management model needs to be implemented. For example,entering a sleep state, such as to suspend RAM or suspend to disk. Another example is when a display has to bealways turned on while all unnecessary peripheral devices should be disabled to minimize power consumption.

Addressing such requirements will require major rework of the Power Manager service.

3 b me

Android takes a while to boot up. Actual boot time depends on various factors including the Android version and

hardware speed. For many embedded products, a fast boot time is one of the key requirements and as such,Android might not fit well in that scenario.

Android takes as much time to boot as it needs to go through all boot steps. For example, DalvikVM does notwork directly with byte code generated during Android build. Instead, it works with optimized byte code version(DalvikVM cache) which is generated in runtime on a target device. DalvikVM caches have interdependenciesbetween each other. During boot process, Android needs to make sure that DalvikVM cache is valid and the wholesystem is consistent. Another example is a Package Manager that scans for available application packages in thesystem and dynamically generates a runtime list of installed packages and then creates runtime data for Intentsresolver. Both these design trade-offs allow developers to achieve faster runtime performance and flexibility (e.g.application installation process is quite straightforward) with sacrificing Android boot time.

There is no common solution to speed up Android boot time. If one existed it would have already beenimplemented. However, based on particular product use-cases, requirements, and implementation, certainmethods and techniques could be used to identify and optimize boot-up bottlenecks.

The boot process has multiple stages. First, it is necessary to make sure that both a boot loader and Linux kernelare optimal. There are a number of tools available to profile the Linux kernel and Android early in the process suchas kernel tracers and bootchart. Oprofile could also be used to perform a system wide profiling and profilingparticular components to find bottlenecks.

Sometimes the order in which system services are loaded may impact the total boot time. The interdependenciesbetween system services should be carefully examined and proper boot order is determined.

File storage type and partitioning scheme also can have impact on system boot time. Rebuilding a DalvikVM cache

in runtime during system boot could be faster than reading and checking prebuilt caches from external storage.

Also complete system shut down and startup sequences could be eliminated by using system sleep states such assuspend to RAM and suspend to disk. It might not be always appropriate but if system configuration is fixed itcould help.


12/16


.ntor.o12

exed add

Making a non-handset device in Android might require extending Android to provide new functions depending onembedded product purposed. Simply put, the phone stack needs to be taken out and some other software unique

to the product needs to be implemented or integrated. And it might have to be done on all levels of Android asdepicted on figr 7.

New device drivers (from the Android perspective) can be added or enabled in the Linux kernel. Some native codewould have to be implemented to interface with the driver over system call interfaces and be accessible of Javaframework extension over DalvikVM JNI bridge. The framework extension could implement new system services,modify existing source (e.g. change a notification bar design). New Intents or AIDL might be added at theframework level as well, as new permission groups for applications use them. And on top, the Android API couldbe extended for applications to use for new Android functions.

This also introduces the problem of maintaining product-specific Android extensions in regards to upgrading tofuture Android releases. This might be considered a disadvantage for Android. However, there is another problemthat deserves a separate discussion, which is integrating an existing source code into Android.

leacy sfwae ea

Its very likely that Android could be selected to create a next generation of existing embedded products whichentails migrating from some other OS. In this case, the software implementing the necessary functions couldalready exist and should be integrated to Android.

Figure 7: Extending Android.


13/16


.ntor.o13

Even though Bionic libc and core libraries are derived from a UNIX-like operating system, its been done with aminimalistic approach, providing only those system functions that are required to run Android. Thus, certainlibraries and interfaces used by the software working in the GNU environment might not be available in Android.Several examples include:

No SysV IPC support

No STL support

Partial pthreads support

No Linux-headers package

Minimal scrubbed set of headers

This means that compiling GNU-based software might be a difficult task and will require either changes to existingsource code or Bionic. This might not be acceptable for various reasons. If this is the case, another approach shouldbe considered to make use of legacy software in the Android runtime environment.

Figure 8: Running both GNU and Bionic in parallel.


14/16


.ntor.o14

c-exs u ad bc

One of the methods of using existing GNU-based software is to run both GNU and Bionic runtime environmentsin parallel as depicted in figr 8. In this case, Android would communicate with GNU-based software via IPCmechanisms provided by the Linux kernel. It could be a native Android IPC such as Binder, if the GNU runtime isextended to support it, or conventional mechanisms such as network sockets. The existing software could be

extended by an upper-level communication layer, which would be kept separately from original software thatstays untouched.

e mul-s appac

Sometimes a situation might arise when a hybrid approach described previously might not be possible for variousreasons. Migration to Android could be performed from a different operating system either commercial or homegrown. Certain system requirements need to be implemented such as performance, boot time, response time, orother real-time characteristics. Android software licenses reduce the risk of releasing software IP, but might notcompletely mitigate it. Certification might be required for certain software, which could be more difficult if its apart of Android.

The list of reasons could easily continue, but there may be one solution to address most of them. Its running the

Android OS in parallel with another operating system. The solution for this scheme could vary depending onfeatures provided by the SoC.

In case of single core, various virtualization solutions (commercial or open source) could be utilized. For multicoreprocessors, it can be either virtual machine/hypervisor or both OSes could run on separate cores with static

hardware resource separation.

The communication between OSes (figr 9) is provided by the virtualization layer (e.g. virtual network) or itcan be explicitly be implemented for both OSes via shared system resources, such as shared memory and inter-processor interrupts (e.g. MCAPI).

Figure 9: The multi-OS approach.


15/16


.ntor.o15

Applications for the multi-OS approach could be embedded products with a user interface driven by Android andcore device functions run by other OSes/RTOS. Examples include multi-function printer, Automotive IVI systems,medical devices and so on.

adwae esucesWith its great design, Android is not a true embedded OS that fits a minimal system configuration. By using Java,it achieves high machine independency levels requiring more processor power and memory to run. All richgraphics and multimedia capabilities provide more than ample room for creativity designing user interfaces andcorresponding applications, but it will require more processor power and memory, as well as hardware assistancefor graphics operations and audio/video decoding to off-load main processor core.

Modern processors and graphics acceleration features are sufficient to power Android. However, selecting a higherlevel SoC and adding more memory will impact the cost of a final product. So there are always open questions thatneed to be carefully analyzed before making a final decision towards migration to Android.

Is it going to be a display-driven device?

Is a processor powerful enough to run Android?

Is there hardware acceleration for graphics and multimedia available?

What is the memory budget?

Obviously, there are no common answer to all of these questions. It all depends on product requirements and usecases. Sometimes, having a low-power processor with a reduced feature set is enough if there are no multimediaor graphics requirements. If display size is small enough there may not be a need for installing large amount ofmemory. Having source code integrated to Android rather than running in parallel using some sort of virtualizationapproach might impact hardware cost, reducing software implementation costs.

cclus

Android is a rapidly growing software platform. Even though it was originally created for mobile phones, it isquickly being deployed on many different types of embedded devices. By performing a low-level Android portto an embedded device, it will bring the complete Android Framework available leveraging existing Androidapplications. There are certain challenges in making an Android-based product. However, once these problemsare addressed the development cycle for future revisions will significantly shorten.


16/16


2010 mntor rhi corortion, right rrv. hi ont ontin inortion tht i roritr to mntor rhi corortion n it in ho or in rt th origin riint or intrn in ro on, rovi tht thi ntir noti r in oi.n ting thi ont, th riint gr to vr ron ort to rvnt nthori o thi inortion. a trrntion in thi ont r th trr o thir rtiv onr.

MGC 12-10 teCh9390-w

F o r t h e l a t e s t p r o d u c t i n f o r m a t i o n , c a l l u s o r v i s i t : w w w . m e n t o r . c o m

efeeces f make daa:

http://www.digitaltrends.com/mobile/only-36-2-percent-of-android-devices-run-froyo/

http://www.pcworld.com/article/209803/developers_will_focus_on_winpho7_and_android_apps_in_2011.html

http://www.computerworld.com/s/article/9194278/Android_phones_outsell_iPhone_2_to_1_says_research_firm

http://www.androidtapp.com/list-of-android-devices/

http://en.wikipedia.org/wiki/Comparison_of_Android_devices

abu e au

A Software Architect at Mentor Embedded Professional Services, Vlad Buzov has more than 7 years experience in

Embedded Linux programming which includes porting, customizing and optimizing existent products, and developingnew custom solutions based on open source components for Mentor Embedded customers. Prior to Mentor, Vladserved as Senior Engineer at Embedded Alley and MontaVista Software. Originally from Russia where Vlad received hisMaster Degree in Computer Science from St. Petersburg State University, he is now based in San Jose, California.

android i trdemrk of ooge nc. ue of thi trdemrk i bject to ooge permiion.linx i the regitered trdemrk of lin orvd in the u.s. nd other contrie

Porting the Android Platform Beyond Mobile Phone Applications

Documents

Transcript of Porting the Android Platform Beyond Mobile Phone Applications