Google’s Android OS has limited real-time support and a checkered past with security. It’s also big, complex, and resource-intensive. Yet, it’s starting to take the embedded software world by storm, via a two-pronged approach.

One prong involves Google slowly adding official support for more embedded device types, allowing Android to make inroads into a wider range of embedded markets. Having grown to dominate the worldwide market for smartphones and tablets, today Android also supports smart TVs and set-top boxes, wearables such as smart watches and Google Glass, and even IoT devices via Google’s new Android Things variant. And it’s clear that Google is just getting warmed up.

The other prong takes a more do-it-yourself approach, with embedded device developers modifying the Android OS and the underlying Linux kernel to support classes of embedded devices not officially supported in Android. Because these embedded device developers typically create a custom Android app that replaces Google’s standard home screen, end users often never even know that they’re using an Android-based device. Although such modifications to Android aren’t trivial, embedded device developers are attracted by many features:

• A modern, GPU-accelerated, touch-based GUI that’s familiar to users
• Wide support for the Linux kernel among processor and peripheral vendors
• Sophisticated software stacks for common bus and network interfaces
• Strong APIs and development tools
• A large pool of qualified Android app developers
• Open-source licenses that provide full source code and eliminate licensing fees and restrictions on use

In May 2016, Google announced that they are expanding Android’s reach by targeting the automotive In-Vehicle Infotainment (IVI) market, projected to reach $35 billion worldwide by 2020, an effort that involves modifying the Android OS to meet the automakers’ requirements. Google and Qualcomm demoed this as-yet-unbranded Android OS variant running on the stock IVI of a Maserati at Google I/O 2016 and Google began publicly releasing architectural documentation and related source code in August.

Of course, this isn’t the first time Android has shown up on an IVI; Google’s Android Auto technology, released in 2014, allows an Android smartphone to “project” its user interface and apps onto the touchscreen of a compatible IVI built on any OS, but it can’t drive IVIs with large 4K touchscreens, like those in Teslas and other high-end vehicles, or digital instrument clusters. Google’s Android-based IVI platform won’t have these limitations.

Likewise, GM, Honda, and other automakers have been working with their OEMs to develop Android-based IVIs for several years. But Google’s official endorsement is critical for expansion of Android into this market; without it, a do-it-yourself Android IVI developer can’t license Google Maps or other prized Google technologies that aren’t technically part of the Android OS, requiring these to be built internally or licensed from third parties.

Google’s biggest challenge in adapting Android for use in automobiles is meeting the auto industry’s stringent security requirements. While Android’s architecture was designed to be secure from the start, its reputation has been somewhat tarnished by the slipshod implementations of some Android phone and tablet makers, and also by the demands of developers and consumers who want root access to the Android OS or the ability to load customized versions.

Google has spent a decade improving Android security, recently mandating that Android OEMs use features like SELinux and secure boot to better restrict access to software components and protect the integrity of the Linux kernel. For the Android IVI platform, Google is building on these security features by isolating key automotive software components from the rest of the OS. And like Android Auto technology, it’s likely that Google’s Android IVI will initially support only a few hundred, specially selected navigation, audio, and messaging apps.

Despite Android’s advantages, there’s no question that there will be automakers who opt to resist the Android juggernaut, perhaps because they prefer a more traditional RTOS, because they want to dramatically differentiate their software, or because they simply chafe at Google’s licensing requirements. But if consumer demand becomes the driving factor, it’s possible that the world’s most popular mobile OS may be about to become the world’s most popular automotive infotainment OS.

Nathan Tennies, principal engineer at Barr Group, has developed embedded and desktop software for more than two decades. Today he focuses on BSP and driver development for embedded Android/Linux, Windows CE, and RTOSs. He has authored articles describing software techniques to extend handheld device battery life and has experience with wireless, automotive, and medical firmware and security architectures.