Android or Linux - some thoughts

While now hard to remember, there was a time when the term “embedded Linux” was viewed with suspicion. The outcrop of small, low-power, Linux-based devices - and readily available open source software - has since transformed the industry; nowadays it’s not “why would you run Linux here” but rather - “why wouldn’t you”?

With embedded systems boosting more performance and graphics capabilities than ever before, and with GUI-enabled touchscreen devices taking hold in a wide range of applications, from small control panels to huge infotainment screens, Android - once viewed as a purely consumer OS - is becoming an interesting alternative.

In this post, as a long-time partner and provider of software & product development services for mutual customers of Toradex, as well as the maintainer of Android images for Toradex modules, we explain the differences and commonalities between those two operating systems.

Over the years, we have developed numerous software solutions and complete devices, both industrial and consumer, running Linux and Android, and we believe there is no silver bullet - what OS is better for your use case depends on the use case itself and your devices’ planned life-cycle.

Linux is a great choice for the the majority of embedded use cases. Linux build systems such as Buildroot and OpenEmbedded can be used to create customized BSPs tailored to almost any size and a wide array of application software and SDKs is available, from gstreamer through Python to even node.js. An OpenEmbedded/Yocto-based Linux is the default distribution supported by Toradex, and a vast development community supports a multitude of programming language environments and frameworks. Modern Graphical User Interfaces (GUI) can be developed with many technologies including Qt, HTML5, to the point that can make it hard to choose. But once you build your base OS image with the necessary software components, update capabilities and APIs - a task for which you also can use service providers like Antmicro - you have all the freedom in the world to build your application software, and it is not so hard to change your mind down the road in case you need that.

Android, on the other hand, forgoes some of the OS-level freedom in favor of standardization: there is an “Android” way to do things in order to benefit from the good sides of this OS. In return, you get a unified GUI framework, Java programming paradigm¹ and a familiar developer experience (a natural consequence of Android’s smartphone/consumer origin) which can in fact be critical for your use case, especially if your device includes a touchscreen which is intended for regular use by various people.

For example, if you have an already existing dedicated app for smartphones/tablets that your users are accustomed to - whether it’s a smart home control center or a mobile industrial measurement device - and you are building a dedicated device to replace or complement them, Android is the perfect choice. Without the need to rebuild your user interface from scratch, you save vast amounts of work and numerous user studies to get the UI right, and people care most about what they see and interact with. You will need an industrialised Android image (with e.g. single-app lock in, customised branding and OS abstractions for various interfaces) to accomplish this, but it will probably be a smaller investment than recreating the user experience in Linux.

Even if you do not have a pre-existing app, you may also have an in-house team of Android application developers (or know a good Android application design studio) who could potentially develop your UI for you. With a much broader application development community, tons of example apps, standardised application packaging and emulators, developing end user apps in Android is easy. The clear separation between OS and application layer through standardised APIs (in Android you use different “API levels” to indicate compatibility) means that you can reuse existing mobile apps or have a separate team work on them and carry on with testing or adjusting the user interface with the target users while an embedded team works on ensuring all the Android features you want to support.

Good use cases for choosing Android especially includes scenarios with a larger, varied community of users. That includes not only typical consumer devices such as wearables or smart home IoT, but also things such as corporate devices used by industrial professionals in larger numbers - from hand-held instruments to networks of machines situated on site. Even foregoing the application development experience, the familiar user interface components, gestures and interactions of Android may be enough to warrant picking it over Linux.

As mentioned above, Android - although based on the Linux kernel - has its own way of doing things, including a fairly complicated buildsystem (related to its huge codebase), and the necessity to expose your kernel level additions to the OS layer in order to make them work in your application. There are also more requirements from the hardware - since Android requires graphics acceleration and memory for its virtual machine, you will typically not be able to run modern Android versions on a device with less than 512 RAM or without a GPU. As with any other choice, using Android in your embedded device should be motivated by a need for the benefits it provides.

Antmicro has helped numerous customers choose the right operating system for their devices based on Toradex platforms, and provides Android demo images and development services for Android 5.1 or 6.0 for the Toradex T30/i.MX6 and TK1 modules to offer better time-to-market.

If you need assistance in deciding which option to pursue for your next embedded device, Antmicro will be happy to guide you further. For details please contact us at contact@antmicro.com or visit our website.

1 You can also use an NDK to develop your applications in C/C++ and C#, use Qt as your presentation framework or develop mobile apps using Javascript in frameworks like Cordova or React Native - but we are focusing on the most popular scenario here.↩