7 reasons to consider Embedded Android for your next project

Android is becoming a popular choice as an embedded operating system. Embedded Android has the same advantages as embedded Linux, plus it has a great UI and a familiar programming interface. It is popping up in lots of different places, including digital signage, test and measurement, point of sale, and automotive. In this article I want to highlight some of the reasons people are choosing Android, and to give some thoughts about getting started with an embedded Android project.

Reason 1: It’s free

The source code for the core of Android is released by Google as the Android Open Source Project, or AOSP. This has everything up to and including the launcher screen and some basic apps for things like browser, clock, and phone. All of this code is licensed using permissive open source licenses: most of it is licensed under Apache 2.0, with some parts using BSD and MIT licenses. Permissive open source licenses mean that you can modify the code and ship products for free, without having to make any of it public.

You can download a copy of AOSP right now from the Google git servers, although you should be aware that a full download is about 50 GB. There are comprehensive details on how to build mainline AOSP at source.android.com, and later on in this article I will give pointers for embedded versions of Android. Building Android from source is certainly non-trivial, but it is well within the capabilities of most embedded platform developers.

The other big software component you will need is a Linux kernel – which is also free under the copyleft GPL license, which in essence means that you have the freedom to modify the code so long as you make that code public.

Unfortunately, there is a fly in the ointment in this world of free software. In most cases you will need to integrate some non-free software as well. Typically, these non-free “binary blobs” provide firmware for the processor and peripherals, for device driver kernel modules and user-space libraries that comprise the Android Hardware Abstraction Layer (HAL). These components are usually only available as part of an Android board support package from the chip vendor. More about this later.

Reason 2. Familiar User Interface

If your product has a touchscreen, Android is the obvious choice. Pretty much everyone has used an Android mobile phone at some point or other, and so your end users will be familiar with the way the UI works – the way you navigate through the menus and on-screen options, the way that the touch gestures work – it’s all second nature. So, it makes sense to have that same user experience in your product.

Reason 3. Familiar programming environment

The Android programming interface is well known and well documented – go and look at developer.android.com to get an idea of the level of support Google gives to their mobile operating system. Not only does this make it easier to develop applications for your product, but it also makes it easier to find developers to work on your product. There are many more who are familiar with Android than know C++, which tends to be used in plain embedded Linux environments. On the other hand, don’t give up on your hard-won C++ expertise, because you can program Android in C++ as well as Java.

Reason 4. Good tools for programming and debugging

Google has a whole set of really great tools for developing Android applications, which are also free. Android Studio is the main workhorse for writing applications in Java and C++.

If Java and C++ don’t float your boat, there are many third parties providing support for other languages and environments. For example, Xamarin have tools that allow you to write Android apps using C# and .NET, which gives a good development path from applications running on Windows CE or Windows Embedded.

Reason 5. Good support from chip vendors

To embed Android, you need both hardware that is capable of running the system and a board support package that configures Android and the Linux kernel appropriately. Bear in mind that embedded devices are usually built to more stringent standards than consumer-grade products. These devices often have to operate in harsh environments, possibly unattended, for years on end. They are often manufactured in small batches and have a long design lifetime. Contrast this with consumer products which are built in hundreds of thousands (or millions) with a design life of 12 to 18 months. Conclusion: an off-the-shelf Android tablet is usually not what you want

So, embedded designs are based on chips and other components that meet industrial specifications and that will be supported for the whole of the design life of the product. This rules out some of the more high-profile SoC vendors, but there are still enough vendors who are committed to supporting Android on their embedded chip sets. Chief among them are NXP, Qualcomm and HiSilicon.

NXP support Android on most of their i.MX 6 range of SoCs, which includes single, dual and quad core ARM v7a architecture (32-bit) CPUs. At the time of writing, NXP provide board support packages for AOSP versions up to 7, Nougat.

