Alan Levy, with Plextek Consulting, has published an interesting whitepaper that examines various issues associated with embedding Android in applications other than the typical smartphones, tablets, and smart TVs.
In the nine-page whitepaper, “Using Android in your embedded product,” Levy provides a brief overview of Android and its origins, and then proceeds to evaluate its pros and cons relative to applications in the general embedded market.
“Frankly, for mass-market portable devices such as phones and tablets using Android is pretty much a no-brainer unless you’re Microsoft, Apple, Nokia or RIM,” writes Levy. “For other devices (e.g. In-Car Entertainment, TVs, set-top boxes and so-on) the decision is less clear-cut,” however.
He then enumerates a long list of issues — both positive and negative — that should be thought about before making the decision to deploy Android in an embedded application. Among the topics discussed by Levy are…
Some potential advantages:
- Simplifies the development process, producing a more professional end product and quicker time-to-market.
- It’s a sophisticated, highly capable embedded OS with an easy-to-use, familiar graphical user interface.
- Makes it easy to support a wide range of devices, sensors, and software capabilities into your product.
- Customers have heard of it and may already be using it.
- Easy Internet-based access to hundreds of thousands of free and inexpensive apps.
- Anyone with the requisite skills can develop and deploy their own apps.
- It’s highly customizable, allowing developers to modify its behavior and appearance.
- Written in common programming languages, making it easy to find developers who can work with it.
- Available from Google, free of licenses or royalties (however, see first item below).
Some potential disadvantages:
- Certain components of typical Android consumer device implementations involve licensing, up-front fees, per-unit royalties (e.g. Google Services, codecs, etc.).
- It’s built from a mixture of programming languages: Java and C++ layers on top of a customized Linux kernel coded mainly in C.
- Depending on the outcome of ongoing legal battles, using Android could end up requiring royalty payments to third parties.
- Because Android initially targeted ARM CPUs, x86 support is not extensive (but it’s improving).
- Android’s functionality is “spread across a wide range of subsystems,” resulting in increased internal task communications and scheduling overhead.
- Adding a new hardware class can be a complex process when it can’t be handled within an existing Java API.
- Android requires moderately beefy CPU, RAM, and flash resources.
- Android’s power management architecture makes assumptions that don’t always match the applications requirements and capabilities (e.g. boot time, suspend-to-RAM, persistent storage, etc.).
- Hacking Android can be challenging due its large size, lack of adequate documentation in the sources, difficulties of regression testing, etc.
Levy’s complete nine-page whitepaper can be downloaded from PlexTek’s website, here (PDF file).