TECHNOLOGY IN CONTEXT
New Mobile Platforms
Android Moves Beyond Mobile
Originally a niche platform for mobile handsets, Android is moving into a host of embedded applications building on Linux, Java and the desires of users to frequently bring new applications into existing embedded devices.
BILL WEINBERG, LINUX PUNDIT.COM
Page 1 of 1
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.
Another example is the JVM. For both technical and business reasons, Google/OHA chose to eschew licensing a Coffee Cup JVM from Sun and instead implemented a new (and improved) Java-compatible VM, which runs Java applications that have been converted into a compact Dalvik executable (.dex). Developers comfortable with both enterprise Java profiles (J2SE) and also mobile/embedded profiles will be mostly comfortable targeting Dalvik using both new and repurposed Java source code—not byte code.
Android began its existence and still primarily targets ARM-based mobile SoCs, most notably the Qualcomm chipsets in the HTC G1 “Dream” phone. Android also supports the x86/Intel Architecture (originally for prototyping).
In pursuit of addressing the wide variety of intelligent devices with Android, Silicon Valley-based Embedded Alley introduced an Android development system with support for RMI/MIPS processors in May 2009. “The opportunities presented by Android span the gamut of intelligent devices types and markets,” noted Matthew Locke, Embedded Alley COO, who is now Director of Linux Technology at Mentor Graphics. “To meet the growing demand for Android enablement, Embedded Alley created our Development System.”
Shortly thereafter, MIPS Technologies announced availability of Android on MIPS architecture and launched an initiative to drive Android beyond mobile handsets. “Android is now moving beyond mobile devices, becoming a standard way to bring the full Internet experience to DTVs, set-top boxes, MIDs, digital picture frames and other embedded devices, noted Udi Kalekin, VP of Engineering at MIPS Technologies. “With Android, developers can easily take advantage of a feature-rich, open source, Internet-connected platform.”
In July, Mentor Graphics’ Embedded Software Division acquired Embedded Alley, and unveiled its plans to extend Android support to Freescale Power Architecture SoCs and multiple ARM-based processors. “Mentor’s strategy acknowledges trends we see in embedded device development,” stated Glenn Perry, Mentor Graphics Embedded Systems Division General Manager. “One is a huge demand for Google’s Android platform in new, complex devices beyond the mobile phones for which Android was originally developed.” At the time of writing, Android supports ARM, x86, Power and MIPS architectures.
Retargeting Android to new architectures involves rather more investment than just swapping out the underlying Linux kernel with one for a different CPU family. Architecture-specific integration and optimization chores traverse much of the Android stack:
• Porting the Dalvik virtual machine underlying Android (e.g, to MIPS and Power Architectures), including architecture and build support and performance optimization for the Dalvik VM
• Extending Android bionic run-time library and linker support to accommodate new instruction set(s)—endianess, assembler bindings, system call code, etc.
• Enabling architecture-specific coprocessors, engines and special-purpose instructions for performance enhancement across Android software modules
• ntegrating and testing board support and specific device drivers, CODECs and other middleware
• Supporting a new architecture in the Android Software Development Kit (SDK)
• Platform and integration testing of Android stack components and shrink-wrap Android applications
Developing with Android
Getting started with Android, for any type of application, is a snap. You can download the Eclipse plug-in for the Android SDK (Figure 3) for Linux, Windows and MacOS from http://www.android.com. You can also acquire commercial tools from Mentor Graphics, MontaVista, Viosoft, Wind River and others. The core tool kit is chock-a-block with resources and capabilities to leverage the display surface, input methods, multimedia, wireless networking and cutting-edge peripherals like GPS and accelerometers. Especially popular are class libraries for location-based applications, like Google’s Geocoder.
Even inexperienced developers can become productive in just a few hours, with abundant online examples, tools and tutorials and a plethora of printed primers from a number of publishers. Developers can immediately execute resultant code on a hosted emulator, on the Android Development Platform (ADP) hardware or on HTC G1 handsets.
Targeting actual non-mobile hardware is still a bit more involved. Refactored versions of the Android emulator are available from a variety of public sources and are included in tool kits from commercial suppliers targeting non-mobile Android applications (Mentor, MIPS et al.). Android BSPs exist for a range of CPUs and board types, primarily sourced from semiconductor manufacturers and their tools and services partners.
Migration to Android
As tempting as developers find a blank slate, OEMs will usually need to preserve legacy investments in application code and middleware. A number of vectors exist for migration to Android, each with its own advantages and challenges. As concerns Java source code, core application code conforming to common profiles and JSRs can be easily recompiled to execute on Dalvik. However, the Android UI, surface manager, etc. are not readily compatible with legacy Java-based frameworks like AWT and Swing.
In theory, multimedia code and other middleware written in C and C++ could be integrated into the Android stack “below” Dalvik-based application-enabling code. Regular Android applications could then access legacy and new functionality via the Dalvik Java Native Interface (JNI) or via purpose-built class libraries, but not directly. A good example of this kind of hybrid exists in a project to support gstreamer-based multimedia applications on Android. Additionally, hardware interfaces already running on Linux will integrate easily at the bottom of the Android stack. If the interface class already exists within Android, then new devices should be accessible as instances of existing interface classes. Completely new peripherals, however, will require unique binding and representation within the Android platform.
If you need to preserve legacy code intact and/or you don’t want to “reach under the hood” in Android, then embedded virtualization might be interesting. With embedded virtualization, Android resides and executes in its own virtual machine, as do one or more entire legacy application stacks. Legacy code and Android communicate via hyper-APIs and IPCs, letting OEMs selectively migrate functionality from one environment to another. Vendors like OK Labs, VirtualLogix and VMware all support Android as a guest OS—OK Labs even has a shrink-wrapped, paravirtualized version of Android called OK:Android. KVM and Xen could also support such configurations for x86/Intel Architecture today, and embedded architectures in the future.
An Application Marketplace Beyond Mobile
An attribute of both successful mobile platforms (like iPhone) that is missing from legacy embedded platforms is an applications marketplace. Historically, RTOS-based embedded systems design did not distinguish between system code and differentiating application programs. For all intents and purposes, the device was the application.
The arrival of embedded Java, Linux and embedded Microsoft offerings highlighted the distinction between embedded platform code and applications as software entities, but did nothing to provide a channel for in-market (post-load) application distribution and deployment. Like RTOS-based devices that preceded them, most Java, Windows and Linux-based intelligent devices are deployed, utilized and retired with the same software load present on them as when they left the factory.
Android, like the iPhone and a number of iPhone wannabees, is an application platform par excellence and supports the marketing and deployment of after-market applications through its own online app store—the Android Market (http://www.android.com/market/). While not yet as well-stocked and frequented as the Apple equivalent, the Market boasts thousands of off-the-shelf applications. Unlike the Apple equivalent, developers can leverage the Market without the gauntlet of vendor approval, or can also source productivity software, utilities, games and other applications through alternate channels, including direct sales/download.
The very existence of the Market, as both a channel and a deployment capability, is attractive to a range of OEMs beyond mobile: consumer electronics OEMs can launch platforms with a ready supply of games and multimedia software and content, as can other manufacturers building mass market end-user devices (e.g,. automotive, home automation). Narrower and more restrictive vertical markets have the option of leveraging Android Market infrastructure to build their own app stores that conform to segment-specific paths to market and requirements.
Many vertical application and non-mobile device types will be able to run existing software as is from the Android Market: Dalvik byte-code will execute, in theory, on all devices deploying Android, regardless of underlying CPU architecture and in many cases independent of screen size, resolution, input type and method, etc. Other segments will not able to reuse COTS Android mobile apps. Those verticals will require re-spins of existing applications or entirely purpose-built new ones, but will surely be able to leverage the same channels and infrastructure as mobile.
The expansion of the Android platform into non-mobile areas is cause for celebration by both OEMs who will deploy the platform and application developers embracing it. OEMs will enjoy previously unimaginable market pull as their previously isolated devices are able to run off-the-shelf applications with minimal incremental investment. OEMs can also look to a large and dynamic developer ecosystem, avoiding the cost and risk of trying to create compelling new developer programs and engage in expensive push marketing. Individual application developers and larger ISVS, for their part, will find larger ready markets for their wares as increasing numbers of intelligent devices and device types are able to run Android applications.
What started a mobile phone OS may be poised to reinvent embedded software development. The budding success of Android certainly builds on the wide acceptance of embedded Linux and other open source software in intelligence devices. However, Android, and the concept of a channel-enabled application OS, goes beyond the horizontal development and deployment success of Linux alone. And, while Android momentum and scope are impressive, the platform and its promoters must still avoid architecture and brand-based fragmentation to compete both with sexy platforms like iPhone for wireless/handsets and with legacy software in embedded applications beyond mobile.