Android for the rest of us

Hardly a day goes by without the arrival of a new Android phone commercial or rumors emerging about Google’s next innovation. Android is magnetic: it is attracting the best application developers, assembling the largest collection of ODMs, recruiting leading software and semiconductor vendors (aka the Open Handset Alliance), and thus becoming “the new black” for marketing engineers everywhere. But assuming that you are not developing the next iPhone killer or blog-worthy app, why should any of this matter to you?

Android is already invading e-readers, media players, netbooks, GPS systems, Internet tablets, digital photo frames, VoIP phones, set-top boxes and more. Yes, these are somewhat natural extensions of the phone with their touch screens, responsive graphical user interfaces (GUIs) and built-in connectivity—and yes, consumer electronics accounts for only a small percentage of the embedded device market. But my question today is this: How useful is Android in segments such as point of service, industrial controls/automation, automotive infotainment, utility monitoring, home automation/security, portable ultrasound/patient monitors, and more beyond?

Linux made easy

Let’s first take a look at Android from the bottom up. It encompasses an operating system (OS), middleware, an application framework, a toolset and an open source community. The OS consists of a set of Android-specific patches on top of a Linux kernel. These patches add the Android vision for low-memory, power-sensitive processors by modifying the kernel’s memory management, power management and inter-process communication (aka, its binder). Unlike traditional Linux where processes slowly starve as memory runs low until the ‘out of memory’ (OOM) killer activates, the Android kernel adds further intelligence by categorizing processes with respect to user importance.

Processes in the least important group are killed to keep a system responsive. For example, the foreground user interface (UI) is likely to be of highest priority, though you can of course set these priorities according to your specific product requirements. Android also introduces the notion of “WakeLocks,” which supply power to particular peripherals, such as LCDs and backlights, and turns them off when they’re not needed. Finally, Android’s IPC driver—binder—is added to the kernel. Binder is a rewritten (thus Apache v2 licensed) and trimmed-down version of OpenBinder that provides resource sharing and assignment, and process management during runtime. It is this lightweight processor focus that turns a desktop-centric Linux kernel into an attractive embedded OS.

The three recurring themes in Android middleware are Apache licensing, library breadth and the Dalvik Virtual Machine (DVM). Android has gone to excessive lengths to place the entire user space stack under an Apache v2 license, speeding its commercial adoption rate amongst those apprehensive about working with the GNU General Public License. Apache-licensed software can be integrated into proprietary projects without imposing the source redistribution requirements of ‘copyleft’ licenses like GPL.

Bionic is Android’s C runtime library. It differs from the widely used ‘glibc’ in that it lacks features like full ‘pthread’ and ‘SysV’ support. If you already have large glibc-compatible C libraries, there may be migration pains in moving to bionic, so you may choose to continue using glibc. On the other hand, bionic uses the very liberal BSD licensing scheme and is considerably smaller and slightly faster than its counterpart.

In addition to the C library, Android comes with libraries for both 2D and 3D graphics, Web technologies, databases, multimedia and more. Instead of receiving a Linux base port from the silicon vendor and either paying a third party for a complete development file system or painstakingly assembling one yourself, the Android base port already provides this level of system integration.

Every Android application runs in its own DVM, which in turn leverages the Android kernel patches for memory and process management. Unlike traditional virtual machines (which stereotypically perform poorly), the DVM was designed like the rest of Android to reduce the memory footprint by stripping duplicate constants, linking inline functions and using an optimized DVM instruction set (as opposed to Java bytecode). The DVM is also register-based and this can help to reduce the number of instructions and increase bytecode efficiency. Finally, the DVM was specifically optimized for multiple instantiations as most modern devices should be able to run multiple applications simultaneously.

Android’s expansive API provides the app developer access to a variety of hardware resources without forcing him or her to worry about their exact implementation. In fact, the Android SDK comes with an ARM simulator that runs on an x86 host to allow application development without specific hardware. And since Android shares Java’s syntax and practices, application developers are widely available. Once applications are created, they can be moved across hardware platforms (and vendors) with relative ease. This lends itself well to the creation of scalable low-end and high-end products.

This is a complete system that is ready to deploy if you only need to use the functionality provided by Android. The model works well if you do not want to choose among the almost-infinite open source options (and dependencies) available in a traditional Linux stack, or have the time or energy to migrate your applications with the rapidly evolving open source software underneath. However, it is likely that you have legacy system code to support or require software resources that are not provided in the Android stack. The Android Native Development Kit (NDK) allows C or C++ code to be built into native libraries to be run in the DVM and to be packaged into Android application packages (*.apk) for device deployment.

