TECHNOLOGY IN SYSTEMS
Embedded Java and Android
Android—Google’s Mobile Platform and its Capabilities for Embedded
The universe of embedded applications for Android is rapidly expanding, and the technical evolution of Android is meeting the needs of embedded developers. Still, there are remaining gaps in performance and other capabilities that are needed to address a wider swatch of embedded application types.
BILL WEINBERG, LINUXPUNDIT.COM AND OLLIANCE GROUP
Page 1 of 1
Google Android deployment has been rising steadily since the introduction of the mobile/embedded OS in 2008. While most adoption has centered on building smartphones and more recently tablets with the Google applications OS, Android presents embedded developers of all stripes with a feature-rich low-cost platform, replete with 200,000+ ready-to-run applications.
Of equal importance is the state of Android IP (intellectual property). While the Android platform and shrink-wrap applications in the Android Market build on Open Source Software (OSS), the realities of working with Google in the mobile/wireless ecosystem increasingly involve closed technology and a closing ecosystem around it.
Expanding Application Space
Android got its start and to this day enjoys its greatest success in mobile handset designs. As of Q2 2011, 250+ models of Android-based phones have been deployed in mobile marketplaces from North America to Europe to Asia and beyond. While focused on smartphones, Android has benefited from work by a broader coalition of silicon suppliers, integrators, “commercialization” services providers and individual developers, such that today the platform is increasingly useful for building a range of device types.
Google’s response to “untutored” use of Android on these types of devices has been:
- Releasing the Linux-based Chrome OS, first as a free-standing platform, and more recently in partnership with device OEMs as a preloaded device OS
- Forking the Android code base for tablet designs
- Holding back release of source code to Android 3.0 to give OHA members and select OEMs more time to create better integrated tablet-type products
The release of Android Honeycomb to (select) OEMs will hopefully result in shipment of Android-based tablets with capabilities beyond the current crop of devices like the Motorola XOOM and Samsung Galaxy—maybe even real competition for the Apple iPad.
The first vision for “Android beyond mobile” focused on building devices for the digital connected home—set-top boxes (STB), digital television (DTV), digital and personal video recorders (DVR/PVR) and Internet TV. To support these types of applications, MIPS Technologies and Android Commercialization companies have optimized the Android Dalvik virtual machine for the MIPS architecture and provided device drivers, CODECs, etc. for MIPS-based hardware. More experimental equivalents also exist for other processors.
Android is enjoying a number of design wins for In-Vehicle Infotainment (IVI). While Genivi and its member OEMs have selected native Linux-based platforms (MeeGo and Ubuntu Mobile, Mentor, MontaVista and Wind River embedded Linux), several Asian device OEMs are building after-market GPS and other IVI systems using Android, especially for connected IVI systems with traffic reporting and other two-way communications beyond satellite-based positioning.
Two years ago, FreeScale and Mentor Graphics announced support for Power Architecture in Android, specifically to target applications in networking and network appliances, storage, printing and imaging, multimedia and industrial control. While not really “blessed” by Google, ports like these mean that in theory at least, Android will find design-wins spanning the gamut of embedded and industrial computing.
In its relatively short three-year history, Android has evolved dramatically, with a staccato release cycle spanning three major releases and a fork. Table 1 recounts the history of the platform, with a brief summary of features and special attention to the version of the Linux kernel underlying the Android stack. Another way to look at the Android release history is to track contributions from Google and community sources, and how parallel development branches relate to one another (Figure 1).
Android and Embedded
Android is extremely attractive to embedded developers because of its functional richness, with capabilities dwarfing practically all RTOS-type platforms, and a full application framework more complete than embedded Linux toolkits.
Android strengths lie in the area of supporting user applications and selectively exposing underlying capabilities today associated with mobile/wireless functionality—it’s a smartphone OS, after all. Smartphones aggregate an impressive array of functions in a small package, but are not necessarily representative of the gamut of intelligent devices. Let’s examine a few requirements that typically characterize device applications in areas beyond mobile, and how Android meets those needs as shown in Table 2.
Android and typical embedded device requirements.
Android IP – Open or Closed?
The original excitement over the Android platform and an attribute of its ongoing success is the ostensible open source nature of the platform and licensing of the project code. Superficially, Android does appear to be an open source project as indicated by the top-level use of Apache 2.0 license and the underlying open source components including the Linux kernel, BSD libraries, SQLite, Webkit, etc. In addition, the software development kit (SDK) is based on Eclipse and there is an enthusiastic worldwide developer community.
However, a closer examination of the inner workings of the Open Handset Alliance (OHA) and the Android “project” reveals greater complexity as well as troubling signs of an increasingly closed and proprietary OS and ecosystem. Yes, there is an open source license in use, but the top-level Apache license does not cover all code in the platform. There are many other open source licenses involved—19 to be exact—and there is also proprietary code. In addition, not all versions of Android are generally available in source form, e.g., Honeycomb.
The OHA itself is not an open, merit-based community because membership is by invitation only through Google and the OHA member companies. This means that the uptake of patches and other input from non-OHA submitters is limited or zero. In addition, OHA members are required to sign an anti-fragmentation agreement (AFA), and the contents of that document are under NDA.
The Android Market and Applications are not exactly kosher open source either. The included “hygiene” apps are not all open source, and app developers are increasingly subject to Google oversight (e.g., the recent ejection of two ISVs with gaming emulator apps). In addition, OHA members are discouraged from building their own app stores.
Anyone familiar with working in actual open source communities will immediately perceive how Android is more open in name than in practice. For readers less familiar with open source best practices, it is instructive to hold the Android project up to the standard Open Source definition created by the Open Source Initiative (opensource.org) as laid out in Table 3.
Android vs. OSI Open Source definition.
The Oracle Suit
Android, like many mobile platforms before it, provides a virtual machine execution engine (Dalvik), similar to Java. When Google launched Android, they stated that the re-implementation of Java was necessary for technical reasons—claiming “Java is broken.” At the time, Java IP owner Sun did not pursue the matter, and chose instead to promote authentic “Coffee Cup” licensed implementations and its own mobile platform JavaFX Mobile to compete with Google’s new mobile OS. Fast forward to 2011—Sun is now a division of Oracle, Google’s stalwart competitor and a fierce protector of its IP portfolio, including Java.
In 2010, Oracle initiated legal action against Google for copyright violations and patent infringement, and in 2011 many of the particulars of the suit were disclosed to the public. Analysis of the claims seems to reveal that several counts regarding patents indeed have merit. Without a strong patent portfolio for counter claims and cross licensing, Google is exposed to damages, and Android deployers will likely have to foot the bill for run-time royalties—$5.00/copy or more, according to one analysis.
This legal challenge won’t soon topple Android from its mobile leadership position, but it will likely make it more expensive for OEMs to build “mass market” smartphones from it. So much for free software and free beer in one cute green container!
Certainly, Android is not ideal for all types of device designs. It presents a dazzling array of features and capabilities for mobile/wireless devices and an attractive OS option for other intelligent devices. In particular, Android is a viable alternative for designs that benefit from a graphical user interface, field-upgrade capability, a complement of ready-to-use applications, and both Java-style and native C/C++ run-times. It is a less attractive choice for
- Headless devices
- Devices with extremely limited RAM and persistent storage
- Closed-box designs
- Legacy support for RTOS APIs and other specialized interfaces
- Systems with pervasive hard real-time / low-latency response needs
- Designs built on “minority” CPU families or special-purpose silicon
I have encountered development teams building applications of these outlying types who nonetheless favor Android as option. Enthusiasm for the platform is so great (as it was for embedded Linux) that Android is often deployed not because of its attributes, but in spite of them.