Download Android – At Last A Ubiquitous Embedded OS

Android – At Last A Ubiquitous Embedded OS?
The Android operating system has established itself in a vast number of mobile devices. Now developers
are eying expanded application possibilities for this dynamic software. Here is a survey of some of those
attractive, but uneven, possibilities.
by Bill Weinberg, Olliance Group (A Black Duck company) and LinuxPundit.com
This article is the third in a series written for RTC discussing the potential and reality for
developing and deploying embedded systems using Android. The first, “Android Moves Beyond
Mobile” (RTC September 2009) introduced the then-outlandish idea of using the mobile OS to
build intelligent devices beyond its core domain of mobile handsets. The second, “Android—
Google’s Mobile Platform and its Capabilities for Embedded” (RTC July 2011), highlighted the
expanding application space for Android but also examined the gaps in its capability set for
many types of smart devices. We now continue the discussion, paying specific attention to the
progress of the Google mobile OS and to both actual and potential inroads in specific markets
and applications. These domains include those listed in Table 1.
Automotive
Automotive systems break down roughly into two broad categories: critical systems control and
in-vehicle infotainment (IVI). The first addresses core functions and safety critical operation in
engine/ignition control, anti-lock braking, steering, etc. and is the domain of RTOS-type
platforms with small resource footprints. The second, IVI, encompasses smart dashboards, GPS
devices and “head units” that integrate these and other functions in a single box. It is these
application that today garner attention in the press and in the boardrooms of automotive OEMs
and the Tier I suppliers that serve them, because these IVI systems increasingly define and
differentiate the vehicle occupant experience.
A consortium of the leading OEMs and Tier I suppliers, Genivi, was launched in 2009 by BMW,
Wind River, Intel, GM, PSA, Delphi, Magneti-Marelli, and Visteon, to “foster a vibrant opensource IVI community” by delivering an open-source platform consisting of Linux-based core
services, middleware, and open application layer interfaces, and by engaging developers to
deliver compliant applications. Originally building on MeeGo, Genivi today supplies an open
specification, with a range of compliant platforms from OSVs and community sources.
To some degree Android is the “competition” for Genivi and also for GM OnStar systems (based
on QNX), but to date primarily in aftermarket applications – GPS devices and media systems
like the Clarion Mirage. One exception is the IVI system in Renault Clio and Zoë vehicles.
So why isn’t Android coming to an OEM dashboard anytime soon? Basically, it’s an” impedance
mismatch.” For one thing, Android releases come too often for the conservative automotive segment and
its 5- to 10-year design cycles. The other is that despite efforts from both handset makers (Motorola
Cliq/Blur, HTC SenseUI, etc.) and from OSVs with add-on UI products (FST FancyPants and
Mentor Graphics Inflexion), automotive OEMs seek a truly differentiated user experience (UX).
Therefore they have set their sights “lower” in the stack for a common platform, ensuring that
each vendor/vehicle platform will be unique and making cross-brand application interoperability
unlikely.
There is, however, another path to market for Android in IVI. OEMs and Tier 1 suppliers are
looking at cutting costs through processor consolidation in their head-unit devices, in particular
onto ARM and IA silicon. Enabling the integration of IVI, CAN and MOST stacks on a single
CPU will likely be embedded virtualization technology (from OK Labs, Wind River and others).
With Genivi, AUTOSAR and legacy RTOS stacks living in virtual machines (as “guests”) on a
single piece of silicon, adding Android to run apps from Android Play becomes a snap.
Consumer Electronics
Consumer electronics manufacturers, primarily in Asia, have embraced Android for nextgeneration digital TVs, set-top-boxes, DVRs, media players and other CE devices. Many of
these devices are built on the MIPS architecture, and MIPS Technologies and their partners have
invested substantially in optimizing Dalvek to run well on MIPS—a 4 to 5x speed-up, according
MIPS marketing—and in creating reference implementations.
With good support for ARM and MIPS and other relevant hardware, consumer electronics as a
segment has enjoyed the most success with Android beyond mobile. A quick glance at the CE
retail space reveals announcements of Android-based TVs, IPTV boxes, media players,
controllers and other products from LG, Motorola, Philips, Samsung, Sony and Vizio, as well as
lesser-known brands.
Enterprise IT and Office Automation
Over the last decade, Linux has won countless designs in both enterprise networking (routers,
access points, firewalls, etc.) and in office automation (printers, copies, MFPs). Most of these
systems are closed devices – they support field upgrade (reflashing) but not unconstrained
download of new applications and functions in the manner of Android-based smartphones and
tablets.
Android is finding its way as a general purpose embedded OS into this design domain, primarily
by manufacturers wanting to leverage Android’s Java programming model and increasingly
familiar GUI. But not for enabling users to download and play Angry birds (or even more useful
apps) on routers and copying machines.
Enterprise IT (EIT) is leveraging Android as a platform for Enterprise Mobility – to deploy
internal apps and enhance mobile worker productivity by giving them access to enterprise assets
in company data centers and in private and secure public clouds. This BYOD (Bring Your Own
Device) paradigm lets EIT staff add software to employee-owed Android devices to enable
remote productivity and ensure the security of business-critical data.
Numerous vendors of Mobile Device Management (MDM) and mobile virtualization solutions
offer Android-based EIT mobility software, ranging from application-level sandboxes to thin
clients to virtual machine platforms to multi-function MDM suites that provision, manage,
monitor and even wipe Android-based devices
Defense and Aerospace
In theory, Android and Android-based devices fit the increasing trend for acquisition of COTS
solutions by military, government and civilian aerospace contractors and users. In practice, the
development and deployment profile of Android in Aerospace and Defense (A&D) has
encountered several key limitations important to military and aerospace—security and
certifiability.
In terms of security, Android, at least in its mobile incarnation, is notoriously susceptible to
exploits of all types: ranging from zero day attacks, process-level denial of service, API and
document-based exploits, malicious apps in standard app stores, especially Google Market and
Android Play. Moreover, the Android platform includes native encryption, and while securityminded integrators and OEMs could certainly deploy stronger measures, many apps and much
third-party-ware blithely employ native encryption methods like secure sandbox apps.
In addition, Android, starting with the underlying Linux kernel, bionics libraries and going right
up through the rich Android m/w framework, is too large, complex and dynamic to pass current
certification regimes such as Common Criteria EAL and FIPS 140-2. Such disciplines are
optimized for code bases of 10-15K lines of code, although Linux-based systems have undergone
EAL4+. However, the total Android stack size numbers in the tens of millions of lines of C and
Java coming to approximately 6 GB of source code in total.
As with EIT use of Android for enterprise mobility, A&D (and government IT too) is looking to
virtualization to facilitate development and deployment of Android devices and applications.
Full hypervisors and less feature-rich separation kernels address both the above concerns by
presenting a much smaller code base, streamlining certification and offering a diminished “attack
surface” to malware as with the NSA’s High Assurance Platform “HAP”.
The use of Android in so-called “superphones”, smart radios and other hardened
communications devices, responds to the same requirements as EIT BYOD: let service
personnel carry a secure single device with a friendly and familiar user experience for regular
communications and “military grade” security for mission-critical messaging, voice and data
transport. This paradigm also serves to cut costs in line with COTS procurement policies. Reflashing or special ordering COTS Android handsets and tablets with High Assurance firmware
and middleware developed by integrators and government contractors is orders of magnitude less
expensive than developing, deploying and maintaining traditional equipment.
Industrial Control and Instrumentation
Industrial control and instrumentation systems seem the least likely of candidates to be powered
by Android, and yet developers are seriously considering using Google’s mobile OS here as well.
For nitty-gritty control applications, they are mostly building native applications and drivers on
the Linux kernel that lies underneath Android. The Java execution engine (Dalvik), while
boasting excellent performance, is not particularly well suited to latency-sensitive control and
sensor applications, although it is more than sufficiently able to communicate with dedicated
hardware modules to perform those functions.
Where Android really comes into play is in creating the control panels and operator interfaces to
program and run control and instrumentation systems. Developers are drawn to using Android
for both communications with dedicated control/instrumentation hardware and with “back
office” resources. The attractive and familiar user interface, rich complement of services and
middleware, and integrated networking make CTOS Android-based devices and custom interface
devices ideal to support both control and instrumentation apps.
Medical
Medical monitoring and treatment devices based on Android face comparable challenges to use
of the Google mobile OS in A&D – certifiability and security (privacy). But the attraction of a
platform that comes ready-to-use with hundreds of medical apps, touch screen support,
networking and other must-have capabilities is overcoming those key limitations. Just as Linux
did before it, Android is making its way onto medical systems for diagnosis and monitoring – not
life-critical, but those that confer convenience and a friendly user experience to clinicians and
patients alike.
Suggested medical device applications for Android include hospital room patient monitors,
remote monitors and surgical displays, portable medical records input/display devices,
pharmaceutical dispensers and scanners – anything where user interaction is paramount.
Another area that has faced certification issues is out-patient monitoring equipment. To some
extent, suppliers have side-stepped the issue by creating apps and mobile-phone add-ons for
COTS Android phones, letting patients automatically report their vitals and long-term test data
over 3G and 4G mobile networks.
In the higher-stakes area of therapeutic and imaging devices, medical OEMs are following the
same path as their peers in industrial automation – use Android devices with built-in displays as
front-ends to certified proprietary devices requiring certification from the FDA and other
regulatory bodies. And in scenarios where even separate displays face certification, OEMs
obtain it for a single common design destined for re-use across a range of life-critical systems.
Is Android the Right Choice?
Despite its expansion across the segments described above, Android is still probably not for
everyone. Whether Android fits your particular intelligent device application will depend upon
the unique combination of considerations endemic to your business and your particular project.
The follow table calls out arguments For and Against with rationale teased from across
application segments and the particulars of the platform. See the sidebar on arguments for an
against Android.
The sheer number and scope of arguments against using Android beyond mobile might in the
future doom the little green robot to be consigned to smartphones and tablets. However, the
smaller set of For arguments is quite compelling and our verdant friend is marching across the
field of device applications with no signs of pause or retreat. Like I used to say for embedded
Linux, the Google Android OS is finding broad deployment not so much because of its
attributes, but in spite of them.
Olliance Group. [www.olliancegroup.com]
Linux Pundit. [www.linuxpundit.com]
[Sidebar]
Arguments for and Against Android
Arguments for Android
 Ubiquitous – Android is increasingly