Closely associated with Android is the notion of an “App Store,” but this does not necessarily imply an iTunes-like experience. Android devices can have their own custom app stores launched by the hardware manufacturer, such as AppsLib from media player specialist Archos. Depending on the design, you may want end-users to be able to install their own *.apk packages as they become available online. For example, a home automation system user could download a weather app or a shopping list app according to his or her fancy. In this way, a device’s software is no longer limited by your resources, but open to thousands of other applications just as you would expect in a desktop environment.

Android has built-in checks to verify the app can be supported by the version of the platform installed on the device. In a more closed system, the store concept can be used to simply and safely upgrade or add features to units deployed to the field, such as POS terminals needing an updated SKU database or extra data field in the GUI. Conversely, if a device is Google-approved, users can download applications directly from the Android Market, which provides a full mobile phone experience.

For most applications, the basic Android look and feel is advantageous as users highly associate it with a strong brand. But how do you take advantage of Android here if you want or need to retain a custom look? Custom branding has already occurred in cell phones, such as the HTC Droid Eris, which sports HTC’s custom Sense user interface (UI) overlay. One way to achieve such customization is by leveraging commercial UI engines, such as Mentor Graphic’s Inflexion software. It includes GUI builders and smooth integration on top of Android’s native interface.

Thus far, we have primarily viewed Android as a close relative to Linux with several advantages. How does it fare compared to Windows CE?

They both provide single-source tooling—that is, you can get your development IDE, compiler and debug tools from a single vendor. Of course, that is not to say that more advanced options are not available from third parties, but the point is that you can get to production without additional tools.

Both Android and CE also provide application frameworks that enable massive numbers of application developers and allow for faster development time as less time is spent on middleware.

However, their primary differences favor Android. Cost—you can’t beat free, both in per-seat development costs and runtime royalties. Licensing—were you hoping to modify and redistribute source code?

Let’s start customizing

If Android sounds appealing, let’s review what you need to get started. First and foremost, you need an Android base port and a development board. Texas Instruments’ OMAP35x product generation is particularly suited for Android with its high-performance Cortex-A8 GPU, SGX vector graphics accelerator, and C64x+ DSP, coupled with low power performance (Figure 1, p. 27).

The OMAP35x family consists of four devices, with varying combinations of the SGX and DSP, thus allowing end-product scaling. For example, Android on an OMAP3503 can make use of ARM-side multimedia codecs, whereas an OMAP3530 can seamlessly utilize DSP codecs without changing any application level code. Similarly, an Android application on OMAP3525 can still render 3D OpenGLES graphics via ARM, whereas the flagship OMAP3530 would make use of the SGX vector graphics accelerator, again, hidden beneath the Android framework.

Texas Instruments’ OMAP35x family also includes a variety of development boards, ranging from TI’s OMAP3530 Evaluation Module complete with a touch-screen LCD to the low-cost BeagleBoard at only $149 (Figure 2). The BeagleBoard has attracted a large community of developers with projects ranging from SDR to license plate recognition, available at beagleboard.org. An Android base port for OMAP35x is available at www.arowboat.org and includes the complete source code as well as documentation to start your development. To recap, the full OMAP35x family is shown in Figure 3.

In addition to the Android base port, you will need the Android SDK itself for application development, available from developer.android.com. The SDK is available on Windows, Mac OS and Linux hosts. The latest SDK is version 2.1 and is associated with the Éclair branch, whereas the previous 1.6 version was related to the Donut branch.

Each SDK adds features. Some of the more interesting ones to emerge recently include HTML5 support for browsers, gesture input and builder, and text-to-speech. In addition to the SDK needed for application development, you may also want the Android Development Tool (ADT) plug-in for Eclipse, which turns your IDE into an Android GUI builder, Android application debugger and Android application signing utility. With the ADT, Android applications can easily be compiled and then run on emulators or hardware connected via USB or Ethernet with a few simple mouse clicks.

Android can take the complexity and cost out of almost any design, whether it is a doctor’s portable patient chart system or a next-generation vending machine. It comes with a complete development stack right out of the box so there is no need to be a GPS, graphics, or browser expert to be able to use them. By standardizing a simple API, your applications become portable across platforms and hardware and are insulated from rapidly changing open source software underneath. So make Android your next “one stop shop” for effortless system integration, painless user-interface and trouble-free development.

Texas Instruments Inc.
Product Information Center
13532 N. Central Expressway
M/S 3807
Dallas
TX 75243-1108

T: 1 972 644 5580
W: www.ti.com