What to know when switching to embedded Android
Article By : Ilja Aizenberg and Igor Kalkov-Streitz
Here's what you should consider when using embedded Android.
Imagine this: The company you work for has just invested tons of money on a custom Linux OS for a fleet of touch-screen devices because hardware driver support for that device didn’t exist. In addition to the product development cost, the company incurred future costs due to having to manage the OS themselves and furnish regular security updates.
Unfortunately, the project ended up being a financial failure. Here’s why:
Providing updates for a custom Linux OS is a mammoth and costly task. It requires in-depth Linux knowledge for merging external patches with custom changes, without breaking the whole system. Then, after building the OS, a complex infrastructure is required for distributing those updates in a secure and reliable manner. And finally, a software component would be required on the device’s side to download and install those updates in such a way so that the device doesn’t brick. All of this introduces significant recurring costs on top of the original investment.
Creating a good UX can be very difficult and differs for every Linux-based solutions: Two ticket-vending machines are rarely ever the same. (Source: Pinterest)
Manufacturers might be tempted to skip the over-the-air (OTA) update function completely because it’s too complicated to implement. But a new German/EU law now requires regular OS updates to consumer devices otherwise companies might face the risk of warranty violations. Android devices are notorious for not receiving timely updates, and sometimes not receiving updates at all.
Unfortunately, skipping OTA in the face of these new laws will no longer be an option.
And then there’s the matter of quality: In a world dominated by Android and iOS, users expect a certain degree of responsiveness in devices, a sleek feel to the graphics, and standardized methods for navigating, opening apps and changing settings. As the world learned from Steve Jobs when developing the first Mac, beauty in software is extremely difficult to achieve without greatly increasing processing power. And, in the embedded world, processing power is limited.
Amazing software also requires huge investments in usability case studies, development tools, UI standards, common UI elements, and more.
For a company like Samsung, which sold 266 million smartphone devices in 2020 alone, and has a huge development team, the costs of the above are bearable. But for a smaller company with a fleet of only 100,000 devices, this type of financial burden can render the entire product unviable.
There is, however, an option that could make projects for smaller fleets more viable: Embedded Android.
What makes Embedded Android better (or worse)?
Android is based on a modified Linux kernel with numerous features added to it, such as power-management features like WakeLocks and Early Suspend.
One game-changing feature that was added is called “Binder IPC” or “Binder Interprocess Communication” which has sometimes been called the heart of Android. Binder IPC is a lightweight method of interprocess communication, compared to the resource-intensive methods utilized in Linux distributions (pipes, sockets, memory queues, shared memory, etc.).
From a developer’s perspective, Binder IPC allows all apps and system components to have a simple communication channel. Sometimes, developers don’t even have to know which application will execute a specific action (e.g. opening the camera or sending an email)—Android will take care of passing the user-request from one application to another application that is able to satisfy it.
Android also has application sandboxing and SELinux for better security, not to mention a rich set of included components for dealing more easily with graphics, resources, notifications, networking, location, telephony and much more.
For devices with touch screens and GUI features, Android is the clear winner over Linux.
But using Android as an embedded OS comes with its own challenges.
Challenges of using standard Android in professional embedded applications
A few challenges present themselves when wanting to port Android to an embedded system.
Android’s C-library (Bionic) is not 100% compliant with POSIX. This sometimes makes it difficult to bring in external code. And Android’s file layout doesn’t conform to Linux’s Filesystem Hierarchy Standard, either.
Android does not run on custom embedded systems out of the box. Large phone manufacturers can afford big teams of software developers who branch off the Android Open Source Project (AOSP) and customize it to their own needs.
AOSP is huge. It has more than 800 projects. And 250GB of hardware space is required to download the code. Another 150GB is required to build one OS release. The build process can run for hours.
Even for experienced Android developers, the process is slow and complex. For teams with zero Android skills behind them, it’s virtually impossible.
So there is a runway for companies wanting to switch from Linux to embedded Android. And a lot of these companies might be sitting on decades of custom embedded Linux libraries that were developed in-house.
But shedding new light on this is that OTA update features must be included in future IoT devices if the company plans on selling them to EU consumers. This has already become mandatory for new vehicles across the EU. And building an effective OTA and FOTA (Firmware Over The Air) infrastructure requires an enormous initial workload that facilitates automatic builds, code-signing, uploading, and future management of updates. For devices to be able to be updated via OTA, a device provisioning system needs to be built, as well as a secure firmware installation engine. And security patches must be delivered as fast as possible when vulnerabilities are discovered.
Companies also need to prepare for hardware failures, update rollbacks, and software bugs.
Sadly, Google’s official port of Android into embedded—Android Things—has been shut down. This further exacerbates the lack of hardware support for embedded Android.
Linux hardware support can arguably be considered better in some cases. But Android is built upon Linux, meaning that if something is supported by Linux, it can also be supported by Android, in principle. However, due to the high abstraction level for application interfaces, it might be difficult to get that hardware support into the actual application.
Furthermore, Android was originally designed for devices with a fixed setup (small screen, predefined connectivity modules, hardware buttons, WiFi, etc.). Changing this configuration to something different is possible, but if the hardware of the product changes, previous changes may need to be reverted and the development starts from scratch.
In essence, embedded Android has many advantages over Linux if it is built by a team of experienced Android developers. Sure, getting started with Android is theoretically as simple as choosing a good prototyping kit to learn from—something like RockPi, Raspberry Pi, or one of i.MX8 SBCs. But it takes a team of highly experienced Android developers to build something at scale and for any fleet size, and which also includes the OTA infrastructure required to update the newly minted OS.
Building a scalable embedded Android OS for any fleet size
More effective solutions to the embedded Android challenge address these challenges by providing a customizable Android distribution that can be easily modified according to the underlying hardware requirements. For example, emteria.OS is Android in its complete form. The developer receives an extended version of AOSP but with additional interfaces, components, and applications that offer many enterprise-grade elements out of the box, such as:
- OTA Update Application
- Release Versioning
- Signing of OS and Apps including custom keys
- Private App Store
- Remote Access
- Kiosk Mode
- Mobile Device Management (MDM)
- Root Access
Some of this functionality can be seen in the figure below.
Simplified schematic of the emteria.OS stack. (Source: emteria GmbH)
Although emteria.OS is modified as needed depending on any given BSP or OEM’s requirements, the underlying infrastructure handling MDM, OTA, and FOTA doesn’t need to be. As a result, the OS stays compatible with millions of existing applications and libraries, while updates are handled on emteria’s servers and pushed by the fleet manager to devices on the fleet manager’s own schedule, controlled via a web browser.
Although Android is increasing in popularity as an embedded system, the lack of a dedicated OS supplier for smaller fleets has kept the industry fragmented and opened the door to flawed software—which can trigger warranty clauses under the new EU regime.
In the bigger picture, the lack of a highly customizable, developer-friendly and user-friendly OS, suitable for medium-sized fleets of embedded devices has been a major impediment for innovation in the growing demand across the IoT landscape. Newer versions of embedded Android like emteria.OS are a step toward standardizing the field of embedded Android and bringing Android’s capabilities to OEMs at a fraction of the cost. By reducing the existing impediment to innovation, more effective versions of embedded Android enable solution builders to focus on adding customer value rather than solving OS challenges.
This article was originally published on Embedded.
Dr. Ilja Aizenberg is strategic and commercial Managing Director at emteria. A physicist by training, Ilja has spent the last decade investigating cutting-edge technologies from different perspectives. Starting his work in nanoelectronics research with BASF SE and the Weizmann Institute he moved on to building enterprise Machine Learning applications. Before joining emteria, he focused on digital B2B business models as a Venture Capital investor.
Dr. Igor Kalkov-Streitz is a computer scientist and founder of emteria. During the development of RTAndroid, a real-time capable Android version, Igor recognized the potential of Android in the industrial context early on. Following his PhD thesis he founded emteria as a spinoff from Aachen University (Germany) and has developed the product into a powerful, highly automated software stack. The continuous stream of highly skilled and talented graduates from his former University supports Aachen as the ideal office location for emteria in the center of Europe.