Successfully connect your Android application with your embedded hardware

Android has established itself as a dominant mobile operation system for consumers in recent years. It is indispensable in the field of applications such as smart phones, cameras, tablets, game consoles and much more. The Android-Software-Development- Kit (SDK) is extensively equipped and offers substantial possibilities for programming complex applications. Based on a complete Linux-kernel, Android is operated by a touch-based user interface. In fact, these are ideal conditions for the development of appealing and intuitive HMI applications in an industrial environment. However, especially in industry, there are further boundary conditions to be considered before Android can be used.

The spread of Android based devices has increased dramatically in recent years.  Due to the associated popularity, the operating concept is very familiar. Everybody can quickly and easily use such a device without extensive training. It’s therefore straightforward to use this concept for other products too.

Besides the classical application areas of Android, like smart phones or tablets, now cameras, televisions and home entertainment systems are equipped with Android.  Even a washing mashine or a household heating control can be equipped with it. The move to an industrial HMI is therefore only logical.

The following shall discuss to what extent Android is suitable for industrial applications and which extensions or adjustments may be necessary to be able to visualize a control. The topics real-time capability and access to process variables are also going to be discussed for this purpose.

Android's biggest advantage is its comprehensive and easy to use application development environment. The libraries provided with the SDK include widgets for graphical user interface, multimedia as well as audio- and video-codecs or 3D acceleration, abstraction layers for input devices, network technologies and of course the classic Java libraries. The integrated development environment Android Studio from Google has successfully replaced the previously used plugins for Eclipse.

Android is a special shaping of a Linux root file system. This means Android is based on a fully equipped Linux kernel and uses its resources (figure 1). Furthermore, the kernel has special extensions in the area of memory management, power management and communication. The Linux kernel is licensed under GPL and the Android sources under Apache 2.0. Product-specific modifications of the Linux kernel must therefore be published; modifications of the Android source code however do not have to be published.

Figure 1: Architecture of Android

Adapting Android to a particular device is a complex multistep process. The starting point is the Android source code, which has been made available by Google with the AOSP (Android Open Source Program) and its multiple git repositories. In addition to this, the Linux kernel source code is required. Both source code packages are generic and usually need to be adapted for the use on a particular SOC. This requires patches from the semiconductor manufacturers. These patches adapt the kernel to the specific properties of an SOC, for example allowing the use of hardware-accelerated multimedia functions. Since different licensing situations have to be taken into account, these patches are sometimes delivered as binary code only. An SOC is installed in modules or devices, so their properties have also to be considered. This mostly results in further modifications by the board manufacturer.

Visualizing processes

The task of process visualization is the preparation and graphical representation of process information. Controls (GUI) are added to be able to manage the process. The process itself can not be implemented under a standard Android (AOSP), as a deterministic behaviour is usually necessary.

Process information is managed in the form of a process image. The control itself and the HMI can access this image. Process information is either implemented directly by the controller via hardware interfaces, or accessed via field buses. This information, like input and output variables and flags, are cyclically and deterministically updated and processed by the control.

Is the process image is implemented as shared memory, the HMI application can access it directly using interface functions, however access conflicts in terms of determinism and arbitration have to be resolved. As Android, or rather the Linux kernel, has no real-time capabilites without any special profound measures, it quickly becomes clear, that the control should be stored in separate controllers and communication interfaces between these controllers and Android have to be implemented. This communication interface could be a serial interface or ethernet. Classic field buses like CAN or profibus are also possible, however, they are not natively supported by Android.

Access to the hardware

As stated above, with Android there is no easy way to access any hardware directly or to communicate via a field bus. This is caused by the lack of drivers and the management of access rights to the resources exported via sysfs.

The system runs with the "system" rights, while the Linux kernel components run "root" rights. All applications and services under Android receive their own UID and GID, and cannot access any kernel or system component at will. You can manage this by assigning the necessary rights to the components during the start and initialization process of Android, or by adding libraries or services to Android, that already have these rights.

Direct access

If you want to implement an easy access to a GPIO (such as an LED), it is sufficient to register and configure this GPIO during initialization. In this case, the following sequence is inserted in the init.rc file:

write /sys/class/gpio/export 123
write /sys/class/gpio/gpio123/direction out
chmod 0666 /sys/class/gpio/gpio123/value

The GPIO port number 123 is activated as an output and anyone has read and write access to it. Under Java it is accessed like a file:

