Customizing AOSP For Different Embedded Devices And Integration at Application Layer.

International Journal of Advance Foundation and Research in Computer (IJAFRC)
Volume 1, Issue 6, June 2014. ISSN 2348 - 4853
85 | © 2014, IJAFRC All Rights Reserved www.ijafrc.org
Customizing AOSP For Different Embedded Devices And
Integration at Application Layer.
Charan K. V[1], A. S Manjunath[2], Sharmila[3]
Department of C.S.E , S.I.T, Tumkur, Karnataka, India
charanssit@gmail.com[1], asmanju@manvish.com[2]
A B S T R A C T
Android is a software stack that includes operating system, middle ware, applications for the
development of devices. Android has evolved greatly and user experience in addition to consumer
level efficiency along with integration of android powered devices also expanded. Because of its
core aspects like open source nature and architectural modal it is becoming more innovative
operating system. Android is being integrated and ported to various embedded devices this
includes enterprise desktop IP phones, cameras, modem, sensors, and set-up boxes and
automotive. One major advantage of using android framework beyond the mobile devices is the
android applications can talk to the functionality of all these devices powered by android and
developers need not to write several applications for different embedded systems. This paper
looks at the challenges in android migration to the different embedded platforms and porting
issues. Here we presented description of preparing and building AOSP in local environment and
implementation with Programming for integrating user applications in android build system
permanently.
Index Terms: Consumer level efficiency, software stack, architectural modal, porting issues,
automotive, android framework and android build system.
I. Introduction
Android provides complete software platform and framework rather than just operating system for
mobile devices and now a days it also creates possibilities of using in a much wider range of devices in
various domains such as control systems, military, medicine and automotive. Practically the android
architecture consists of application framework on top of modified Linux based kernel and it is java based
along with free licensing this facilitates its rapid deployment in many domains, allowing adopters to add
additional proprietary value in the android source. Android-based smart phones Surpassed Apple iPhone
shipments [9] in various places of the world, clearly showing how Android is open for innovation. At the
bottom of the stack is Linux kernel with many patches this provides basic system functionality process
management, memory management, networking and security but android does not uses all Linux kernel
utilities some of them has been modified like Power manager and Binder to regulate it for mobiles also.
On top of Linux the android includes a set of native libraries providing support for C/C++ native code
used by various components of the Android system. The some of the core libraries specifically designed
for android are bionics, media support for audio, video, SQlite for database etc there are many technical
reasons for reducing and optimizing some libraries like Bionic in android. Another key component of
android system is Dalvik virtual machine (VM) it is optimized and designed specifically for android. The
Application framework is a most extensive part of the android system it provides many higher level
services to applications. The developers can easily make use of services provided by the android
including accessing location information, running services background, set alarms and much more.
Android will ship with asset of basic applications including a calendar, email client, maps, and SMS
program, browser and others. All applications are written using the Java programming language. Our

application communicates in the java code of frameworks and it will intern makes a call to JNI to
communicate with C code in native libraries and C code determines what is the best way to do this for our
application and using hardware abstraction layer of kernel we can make use particular hardware [8].
Figure 1. Shows the Major Components In Android Architecture
II. Challenges and Issues
Historically Android has been widely deployed in mobile phones such as smart phones and tablets. Now
the android is grown-up with more patches and powerful versions of android has come up with support
for new kind of things, as well as more strong multimedia processing, android is escalating beyond its
origins and started migrating [11] into a wider array of applications and products. As a result, an
increasing number of developers are educating them self on android and also because of the advances in
android and kernel development we got curiosity to explore some of its benefits and challenging issues as
well as new possibilities it presents they are
• For migrating android system to the many embedded devices [25] we have to be aware of the
differences between the Linux and android.
• The Linux kernel driver policy for android is to avoid modules and it runs on a static hardware
configuration unlike Linux distributions that can run on a most hardware as possible.
• We need to ensure that the kernel is appropriate with the target hardware and with android, thus
ensure suitability between android and the hardware [11].
• Linux kernel for an android needs to be compiled according to the hardware of the target device in
which we want to build android system [12].
• Besides the kernel and drivers, the GUI of android needs to be adaptable with the target platform.
• Accordingly the changes made in the android kernel and codes for the hardware emulator do not
work well with actual hardware.
• Creating patches so that the Linux kernel is attuned for android and android intern is tailored for
the mobile phone or other devices [13].
• Once you have the Linux kernel ported, it is a fairly easy to get the rest of the android system in
place and then you can take advantage of a enormous number of the available android apps that are
existing in the community.

