It’s happened before. The development of a compelling operating system and/or software system envisioned for purposes unrelated to the unique needs of embedded and real-time systems was so attractive that embedded developers would not rest until they had adapted it to their particular needs. Among the examples are WindowsCE, Linux and Java. Now it looks like a similar movement is afoot and the target is the latest mobile operating environment, Android.

Despite the fact that Android is familiar to most users of smartphones and tablets, relatively few are aware of what it actually is. That’s because the way its creator, Google, conceived it is now being subjected to alternative interpretations by people who see aspects and advantages to it beyond Google’s original intentions. According to Google, “Android is a software stack for mobile devices that includes an operating system, middleware and key applications.” And that is quite true as far as it goes, but those poking around under the hood are discovering aspects that with a good deal of effort can be harnessed for other applications—among them certain classes of embedded systems.

Of course, Android is based on an operating system, Linux to be specific, and it definitely has a graphical user interface (GUI) and a complete Java Virtual Machine, which is intended to be its programming and application development environment. Applications written in Java are intended to be portable across all Android devices and these devices are also web-enabled. In addition, it was originally implemented for the ARM architecture because no matter how universal a software system tries to be, it still has to run on a particular hardware platform—at least initially. The underlying layers of Android (the Linux layers) are targeted at supporting specific aspects of ARM-based hardware platforms through a middleware application framework that defines certain resources such as touch screen, USB, camera, compass, GPS, etc.

Porting Android to a new ARM-based platform is not a trivial undertaking, but moving it to a new processor architecture with elements and devices not recognized by the application framework involves a major effort. Art Lee of Viosoft, which has undertaken a number of such porting projects, points out that Android consists of some 15 million lines of code and only about 1 percent of that is assembly code, which is ARM-specific. Still, Lee notes, that is about 150,000 lines of assembly code. Linux, of course, is mostly compiled from C code. Viosoft has ported Android to the MIPS architecture and has recently demonstrated a port to the AMD G series, bringing it into the world of x86.

These efforts all required a large amount of native development in Java, C/C++ and native (assembly) code because Android is inherently multilingual (Figure 1). Since Android was conceived and developed for the mobile market, developers who wish to take it to other devices such as set-top boxes, medical devices or even industrial control, are on their own. Viosoft, however, has come up with a porting kit that includes a reference Linux kernel distribution and a reference port of Android to selected embedded platforms.  These ports can be used as a starting point along with a version of Viosoft’s Arriba debugger that gives visibility to the different layers of an Android system including the Java virtual machine, Linux and even device drivers, and can work in Java and C/C++ as well as in native assembly code (Figure 2).

Figure 1
Android is multilingual because different sections are implemented in different coding languages from assembler to C/C++ and Java with additions of XML.

Figure 2
The Viosoft Arriba debugger for Android is able to display and analyze the different layers, sections and languages that make up Android with a single target connection.

For embedded developers, this multilayer access is vitally important because although Google encourages all apps to be written in pure Java, that cannot satisfy the performance requirements of many embedded applications. Therefore, two things are needed: First, the ability to create additional elements such as specialized device drivers, which must be implemented in C or assembler. Second, there needs to be a mechanism for Java applications to communicate bidirectionally with this custom code. Very often this is done using the Java Native Interface (JNI), but it can also be done with such mechanisms as the Common Object Request Broker Architecture (CORBA).

With this level of complexity and more, one might reasonably ask, what is the attraction of Android that makes all this worthwhile? The immediate answer might be that it is the GUI, but Android is more than a GUI. It is also on the Java level an execution environment. However, once it is ported to a nonstandard processor/hardware environment, it remains an execution environment, but one that can run more specialized applications such as medical data acquisition. In such a scenario, many of the widely available Android apps will run on such an embedded system, but the ones that take advantage of its unique resources will run nowhere else.

There is a cultural element at work here as well, due partly to the proliferation of low-power CPUs that integrate very rich graphics processing on chip. This has led to the explosion of smartphones and tablets that are defining how ordinary people interact with important objects in their everyday lives. This in turn has led to the expectations that they should be able to interact in the same way with technology that they work with. Thus, the designer of an MRI machine may wish to incorporate a tablet-like Android user interface because it simplifies the training and interaction of medical personnel, who can intuitively relate to it.

But there is an added advantage. Android is not just a user interface; it is also—even in such a specialized device—a programming environment for Java apps as long as those apps conform to the specialized nature of the device. For example, a piece of medical equipment might have an integrated custom Android environment that includes awareness implemented at the underlying levels of very special kinds of sensors and devices that are presented to the Java environment as APIs. The manufacturer or service provider will have supplied a user interface and set of applications to operate the machine. Later, however, someone could decide that the data and functionality provided by the basic machine’s custom APIs could be used as the basis for additional apps that could be written in Java, take advantage of the available special resources, and enhance the value and utility of the system. But there is no way they would run on a smartphone.

Thus, it is the OEM’s task to get the entire specialized Android system ported to a given platform environment, but additional utility could be supplied by the user or by specialty application developers who target that high-value machine. You could also play cribbage on it.

As previously noted, getting that entire Android Java/Linux/C/assembler stack ported to a dedicated hardware environment can be a daunting task. As Viosoft’s Art Lee points out, “Just remember, it’s still Linux at the foundation.” So the first task in enabling a device with Android is simply to get Linux running on it. Once that is accomplished, there are a number of issues involved with adapting the Android software platform as defined by Google (Figure 3) to work with a non-Google hardware environment. This involves applying patches to Linux that will enable it for Android. Notice by the way in Figure 3, how relatively small the Android runtime with its Google Dalvik JVM and core libraries is in relation to the rest of the whole software platform

The application framework, which in the Google model defines the mandatory services, must be modified to add the custom services for the target application. According to Lee, “If you have a new piece of hardware or a piece of code that isn’t defined in the application framework, you have to find a way to extend the framework for the infrastructure of Android to be aware of that.”

Then other libraries must be brought in, in addition to those referred to as the “bionic libraries” defined in Android. And then new device drivers must be written for the Linux kernel. All the communication mechanisms between these elements and the Java environment must be set up and verified. Mostly, this is done in C code, but there are inevitably instances where performance requires dropping into assembler as well.

This requires a tool suite that can analyze an