FileOutputStream out = new FileOutputStream(„/sys/class/gpio/gpio123/value“);

Access using a library

In addition to the SDK, there is also a framework named NDK available for Android. This offers the possibility to create dynamically loadable libraries that can be used by Android applications.

Figure 2: Use of NDK based libraries

The implementation of the library functions can be done in C/C++, while the interface to the Java world is implemented using JNI. Inside a Java application, it makes sense to encapsulate the library within a class and to use its methods.

The advantage of this method is the ability to implement the functional part of the library in C/C++ and to use this via a Java class. Through call-back mechanisms, it is also possible to observe asynchronous changes of an input. The disadvantage is that programming errors within a library can cause the application to crash. Furthermore, it is not possible to access Android services from this point, or via the Android SDK respectively. Such a library is assigned directly to one application and cannot be shared by several applications.

Access via a service

For more complex hardware interfaces, such as a fieldbus or an RS-485-based, proprietary communication interface, it may be necessary to access services from Android or to at least use the SDK. A convenient variant is the implementation of a separate service, which is also managed by the Android framework.

The lower layers are implemented similarly to using the NDK approach, i.e. accesses to the hardware are madein C/C++ and a JNI-based interface is implemented for the upper layers. However, this interface is not exported as a generally loadable, dynamic library, but it is used by a Java-made service (Fig. 3).

This service is available within the SDK as a class with its own methods and is thus an extension of the Android framework. However, this results in a dependance of an application on this exact SDK.

As the documentation of Android frameworks is often insufficient, the integration of a new service is considered to be a complex task.

Figure 3: Use of a service within the Android framework

Sensor interface

Android is well connected with its environment, for the current position, acceleration, ambient brightness, touch, mouse and keyboard are intensively used by many applications. For this reason, the so-called sensor framework has been implemented by Google. This unifies the various environmental parameters to a relatively universal interface.  However, the input framework of Linux is used for forwarding these parameters and it is therefore subject to the limitations provided there.

The framework can still be used to forward its own specific sensor signals, or more specifically, its process variables, to Android. An easy way is to create a specific driver under Linux like a mouse driver. Any change of the sensor value can then be reported like a change in the absolute position of a mouse. This "mouse" data can be interpreted accordingly in the Android application.

Android Look and Feel

Unlike a smartphone, which runs on a large number of so-called "apps", a HMI application typically consists of exactly one application. This application must not be terminated or replaced by another application. Furthermore, it must be ensured that noone can access the app-store to install AngryBirds onto the coffee machine, for example. Occasionally, product marketing demands that the use of an Android operating system remains unnoticed at first glance.

These requirements can be met if the developer creates a unique device configuration and uses this during the construction of the operating system. For this purpose there are a number of "mk" files that ought to be regarded as makefiles in the Android build system, and in which the compilation of applications is described. In addition, there are flags that determine the properties of Android. This is complemented by overlay files, usually in xml format, which allow the modification of strings or even the system behaviour.

If you want to add your own services or change the status or navigation bar, for example, it is necessary to get an in-depth understanding of the Android source code. For example, the services and their interdependence can be found in the xxx/frameworks/base/services directory.

It is indeed possible to adapt the Android source code so that only the infrastructure of Android remains. The HMI application can then run on its own within it like a kiosk application. Unfortunately, there is very little documentation and one can expect a long phase of familiarization - or get help from a specialist straight away.


On the one hand, real-time applications for controls are currently not feasible under Android, on the other hand it is possible to comfortably implement HMI applications. Special measures must be taken in order to access process information, such as the implementation of libraries on the basis of NDK right up to special services. Android can be configured so that only one application is running actively and the operating system is not recognizable.

These tasks are not trivial to implement and unfortunately there is little documentation available. However the gain is an intuitively operable graphical interface, that users can handle without  extensive training - market acceptance will be correspondingly high.



[3] „Embedded Android“, Karim Yaghmour, O’Reilly, 2013.

[4] „Android Forensics“, Andrew Hoog, Syngress, 2011.


Dr. Frank Reither has more than 20 years of experience in the areas of hardware development, software development, support, consultation and implementation of development projects. Since 2003 he is working as a software manager for the company emtrion GmbH. His main focus is on industrial communication, embedded operating systems such as WindowsCE, embedded Linux, Android, and custom firmware. In this context, controllers, processors and SOCs like SuperH and various ARM derivatives (Freescale, TI, Atmel, Renesas ...) are being used.

Edited by James A. Langbridge