Your SlideShare is downloading. ×

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

357

Published on

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 …

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.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
357
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 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
  • 2. International Journal of Advance Foundation and Research in Computer (IJAFRC) Volume 1, Issue 6, June 2014. ISSN 2348 - 4853 86 | © 2014, IJAFRC All Rights Reserved www.ijafrc.org 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.
  • 3. International Journal of Advance Foundation and Research in Computer (IJAFRC) Volume 1, Issue 6, June 2014. ISSN 2348 - 4853 87 | © 2014, IJAFRC All Rights Reserved www.ijafrc.org • 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
  • 4. International Journal of Advance Foundation and Research in Computer (IJAFRC) Volume 1, Issue 6, June 2014. ISSN 2348 - 4853 88 | © 2014, IJAFRC All Rights Reserved www.ijafrc.org 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.
  • 5. International Journal of Advance Foundation and Research in Computer (IJAFRC) Volume 1, Issue 6, June 2014. ISSN 2348 - 4853 89 | © 2014, IJAFRC All Rights Reserved www.ijafrc.org 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.
  • 6. International Journal of Advance Foundation and Research in Computer (IJAFRC) Volume 1, Issue 6, June 2014. ISSN 2348 - 4853 90 | © 2014, IJAFRC All Rights Reserved www.ijafrc.org • /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.
  • 7. International Journal of Advance Foundation and Research in Computer (IJAFRC) Volume 1, Issue 6, June 2014. ISSN 2348 - 4853 91 | © 2014, IJAFRC All Rights Reserved www.ijafrc.org 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].
  • 8. International Journal of Advance Foundation and Research in Computer (IJAFRC) Volume 1, Issue 6, June 2014. ISSN 2348 - 4853 92 | © 2014, IJAFRC All Rights Reserved www.ijafrc.org 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))
  • 9. International Journal of Advance Foundation and Research in Computer (IJAFRC) Volume 1, Issue 6, June 2014. ISSN 2348 - 4853 93 | © 2014, IJAFRC All Rights Reserved www.ijafrc.org 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
  • 10. International Journal of Advance Foundation and Research in Computer (IJAFRC) Volume 1, Issue 6, June 2014. ISSN 2348 - 4853 94 | © 2014, IJAFRC All Rights Reserved www.ijafrc.org [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.
  • 11. International Journal of Advance Foundation and Research in Computer (IJAFRC) Volume 1, Issue 6, June 2014. ISSN 2348 - 4853 95 | © 2014, IJAFRC All Rights Reserved www.ijafrc.org [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.

×