ubiquitous, and so is the expertise to develop
systems with and apps for it. Furthermore, it
leverages an even larger global community
of developers already fluent in Java and
other programming disciplines.
 Open Source – with the release of Android
4.0, the OS is generally considered to be
“open source” (again), giving OEMs the
ability to customize and enhance for a range
of new application domains.
 OEM-Friendly Licensing – OEMs have in
general made their peace with license
compliance when deploying the GPLv2
Linux kernel. Far more forgiving (“liberal”)
is the Apache 2.0 license that applies to the
majority of Android code, letting OEMs
modify and redistribute with minimal
disclosure requirements.
 Linux – As of Q1/2012, Android no longer
forks Linux. Instead, changes unique to
Android have been merged into the
kernel.org tree under a special architecture
branch, assuring that the core of Android
will track mainstream Linux evolution.
 Paravirtualization – since the underlying
Linux kernel and hardware-dependent parts
of Android are supplied in source, the
platform can be paravirtualized for execution
on processors with hardware virtualization
support. This capability offers developers
and OEMs the option of addressing some
Android shortcomings (security,
performance) by running the OS as a guest
of a hypervisor, alongside more secure
and/or higher performance software
(including vetted instances of Android
itself).
Arguments Against Android
 Size – Android is too large in both source
and binary forms for many application types.
Its massive source base is too large to certify
and the derived binaries can outstrip the
resources of smaller embedded designs.
 Overkill – Android, between the kernel,