• Some functionality like Ethernet, AM/FM radio is not supported by default in android stack.
• Modularity is not included in stack designing so that packages and package features can't be
changes easily.
• Android stack has a strong dependency on hardware of a device. It is evident that the largest
dependency is on the touch screen as user interacts via the touch screen. A majority of the
embedded systems still does not contain any display [12].
Figure 2. Figure shows steps in porting android into ARM board
Porting is the ability to create target hardware specific images to bring life to target hardware by using
host machine and developing suitable environment to compile and build the source with the help of cross
platform tool-chain and finally downloading those images to the target hardware.
III. Migration of android beyond the mobile phones
This section takes look at value of android migration and describes android porting procedure for ARM-
based board and non ARM-based board. Android is trying to surpass beyond the mobile terminal space
and is generating an increased interest in the consumer electronics, automotive, home entertainment,
video surveillance and industrial equipment control domains. Although Android is the standard fit for
ARM processor technologies, commercial ports of android are available today on PowerPC, SH4
(Reneasas), MIPS, and x86 platforms. This portability makes it the most widely used mobile OS among all
the other Linux-based open platforms. The design of android OS originally only for the ARM processor
architecture, which made it the genuine choice for mobile phones as the first complete phone software
stack based on Linux. Since android is based on Linux kernel, there's a lot of opportunity to make it
available on other processor technologies. The task of porting Android to other processor technologies is
not of little value, as Android is heavily influenced by the ARM architecture.
A. Porting android to an ARM-based board.
The two steps procedure in porting to an ARM-based processor architecture board. First, Preparing the
Linux kernel for the boards [13] this requires stable Linux board support package (BSP), including the
boot-loader, Linux kernel, and device drivers for the ARM board. We need to get board specific patches
for android and U-boot they can be freely downloaded from Linaro instead creating from the scratch this
will require time and efforts to develop, test, and harden the patches before it can be used on the target

board. Once stable Linux kernel, Linux BSP, specific U-boot is available for downloading onto the board,
the next step is to preparing android and all images for the specific processor board and we can follow
this procedure.
• Remember to work using 64 bit machine for Gingerbread and later versions of the android and 32
bit machines will support froyo and earlier versions.
• Our local environment is equipped for downloading and building android AOSP by installing
packages as per the instructions of the official website [3].
• Download the board supportive android source from Google's android site using repository
management tool repo once successfully getting into the working directory it contains these sub-
directories.
• Initialize the environment using envsetup.sh shell script it will generate lunch command.
$ . build/envsetup.sh
• Execute shell script generated lunch command and choose build name that is the name of the
target device and choose build type for targeting emulator we can use full-eng.
• Build the Android in local environment using make tool. $make -j
• The successful building using make tool will create an image files named system.img,
userdata.img, ramdisk.img in generic directory.
• Then the image file is ready to be downloaded on the board.
Figure 2. gives high level details of android porting steps required for an ARM processor-based board.
The illustration assumes the Linux BSP is developed from scratch. If a Linux BSP is already accessible
freely from board vendors and it is fully configured for the target hardware, then the first step is not
necessary or may be required for incorporating additional device drivers for the target board.
B. Porting android to non ARM-based board.
Android open source project can run on any CPU in the world as android supports ARM, MIPS, power
architecture, x86 processors like Intel atom and other CPU's and as long as we are programming in java
the architecture does not matters. Majority of the CPU's in embedded devices are already ARM based but
still we have some non-ARM based CPU's they obligates to port android on a different non ARM-based
processor architectures like Super-H and Intel atom the following general steps are essential [11]. a large
amount of code needs to be rewritten and updated to achieve this port: Alter the android build system to
support the other architecture.
• Porting of the Dalvik VM for other processor.
• Include architecture and build support.
• Widen bionic run-time library/linker support to have room for the other architecture.
• Hardware-related tunings are needed to control audio, video, and graphics.
• Port the android media framework and other libraries.
• Integrate android-specific Linux Kernel patches into the board's BSP.
• Support the other architecture technology in the android SDK and android targets in the
customizable development system.
• Conduct the platform and integration testing of android stack components, very thorough testing is
required.
The dalvik VM and bionic C library are optimized for the android and they are vital components in the
stack at the same time porting of these components on non-ARM based CPU's is very difficult and
complex task. Upon completing the porting activity thorough testing is mandated to validate the port.

