I got the opportunity to talk with Sébastien Ronsse, Solutions Architect and seven-year veteran of embedded systems development with Adeneo (www.adeneo-embedded.com) about Android, embedded systems, and its challenges and opportunities. Ronsse works with companies who have questions about the best technologies to choose for their embedded applications.

Android overview

Android can be best thought of as a software environment that sits on top of Linux. Android has grown from its "API layers" start into an entire ecosystem. Android can be thought of loosely as its own distribution of Linux. The goa of Android is to allow the developer to easily create an entire product with all the packages you need for specific applications. Ronsse mentioned that there are an increasing number of customers coming to Adeneo and asking about Linux versus Android for their application. Ronsse mentioned choosing Android makes sense in some areas, but isn't always recommended.

"If you have a simple product with a small set of fixed functions, Linux makes more sense," Ronsse says. "Embedded environments that want to host multiple applications that need a nice shell with lots of eye candy and ready-to-use telephony, Wi-Fi, Bluetooth, and GPS are where the Android sweet spot is. These days, even embedded devices in industrial, medical, and automotive environments are expected to be interacted with in a similar manner to the smart phone. We all respond to paradigms we know and the smartphone has become a significant influence in our device interaction preferences."

The new Android version requires higher horsepower processors, so the ARM Cortex-A9 is usually preferred. Google selects a particular kernel version of Linux for Android. The Android Open Source Project (AOSP) becomes the starting point for all other Android distributions.

Think of Android's distribution as providing layers on top of the Linux baseline. The first layer consists of the native C/C++ libraries, SQLite database, Webkit (the browser rendering engine), along with OpenGL/ES for graphics rendering. The layer also includes the Android Runtime (ART) – Google's version of the Java Virtual Machine (CM).

"ART is what allows Android apps to run – the heart of Android – it's a virtual machine," Ronsse says. "Google developed a framework on top of Java which can be leveraged by developers – a location manager, a window manager, a resource manager, etc. Then on top of that there are some stock applications from Google – a default shell, contacts, and browser for example. Then of course with this run-time you have all the downloadable Android applications at your disposal."

Android is geared toward tablets and smartphones. Additional development advantages are that the application is portable and you can literally use your smartphone or tablet as your target machine for development. As more people develop for Android, familiarity with the APIs become more commonplace resulting in faster development.

Android for industrial

Android platform development is like any other porting of an operating system – it's not necessarily straightforward. Custom hardware designs require a port of Android to that platform. One option is to start with a platform design that runs Android, then adapt the platform and do an incremental change, but it depends on the embedded hardware needed.

Industrial, medical, and auto embedded systems need connectivity, I/O, or interfaces that probably don't have standard support in Android. In this case extending Android is required. If you're familiar with Linux, accessing hardware is typically done by opening the right driver node and communicating through the filesystem. But in Android you can't do that. The middleware portion of Android must be extended so you can make sure the application can talk with the hardware through the proper middleware/OS stack. Unfortunately, this is not straightforward or well documented.

"Five years ago when we started working on Android, it was hard to find where to start. We struggled to understand the architecture and there wasn't much documentation. Everything that was available was application development oriented, not the internals and architecture," Ronsse says.

Years ago this required looking through the internals to understand how it worked. Ronsse referenced the "Embedded Android" book by Karim Yaghmour, a good reference for Android platform development.

Silicon vendors are now providing porting guides for Android making embedded development easier. This provides more information, but still requires a learning curve, support, maintenance, and access to embedded systems experts to complete the work.

Specific to industrial control, the big factor is connectivity for M2M. Users are expecting to arrive in the industrial environment with their smartphone or tablet and securely connect to the industrial systems to get status via Bluetooth or Wi-Fi. These specific services are provided by Android, which makes the environment a good choice.

Headless embedded systems

Ronsse mentioned that you rarely see Android without a screen. Headless devices aren't popular for Android and the environment is not designed to work without a screen. However, there are projects out there that have customized a version of Android that will operate in a headless environment. Gary Bisson, also working at Adeneo Embedded, has successfully demonstrated this scenario at the Android Builders Summit.

Medical devices are becoming increasingly multi-function. These devices need multiple applications to record notes for patients, sensor recording, and patient vitals measurements. In this kind of environment where one device runs multiple applications, Android is a good choice with its shell and ability to load and run a variety of applications. You don't have to be an embedded expert to create an application that can be attractive in the embedded systems environment.

Traditionally, Java was the language you wrote in for Android. For embedded development, there may be a need for C/C++ to accommodate legacy code. The Android NDK supports C/C++ so that makes porting legacy code easier.

Embedded Android example

Many Android embedded projects tend to be adaptations. One Adeneo project involved a tablet design for restaurants where you can browse the menu, select a meal, play games while you wait, pay with a credit or debit card, and print a receipt on the tablet device at the table. Much of the tablet leveraged pre-existing capabilities and applications, but adaptations needed to be done for the card swipe, point of sale transaction, and receipt printing.

The porting starts with the creation of a custom boot loader. This is the initial program run by the processor. Then drivers needed to be developed for the card swipe and printer mechanism. Once these low level drivers are completed, the middleware layer of Android needs to be extended to expose these new services to the application layer. This requires the creation of a special Android SDK for the platform.

While the Android adaptation work was being done, the company could develop their restaurant application. APIs were defined for the credit card calls and printing so the application could implement them and simply stub out those calls until the platform was ready.

Processors, development, and debug

Processor support for Android is not as sparse as you might think. Of course the companies that support ARM cores (such as Freescale, TI, NVIDIA) support Android. Ronsse mentioned that Altera and Xilinx also have integrated ARM/FPGA chips that run Android. We are also starting to see x86 solutions that Intel is now actively involved in.

As you might expect, Linux-based development is the preferred environment for the lower Android layers while Eclipse and other Java-oriented IDEs can be used for application development on Windows, Mac OS X, and Linux. Application debugging is done via USB and ADB (the Android Debugger). When you enable Android debugging, you get access to a number of tools for application development. System tracing is also available that allows insight into the various threads of execution with HTML output providing a nice summary of the tasks for diagnosing races or problem areas.

Will Android sweep the embedded community like Linux has? For applications needing wireless connectivity, Bluetooth, and a familiar user interface paradigm, Android may fit. However, for applications that don't use these kinds of graphics and connectivity extensions that also have higher performance requirements, it may not make sense.