Android vs Linux as An Embedded Operating System

Let’s first look at question number one: what is the device intended to do?

Here is our position: If the device you are envisioning has the following…

• need for a rich UI that a user will be expected to interact with
• need for wireless connectivity (WiFi, Bluetooth, etc)
• you’d like to avail of the close to 900,000 apps (and counting) on the Android play store to further enhance the usability & applicability of your device
• you envision in the future that you plan to expose this device as a platform that can add new functionalities that you may not have a current understanding of, but don’t want to close the door to

…then you really should consider Android as an alternative to Linux.

Which now brings us to the next question: what are the differences between Android and Linux?

And why do we suggest Android, is it really ready enough?

The answer is yes, it’s ready, but you may have to tweak Android to work and fit well into your device. Without enough information, it’s very easy to conclude that Android is just too bloated, too slow, or too limited to get onto a device anything smaller than a 1GHz ARM CPU. And you would be right if you just looked at ‘mainstream Android.’ BUT, that is really not the case if you delve in deeper and work with partners who know how to customize Android for your needs.

But before we talk about why Android needs to be customized, let’s talk about the key benefits it brings you over Linux

• UX: The UX layer of Android is significantly more advanced than Linux. It’s optimized for touch screens, has advanced handling and rendering capabilities and exposes a very rich set of APIs that a developer can easily use to create a great UX experience. Furthermore it is standardized. Linux on the other hand has a plethora of different UI libraries, for a vast variety of platforms and given that it’s intended as a core OS, leaves UX choices/integration to the developer.
• Support for connectivity protocols: Android has an advanced connectivity manager that includes managing wireless connections via various protocols. This is neatly integrated at both the services and UI level, and is easy to extend.
• Vibrant developer community: Android has a well-established SDK and publishing process for new applications. If you ever chose to add more functionality to your device, it’s easy to either write an app for it or even, open it to a 3rd party to create an app –they don’t even need to know your device specifications. If they develop using Android SDK guidelines and your device supports the same guidelines (which it should), the app will just work on it! Well, the devil is in the details, but at a general level this is correct.
• Java: Android has an optimized JVM (well, Dalvik VM, really) that allows a Java programmer to write applications that work efficiently on it. Linux on the other hand supports a multitude of programming languages, but does not have a Java-compatible VM that is as optimized as Android. Why does this matter? Simple – you can hire Java programmers very easily to create extensions. But most Linux embedded devices today don’t support a Java-based application system and people are still using C and C++ to develop extensions.
• Built in Telephony: Android already has a built in telephony stack – that includes GSM, CDMA, LTE in addition to providing VoIP calling integrated into its suite.

Now, a Linux expert could turn around all of these points and state that “Android is just a layer on top of Linux” and that Linux can do everything listed above. This is technically true. The point however is how much effort do you need to spend on top of a vanilla Linux distribution to achieve these additions? Android already has them, so why not use it?

And herein lies the other part of Android: myth busting. Many people evaluate Android from its “stock image” –that Google maintains (AOSP) and conclude that it’s not suitable (yet) because it:

• does not work on their hardware
• is too slow to start
• takes too much memory
• [add your favorite complaint here]

The answer to all of this is: you need to know how to customize Android to suit your needs. Once you do, the benefits are tremendous.

So here are some myths we’d like to address:

Android is too slow – it takes over a minute to boot up!

Android’s boot up and startup procedure is heavily customizable. There have been significant advances to improving Android’s U-Boot, including replacing it with single stage boot loaders such as Qi. There have also been advances in hibernation support for Android that results in significantly fast power-to-ready scenarios. These options reduce the time to load the kernel by over 5x. Next, you should look at reducing the number of system services that get started – only use the ones you need. There are many other optimizations you can achieve there, including reducing the preload of classes by Zygote and several others.  If you search, developers have shown a sub 3 second boot for Android devices using a multitude of technologies.

Android only supports ARM

First, ARM is probably one of the most common and flexible platforms for embedded devices. And yes, Android AOSP mainly supports ARM. But did you know that Android is also ported on MIPS, x86 and other platforms? There are several groups like android-x86, mipsandroid and others that support Android on platforms that Google directly does not. You should also keep a track of Linaro.

Android needs too much memory and is slow

Depending on how you customize Android (see above), it is possible to have it work efficiently on a 700MHZ processor with 512MB of memory. Frankly, if you are working on a very low end processor, it’s probably not worth it to port Android. Is this a high end processor? We really don’t think so but if you have a form factor that is significantly less powerful, then Android is probably not a great choice.

Android is primarily intended for battery-powered mobile phones

Yes, the stock version is. But we’ve customized it for desk phones (powered, Ethernet!), medical devices, and appliances which have nothing to do with mobile phones. The benefits are tremendous – if you do get Android working on your platform (and we can do that for you), it’s so much easier to add features and upgrade, not to mention automatic support for a plethora of applications.

I don’t need the ability to add new applications – mine is a closed system

If we could count the number of times we’ve heard this from our customers… The point here is you can never predict your roadmap a year ahead. If you are in the market with a device with a rich UX and you believe you will never need apps, your end users will prove you wrong. Even if you don’t allow 3rd parties to deploy applications (yes, you can customize Android to not allow Play Store access) you can use the same infrastructure to deploy your own apps as upgrades!

Android has licensing issues

There are two parts to Android: the core platform and the apps on top of it. The core platform is Apache Licensed – which means you can use it commercially, without paying Google at all. The other part, which is the core apps – like Google maps, search and others – are Google licensed and the only way you can get them on your platform is to be able to certify your device as Google compliant. You don’t need to have it certified unless you need Play Store access or need the apps. So let’s be clear – the core Android platform is Apache licensed and has been forked many times by many vendors for commercial use.

Android does not use glibc, but uses bionic – that is very limited

In our opinion, Bionic actually has several advantages, size and speed being one where it is more appropriate than glibc and even uClibc. Furthermore, it is BSD licensed so that means Android applications are not tied to GPL/LGPL effects. Bottom line, this really should not be a concern.

Android is limited – its only Java

This is the corollary of ‘Java is easier’. Actually, this is not true. Android has two parts: the Java SDK and the C NDK – you can write applications that use the NDK as well. Furthermore, the core Android Framework is split between Java and C – and you can customize it at both levels to do what you want. Really, if you understand the source, it’s incredibly customizable.

Linux allows more customizability

Well, Android is a layer above Linux! When we modify Android, we hack Linux too – you have the source code for both, so don’t let Android stop you from hacking at the Linux that lies underneath it! Of course, you need to know how Android’s framework interacts with Linux, and that is where companies like us can help you make sure your changes don’t break anything.

Linux has more adoption

Indeed it does. But that is a function of readiness and time. If you look at the market today, it’s all about applications – no matter what you are building. You now have fridges, car dashboards, watches , TVs and set top boxes powered on Android – and we expect this trend to explode

Bottom line, Android has a lot of additional, standardized work done on top of Linux: things that are very useful of you are thinking of a UX rich device. Don’t let the bulk of Android scare you – tame the beast and enjoy its incredible benefits.

(Do you find this article interesting? You may want to check out our Embedded Android pages to read more about what we do in this space.)