While these illustrated procedures are brief, to turn these into reality we will require low-level and
platform-level experience and a thorough understanding of the target environment, especially for the
non-ARM platforms.
C. Android applications in embedded devices beyond mobiles.
There is no full fledged usage of android in all embedded devices because lack of interface requirement
for so many devices this is also one of the reason to limit android but we can find it in only few of the
embedded devices like set-up boxes, cameras, enterprise desktop IP phones and also in future we can get
more number of embedded devices enabled with android some of the applications of android that we can
claim in different embedded devices and real-time features [20][22] they are.
• Using android powered set-up boxes increases user experience with the television and it is better
for the operators and also easy to develop [14].
• The applications developed using android OS can support ECG monitoring in mobile devices [15]
[23] and also for collecting sensory data from various embedded sensors [16].
• Real-time system features and several capabilities of android are used for implementing Body
area networks [19].
• The android penetration into the desktop IP phones used within enterprises offers more security
and also rich interface.
• Use of android in camera generates more applications in the device because we can walk around
the strong app store of the android community.
Figure 3: Figure shows sub-folders in AOSP folder.
IV. How to customize for transporting android into new device
This sections starts with introduction about AOSP with brief description about directories in android
source then we brings glimpse of the customization to be made to design and get android life onto the
new device.
A. What is AOSP?
Project responsible for creating android system is called AOSP it is primarily developed and maintained
by Google as of free availability it is more open to innovation that you often don't see in IOS and because
of more flexibility in customizing android it facilitated creation of more custom ROM's, rooting options
and they all provide plenty of features [17]. After synching AOSP from official website you will get sub-
folders as shown in Fig 3 some of the important sub-folders are.
• /bionic/ it is where bionic C library optimized for embedded devices is stored.
• /bootable/ boot and start up related code.
• /development/ projects associated to development such as source code for sdk and ndk tools.
Usually not a folder you tap when working with the platform for a target.

