Porting Android on embedded platforms: a step-wise approach - Embedded.com

Porting Android on embedded platforms: a step-wise approach

The advent of Google’s open source Android distribution of the Linux OS has generated tremendous interest in the developer community to customize/port the same for their products running on other embedded platforms. These devices include mobile computers, vehicle mount devices, digital TVs, set-top boxes, video conference devices, and game boxes amongst others.

The advantage of making Android available to multiple device platforms signifies that applications, and features developed for one device could easily be made available for another platform with minimal porting needs, thereby allowing developers to focus their efforts more on introduction of new products in the market.

Given that Android is a Dalvik Virtual Machine Monitor-based software OS that runs on a Linux-based kernel, in order to port an Android platform one needs to port the underlying Linux OS and thereafter the Android stack (Figure 1 ).

Figure 1: Android Architecture

For porting Android on other embedded platforms, a 4-step approach is recommended:

  • Step #1: Porting feasibility check
  • Step #2: Porting and booting Linux on the reference platform
  • Step #3: Porting Android onto the reference platform
  • Step #4: Enable Non-working modules/drivers/applications

Step #1 ensures the feasibility and gathers the list of working and non-working functionalities. While Steps #2 and #3 largely involve independent activities, but some customization might be required in the Android core libraries once the Linux drivers are installed. As and when the device is loaded with Android, many of the components might not work because of the difference in configuration of the hardware abstraction layer (HAL) or missing drivers and libraries. However, these components get enabled in Step #4.

Porting to a vehicle mount computer
To understand better, let’s look at an example of Android porting on an embedded device (vehicle mount computer) which is based on x86 architecture:

Porting feasibility check
The default Android x86 image needs to be installed on a target device to perform the feasibility check. It certainly involves some efforts to get the system up and running! We also need to collect the list of working and non-working functionalities. Working functionalities can be display, USB, etc and non-working can be touch screen, Ethernet.

Porting and booting Linux
The main steps for porting Linux are (1) to install bootloader and (2) build the kernel image and bring the kernel up.

Since we selected x86 architecture platforms, GRUB is a good bootloader to extract. Now put the boot medium into the target device and power on the device to boot with the just installed GRUB. If GRUB is installed properly, the “Run Android” option will appear on screen.

The kernel image can be used from the Linux kernel archives or using android-x86 repo. Then the user needs to select the Android configuration file from /arch/x86/configure path and compile it. Once we get a compiled kernel image, we can instruct GRUB to select this image. After this step, the prompt will display “Detecting Android-x86…”
Porting Android
Following are the main steps for Porting Android:

  • Build the environment setup
  • Build the Android stack
  • Booting system with Android stack

Androiddevelopment requires a few tools and utilities for source compilation.The environment setup process does install these tools and utilitiesinto the development host machine. Once the environment is set, thesource code build can be started. On successful compilation, the buildsystem generates bundles for the kernel image, initial ram disk image,and a user space stack. All of these have to be loaded into a bootablecompact flash with the boot loader installed, and for booting thedevice.

The screen image that appears (Figure 2 ) on a successfully ported android ICS screen will look similar to the below depiction:`

Figure 2: Android Boot up on Vehicle mount computer

Enable non-working applications/drivers
This step is basically to make various interfaces like Wi-Fi, Bluetooth and Ethernet  work together.

Codechanges are often required across the android stack, from theapplication layer to the hardware abstraction layer and the Linuxkernel, to enable these interfaces. For instance, the Ethernetconnectivity requires the Ethernet driver to be enabled in the kernel,Ethernet connectivity service and DHCP in android framework.

Wi-Firequires the WPA supplicant service to be running and the interactionof user space program to pass events request to the kernel; thetouchscreen requires the corresponding driver running along with propermapping of input event to input subsystem, and so on for otherinterfaces.

The screen shot in Figure 3 shows an Ethernet enabled device screen and internet access through it.

Figure 3: Ethernet Driver integration

ThoughAndroid was initially introduced for mobile handsets, it has a muchwider potential. It is open to all – industry, developers, and users.There are opportunities in the Android platform to support other devicesin the rugged device space. Apart from Google, apps developers and OEMsare predicted to be the major beneficiaries.

Developers areseriously considering Android OS as a feasible option to supplementtheir Windows offerings. The uncertainty about Windows OS offerings, therise in popularity of Android, and the need for vendor differentiationare compelling developers to embrace this change.

Rishi Agarwal ,Program Manager, Product Engineering Services at Collabera, isresponsible for managing programs for the company’s US-based clients. Hehas experience in large scale system design, architecture assessment,and wireless and telcommuncations embedded software development. Priorto Collabera, Rishi was a Technical Lead with Motorola. He is a Bachelorof Engineering in Electronics & Telecommunications from AllahabadUniversity.

References :




Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.