Qualcomm have a number of industrial grade components under the “Snapdragon Embedded” banner, which include the 410E, 600E, and various 8xx models. These are a mixture of ARM v7a and ARM v8a (64-bit) architectures with either four or eight cores. The embedded chips are similar to their mobile counterparts, but without the mobile data modem. Currently, all support AOSP 7, Nougat.

Hisilicon (part of Huawei) are a bit of an outlier here in that they do not have a strong presence in embedded processors, and yet they do supply the SoC for the only embedded development boards that have direct support in the AOSP source code base: the HiKey and HiKey 960 boards. These are based on the Kirin 6220 and 960 chips respectively, which are both ARM v8a architecture. Since the support is right there in the AOSP code base, they run the latest AOSP version, currently 8, Oreo.

There are other SoC vendors that offer some level of Android board support, including Allwinner, Amlogic, Intel, Mediatec, and Rockchip. If the chip you are using is not in the list, you could, theoretically at least, port your own version of AOSP to it. As an example, I have done this for the TI AM335x processor found in the BeagleBone family of boards. The project is called Android4Beagle.

Reason 6. It’s Linux underneath

The Android operating system sits on top of a Linux kernel, usually supplied from one of the SoC vendors mentioned above. This means that the knowledge of Linux that you have built up over the years is still relevant. You can still customise the kernel and add drivers for your hardware. You can use all of the Linux development tools, including perf for performance monitoring and ftrace for tracing.

You can even run normal GNU/Linux applications within Android, with a little tinkering. This means that you can reuse code that you have developed for other Linux platforms in the past. Good examples would be customised algorithms for processing signals, or protocols for communicating with the rest of the system. The issue here is that Android does not provide the POSIX APIs and other libraries that are expected by applications compiled for a GNU/Linux distribution. There are two ways of going about solving the problem.

Option 1 – re-write your application to use the libraries that are available in the Android native environment, including the non-POSIX compliant C library, Bionic

Option 2 – use a “chroot jail” to create an small GNU/Linux environment within Android, and use local sockets to communicate with the reset of the Android system.

Reason 7. You can customize it to your needs

This is a feature of all FLOSS (Free/Libre and Open Source Software) but in the case of embedded systems, being able to tweak the low level platform code to your needs is crucial to getting the most out of your product. I am not advocating large changes to the core operating system – which would be a maintenance nightmare – just making the small changes and adjustments that make for a really great product. A good example would be locking down the UI so that users can only use the applications that you supply.

Getting started with embedded Android

To get a feel for what is, and is not, possible with Embedded Android, a good place to start is with a low priced development board. Choose one with good Android support, such as the DragonBoard 410c, with its Qualcomm Snapdragon embedded 410 chip ($75), the LeMaker HiKey ($75), or the i.MX6-based Wandboard (from $69). For a longer list, you could take a look at LinuxGizmos catalog of open-spec, hacker friendly SBCs.

If you want a more “nuts-and-bolts” experience, you might be interested in my Android4Beagle project, which is a clean port of AOSP to the BeagleBone Black. You could use this as a base for running Android on a TI chipset (several of my customers have done so already), or you can use it as an educational tool to play with Embedded Android in a simple and straightforward way.

If you would like to know more about Embedded Android, stay tuned to 2net. We offer in-depth, instructor-led training courses in Embedded Android and Embedded Linux. We have two courses that are specific to Android: Android Porting which covers platform configuration, and Android Internals which teaches how to create embedded products using Android. Both courses are available world-wide.

Biography

Chris Simmonds is a software consultant and trainer living in southern England. He has almost two decades of experience in designing and building open-source embedded systems. He is the founder and chief consultant at 2net Ltd, which provides professional training and mentoring services in embedded Linux, Linux device drivers, and Android platform development. He has trained engineers at many of the biggest companies in the embedded world, including ARM, Qualcomm, Intel, Ericsson, and General Dynamics. He is a frequent presenter at open source and embedded conferences, including the Embedded Linux Conference and Embedded World.