• /build/ it is one of the complex part of the system and it will pick specific board, specific target and
product.
• /cts/ the compatibility test suit directory made to test requirements for the android system to be
an android system and each android version has its own compatibility definition document and
compatibility test suit that runs tests on target hardware.
• /dalvik/ this directory contains the Dalvik virtual machine at /dalvik/vm, the dex compiler at
/dalvik/dx and core class libraries as well as related tools.
• /device/ this is place where most of the device specific things will be stored and some of the
commonalities will be stored in /device/common.
• /external/ External refers to external open source libraries. That means libraries that the Android
platform dependent upon but that are not primarily developed and maintained by Android open
source project. Typical examples are webkit for the browser, FreeType for fonts.
• /frameworks/ the directory contains android framework to support all the system and user
applications for example if we want media support is provided through /frameworks/media folder
and for graphics /frameworks/graphics folder.
• /hardware/ - this is where very hardware specific things will go. The /hardware/libhardware
folder basically contains things to abstract real physical hardware’s. This folder also contains the
reference radio interface layer implementation.
• /ndk/ - this ndk have tool-chain for building native code that may be low memory footprint code,
CPU-intensive code and cross compiling your native code for target device architecture.
• /packages/ this is the place where things bound to the applications are stored for example apps
that get included into the project are stored in /packages/apps folder and they will goes to devices.
The wallpapers and content providers also stored here.
• /prebuilt/ the things that are prebuilt and also distributed files in the binary form will goes here.
• /system/ this is a directory a lot of system related things as well as source code files for the core
android system will be stored. This also includes source code for the init process and default init.rc
script that provide dynamic configuration of the platform.
• /out/ the out/target/product/generic location contains required images that you can run using
emulator command and also they can be downloaded and flashed to a device if you are building for
target hardware.
It is a just partial view of the tracking and customizing the files in AOSP in order to prepare for
transporting [4] android into new device but real implementation needs lot of work to be done. we need
minutes of all components making up android including kernel androidism to optimize and develop
patches for kernel towards make it compatible with specific hardware as well as android and also we
need to learn adding support for new hardware in the device [2].
V. Tracking AOSP for porting into the new device
Porting android to the devices they are not meant to support for android is more challenging task before
starting first we need to find out how does new device heavily differs from usual android devices,
switching into any one of the specific android versions like Gingerbread, Ice cream sandwich we need to
go through the compatibility guidelines including memory, storage, display resolution, Graphics
requirements specifications that our new device should satisfy and device should provide android
applications compatibility, provide android marketplace support, provide access to Google services
without modifying any Google API's and framework.

The Google AOSP is up-to date reference but limited device support mainly it support for Google's official
device Galaxy Nexus. The Linaro AOSP [4] is most integrated with wide hardware support and because of
its Android added values like extra and optimized packages it gives more hardware devices support than
stock Google ICS, it supports for TI pandaboard, TI BeagleBoard, Freescale i.MX53, ST Snowball, Samsung
Origen devices.
• Take your AOSP and create directory for our new device with complete product description
under device directory of the AOSP sources.
• Create vendersetup.sh file that is executed by build/envsetup.sh and can use anything defined in
envsetup.sh
• Create Android.mk, AndroidProducts.mk, new_device_name.mk files and enter new device name,
device brand and specify all make files. The values we put here is very important because that
will be referenced by some other scripts during the run time.
• Create device.mk file it is the device specific product definition file. It lists all the overlays, files,
modules, properties that are specific to hardware of the new device. And set
PRODUCT_PACKAGES, PRODUCT_PROPERTY_OVERRIDES and some other make file rules specific
to our new device.
• build/core/product.mk file in AOSP contains build options like Target and compiler options,
Enable NEON feature, File-system and partitioning and some other options that we need to edit
according to our target new device.
• Create a device/my company/my device/overlay directory with same depth and files you want to
overwrite for new device specific settings that you may want to customize for target device, this
will avoids you touching the files from AOSP.
• If you have U-boot customized for your specific new device just replace it with the generic boot-
loader provided by Google at bootable/bootloader/legacy and if you not using prebuilt version of
the U-boot you may just specify true for the TARGET_NO_BOOTLOADER, TARGET_USE_UBOOT
and specify customized configuration file using UBOOT_CONFIG commands in BoardConfig.mk
then U-Boot boot-loader is built by the specified configuration file.
• In android kernel no drivers are built as modules and according to Linux kernel driver policy the
drivers can be loaded or unloaded, if you do not want to use prebuilt kernel then we need to
specify our own kernel configuration file through KERNEL_COFIG command.
• The network and connectivity for your new device required to overlay some resources in
framework/base/core/res/res/values/cofig.xml.
• Within this file we need to change few lines based on what are the interfaces the processor board
of our new device will support and edit network attributes and radio attributes.
• For media support we create media_profiles.xml file and used to declare the multimedia profiles
and capabilities like decoding and encoding rate that our new device board will support.
• Override in BoardConfig.mk for phone or tablet mode.
• HAL (hardware/libhardware) acts as a bridge between regular kernel implementation and
android framework.
It is a just partial view of the tracking and customizing the files in AOSP in order to prepare for
transporting [4] android into new device but real implementation needs lot of work to be done and we
need minutes of all components making up android including kernel androidism to optimize and develop
patches for kernel towards make it compatible with specific hardware as well as android and also we
need to learn adding support for new hardware in the device [2].

