In the fall of 2008, Google and its Open Handset Alliance (OHA) partners introduced Android into the mobile marketplace. After several years of engaging in very stealthy development, and of fomenting rumors and speculation, Google opted not to build its own handsets. Instead, the Mountain View-based search and software behemoth elected to release an open source platform and to partner with HTC and other hardware manufacturers (OEMs) to build and deploy Android-based handsets and other device types. Even before launching the platform, OHA seeded the market with source code and tools, and instigated early development with a programming contest and the promise of a marketplace to rival the Apple iPhone App Store.

In the year since Android’s release, Google and OHA have delivered on and exceeded their original commitments and projections for the platform (Figure 1). The results are that in 2008, HTC shipped between 800,000 and 1,000,000 Android handsets, and in 2009, that company and eight additional OEMs announced dozens of new Android-based phones. In addition, Freescale Semiconductor and multiple OEMs have announced plans to ship netbooks and webpads based on Android to target the emerging Mobile Internet Device market

Moving Beyond Mobile

Perhaps more interesting than Android joining in the global smartphone fray is the prospect of the platform expanding beyond mobile, to encompass embedded applications from consumer electronics to automotive to instrumentation to control. We focus here on designs and applications for Android in these and other ubiquitous embedded domains.

Why all the fuss about a mobile phone platform? Android is just one of half a dozen smartphone OSs, and enters a broader embedded marketplace teaming with over one hundred OSs, including real-time executives and application platforms. To understand the appeal of Android to device OEMs, it’s easiest to examine the shortcomings of these (legacy) embedded platforms. Most real-time operating systems (RTOSs) focus on system-level functionality but lack rich middleware supporting multimedia, graphics and other modern application-enablers. While existing embedded Linux implementations offer broader APIs, middleware and graphics frameworks, they still fall short in handling high-level application support. Even though Microsoft Windows CE, Windows Mobile and other incarnations of Redmond’s embedded code base do offer rich APIs and a tall stack, they are proprietary/closed (shared source programs notwithstanding) and expensive to deploy.

Both legacy RTOS and Linux-based platforms can support field upgrades and post-load (re)deployment, but are not optimized for after-market application deployment. In fact, most legacy embedded software ecosystems provide no unified channels for mass market software distribution; those few that do (e.g., iPhone or PalmOS) are closed, rigidly controlled and target a narrow range of devices.

By contrast, Android is an open source (Apache licensed) application-centric embedded OS, boasting an enterprise-class kernel (Linux), middleware for broad interoperability and application support (Java, CODECs, UI), with a ready-to-use distribution channel, readily retargeted for multiple CPU architectures and device types.

What is Android?

The Android Web site touts the platform as a “complete set of software for mobile devices: an operating system, middleware and key mobile applications” along with a software development kit (SDK). Android was built from the ground up to enable developers to create compelling mobile applications that take full advantage of all a handset has to offer.

Simply put, Android is a Mobile Phone OS built on top of Linux and the code of other OSs. It is a “tall” stack that emphasizes application development and deployment on a par with system-level functionality, and even includes a set of core applications. Like many mobile software stacks (and unlike most Linux-based platforms), Android offers Java APIs and frameworks to application developers via Dalvik, Google’s Java Virtual Machine (JVM) work-alike.

While the emphasis here is on Android moving beyond mobile, it is useful to compare/contrast Android in Table 1 with other (mobile) applications platforms. Pardon me if I’ve left out your favorite Linux-based platform. LiMo, Ubuntu Mobile, Debian Embedded, Mobilinux, ALP, Azingo Linux, OpenMoko and others share the majority of their component software and frameworks with Mobilin and Maemo.

At first blush, Android presents a typical four-layer stack: OS/kernel, middleware, application framework and applications themselves (Figure 2). But while the familiar “boxes” fall in the right places, the contents of those boxes can depart from established expectations. One example is the Linux kernel. Android SDKs build on aggressively forward-looking Linux kernel versions. For example, the Android 1.5 SDK integrates the Linux kernel 2.6.27, but with a fairly extensive Android-specific patch set. And although Android builds on Linux, it leaves behind many familiar elements. Notable is the Android Bionic run-time, which is based not on GNU glibc but on a BSD-derived C library.