application framework, and including
“hygiene” apps is far richer than many
(most?) intelligent devices need. Strip out
the apps and sections of the framework and
it’s not “Android” anymore – not all apps
will run, etc.
 Application Architecture – the Android
programming model is optimized for
building mobile handsets (i.e., Activities,
Services, Broadcast receivers and Content
providers). While that model can be
stretched and bent to fit other paradigms,
Google’s OS is still at heart best suited for
smartphones (and maybe for tablets).
 Performance – while the Dalvik run-time
engine has been optimized for most silicon
architectures, Android is still fairly “heavy”
and can overwhelm modest processors and
lean memory systems, as evidenced by
sluggish system response and sub-par
application performance on low-end (single
core) handsets.
 Real-time – Android, like Linux, in its
unadulterated form has somewhat limited
real-time response capabilities. That being
said, most embedded applications don’t
really have particularly stringent latency
requirements. When they do, there are many
means to meet those requirements, including
“ugly” shortcuts around standard system
mechanisms (true for Android and true for
many legacy RTOSes as well). One area of
Arguments for Android
Arguments Against Android
concern for latency sensitive systems is
Android power management, whose
aggressive sleep states of course degrade
responsiveness. It can be disabled, of course.
 Security – Android native security
combined with both vulnerable and outright
malicious apps presents a grim picture for
security conscious developers and deployers
in general. However, it is probably no worse
(and likely better) than many/most legacy
RTOSes and other platforms it replaces.
And, Android’s global developer community
makes aggressive efforts to patch and update
to address known exploits and other threats.
 Reliability – Users report that Android
phones crash a lot. One study reported that
low consumer satisfaction drives Android
device return rates as high as 40%.
Reliability is paramount to intelligent device
design: not all applications are mission-,
safety- or life-critical, but even a failed toy
or fun gadget can be business-critical to its
manufacturer and distributors.
 Forking – the flip side of liberal (Apache)
licensing is that developers and deployers
can customize Android beyond recognition.
Forked Android implementations are fine for
closed box systems, but a major selection
criterion for the OS is its ample and growing
portfolio of 400,000+ apps in Google Play
(a.k.a. the Android Market). If open devices
can’t run a significant number (or they run
badly), then the whole ecosystem suffers.