VII. Implementation
Android is customizable in all the 5 levels before porting into any ARM based boards in this work we
started customizing from the application level. AOSP porting into new devices consists of two major steps
as described in the paper; here we have done preparing AOSP on host machine making it working on
android virtual device. Android will always arrives along with many applications, this forms an
application layer in the android stack including Browser, camera, Email, phone etc. When it moves
beyond mobiles and tablets to some other embedded devices, all the core applications need not be
required and some of them need to be newly integrated to the operating system. We have prepared make
file to describe any user defined application sources to the android build system and integrate to it
permanently.
• Go to packages/ apps/ in this location we need to copy application source code as we developed
using android SDK.
• Programming Android.mk file in application to describe user source code to the android build
system.
PRODUCT_PACKAGES:=
Login ******this is the addition********
ApplicationsProvider
BackupRestoreConfirmation
Browser
Bugreport
Contacts etc…..
• Then add make file to the product packages for that we need to edit /buid/target/core.mk file that
means add our application in the list of product packages.
• Content of the make file.
LOCAL_PATH:= $(call my-dir)
Include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := tests
LOCAL_STATIC_JAVA_LIBRARIES :=
android-common
guava
android-support-v13
android-support-v4
LOCAL_SRC_FILES:= $(call all-java-files-under, src)
LOCAL_PACKAGE_NAME:= Login
LOCAL_PROGUARD_FLAG_FILES:= proguard-project.txt
LOCAL_SDK_VERSION:= current
include $(BUILD_PACKAGE)
include$(callall-makefiles-under,$(LOCAL_PATH))

Figure 4. Figure shows emulator with integrated new application.
VIII. Conclusion and future work
In this paper we look at challenges and benefits of android migration into new embedded devices and we
presented general procedures to port android to ARM and non-ARM boards including partial view about
How to customize android source for preparing it to port onto new devices. After building AOSP on the
local host we prepared top level file in the directory for the user application to run directly along with
existing operating system. Our implementation is help full in integrating new applications based on the
target device; new applications can be carried along with the generated operating system images. The
success of android was only possible due to easy portability of Linux to various hardware platforms but
android is a watered-down, limited Linux distribution [5] that works for one specific purpose and Linux
kernel inside was always unaltered we need to apply some patches to add features that we want for our
new device [21]. The customizing ability of AOSP and also as an embedded android with Linux kernel it
provides new possibilities [18] for porting into many more devices. Creating androidism in the kernel for
different target hardware's we can definitely make android to support for new kind of devices other than
mobiles [6].
IX. References
[1]. Marko Gargenta learning android first edition O’Reilly publications 2011.
[2]. Karim Yaghmour Embedded Android first edition O’Reilly publications 2013.
[3]. official google android website developers.android.com
[4]. Benjamin Zores ABS 2012 - 13th Feb 2012 - Redwood Shores, SF Bay,CA, USA android device
poring walkthrough guidelines.
[5]. Al-Rayes, Hadeel Tariq. “Studying Main Differences between Android &Linux Operating Systems".
In. Proc: International Journal of Electrical & Computer Sciences IJECS-IJENS Vol:12 No:05

