Android–Google’s Mobile Platform and its Capabilities for Embedded
Download 15.06 Kb.
|
- Navigate this page:
- Expanding Application Space
- Android and Embedded
- Android IP – Open or Closed
- The Oracle Suit
Android–Google’s Mobile Platform and its Capabilities for EmbeddedThe 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. by Bill Weinberg, LinuxPundit.com and Olliance Group. Google Android deployment has been rising steadily since the introduction of the mobile/embedded OS in 2008. While most adoption has centered on building smart phones 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 increasing predicate closed technology and a closing ecosystem around it. Expanding Application SpaceAndroid 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 smart phones, 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. Almost from the first release of Android platform code, device manufacturers (OEMs) also experimented with using Android as an OS for tablets and netbooks. With the unparalleled success of the Apple product line, OEMs and users of course look to Android-based designs as potential iPad killers, or at least as a way to get some piece of this lucrative market away from Cupertino. Early attempts at building tablets and also netbooks based on Android have proven disappointing, both in terms of user experience and commercial impact. Google’s response to “untutored” use of Android on these types of devices has been
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. nother 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 strengths lie in the area of supporting user applications and selectively exposing underlying capabilities today associated with mobile/wireless functionality – it’s a smart phone OS, after all. Smart phones 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 IP – Open or Closed?The original excitement over 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” reveal 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 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 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 on-OOHA 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 the to standard Open Source definition created by the Open Source Initiative (opensource.org) as laid out in Table 3.
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” smart phones 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
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. [***Contact Information being negotiated***] Directory: files -> article versions article versions -> High-Octane Distributed Computing Fuels Intelligent Highways article versions -> Development Tools Are Key for fpga soCs article versions -> Mmc management Solution Using actel smartFusion article versions -> Tightly Integrated Devices Yield More Efficient Motor Control article versions -> The Windows Embedded Legacy Continues with Windows Embedded 8 Standard article versions -> Achieving Frictionless Parallel Processing with the Heterogeneous System Architecture article versions -> Editor’s Notes article versions -> Rtc article, October 2011 Final article versions -> The Internet of Things and the Convergence of Networks article versions -> Mobile App Protection (map) for Android Make Mobile Apps "Self-Defending" Download 15.06 Kb. Share with your friends:
|