[6]. Colin Walls, Mentor Graphics Android development for embedded systems beyond mobiles.
[7]. Marianne Loes, Mapusoft Challenges in porting embedded applications.
[8]. Marko Gargenta founder and CEO at Marakana Learn about Android internals and NDK .
[9]. Top Smartphone Operating Systems, Shipments, and Market Share, Q2 2013 (Units in Millions)
analysed at http://www.idc.com
[10]. abhimanyu das, aricent technologies Android opens up the operating system for innovation
Mobile Dev and Design.
[11]. White paper by Darren Etheridge, Android Multimedia Engineering Manager, DSP and ARM Texas
Instruments “Developing Android applicationsfor ARM Cortex-A8 cores”.
[12]. Soumya Kanti Datta Mobile Communication Department EURECOM Sophia Antipolis, France
“Android Stack Integration in Embedded Systems”.
[13]. Abhyudai Shanker CSE Department Jaypee Institute of Information technology NOIDA, India,
Somya Lal “Android porting concepts” In.Proc: Electronics Computer Technology (ICECT), 2011
3rd International Conference Vol: 05.
[14]. Kuzmanovic, N. Maruna, T. Savic, M. Miljkovic, G. Isailovic, D Google’s android as an application
environment for DTV decoder system2010 IEEE 14th International Symposium on Consumer
Electronics (ISCE).
[15]. Jokic, S.Pokric, M. Krco, S.Delic, V. Jokic “application for WALK activity and ECG monitoring on
mobile devices based on Android OS”Telecommunications Forum (TELFOR), 2011 19th.
[16]. Gil, G.B. Berlanga et all, “inContexto: A Fusion Architecture to Obtain Mobile Context Information
Fusion (FUSION)” Proceedings of the 14th International Conference Publication Year: 2011 ,
Page(s): 1 – 8.
[17]. Ijjina Earnest Paul, et all “Android OS Customization” International Journal of Engineering and
Innovative Technology (IJEIT) May 2012 Volume 1, Issue 5.
[18]. Loc perneel,et all “Can Android be used for real-time purpose” International conference on
computer systems and industrial informatics(IJEIT) Dec 2012 pages 1-6.
[19]. Matthias Wagner, “Android Based Body Area Network for the Evaluation of Medical Parameters”
In proc: 10th International Workshop on Embedded Systems publication year: 2012 , Page(s): 33 –
38.
[20]. Claudio Maia, “Evaluating Android OS for Embedded Real-Time Systems” Published in
Proceedings of the 6th International Workshop on Embedded Real-Time Applications, July 2010.
pp. 63-70.

[21]. Igor Kalkov, Aachen, Dominik Franke “A real-time extension to the Android platform”
Proceedings of the 10th International Workshop on Java Technologies for Real-time and
Embedded Systems publication year:2012 Pages 105-114.
[22]. Bhupinder S, et all. IEEE “Reliable Real-Time Applications on Android OS” submitted for
publication June-18 2010.
[23]. Wolfgang Mauerer, et all “Real-Time Android: Deterministic Ease of Use” In: Proceedings of
Embedded Linux Conference Europe, 5 - 7 Nov 2012.
[24]. Ching-Wei Chen, Wei-Chieh Chou, Yi-Lwun Ho “Live Demonstration: A Mobile ECG Healthcare
Platform” Publication Year: Biomedical Circuits and Systems Conference (BioCAS), 2012 IEEE ,
Page(s): 87.
[25]. Charan K.V, Sharmila S.P, Manjunath A.S “Customizing AOSP for different embedded devices” 8th
IEEE International Conference on Computing for Sustainable Global Development (INDIACom)
2014.

Customizing AOSP For Different Embedded Devices And Integration at Application Layer.

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Customizing AOSP For Different Embedded Devices And Integration at Application Layer.

Similar to Customizing AOSP For Different Embedded Devices And Integration at Application Layer. (20)

Recently uploaded

Recently uploaded (20)

Customizing AOSP For Different Embedded Devices And Integration at Application Layer.