Android Automotive OS: GAS vs. NON-GAS

In-vehicle infotainment (IVI) in consumer and fleet vehicles has been shaken up by the rise of Android Automotive (also known as Android Automotive OS and AAOS) in recent years. Initially released 7 years ago, it has slowly expanded into many vehicle models across an ever-growing list of automotive OEMs – the Polestar 2 by Polestar, the Accord by Honda, and the Nautilus by Lincoln just to name a few.  The case it makes for itself is certainly very enticing. It allows OEMs to utilize the Android developer community that has been built up for over 15 years. It makes the development of partner applications much more appealing to those potential partners, as most of them have Android applications already.  It also provides a more standardized approach to infotainment application design that will lead to more consistent user experiences across the industry.

Before we proceed with a view of the AAOS landscape, it’s important to clarify what Android Automotive is not. Android Automotive is not Android Auto, the Android experience that most drivers may be familiar with. Android Auto is an app mirroring solution developed by Google, that allows users to project key Android features from their phone to a valid receiver IVI module. In this way, a mobile device with the Android Auto app installed is therefore required and serves as the main processing unit for content. Android Automotive is an extension of the Android OS that runs directly on the IVI module itself. An external mobile device is therefore not required – though phone companion apps are still very common!

So now we know that Android Automotive is distinct from Android Auto, and is much more powerful in terms of the kinds of experiences that can be developed. But what actually sets it apart from your standard Android OS? After all, several OEMs and tier 1s have developed many similar infotainment systems over the years, even some that build off of “vanilla” Android. So what does Automotive add to the mix?

Essentially, Android Automotive adds a variety of additional APIs and components that simplify application development by leveraging the features unique to a vehicle. The centerpiece of these additions is the VHAL (or Vehicle Hardware Abstraction Layer), Android Automotive’s mechanism for taking in information from elsewhere in the vehicle – attributes such as speed, HVAC state, seat configuration, mirror positions, etc. – and exposing that data to the infotainment application environment.

AAOS, however, is not a catch all solution to building out an infotainment product. The open source version of the operating system – that any entity can build today – has its own selection of built-in applications that satisfies key use cases, such as messaging, contacts and SMS for a paired phone. But if you were to boot up such a “vanilla” build today, you would see some key expected applications missing – in particular, maps, app store, and voice assistant.

Every user expects these 3 key applications in their modern infotainment experience. They expect an easy way to get navigation guidance from A to B. They expect an easy way to interact with their car in a hands-off way. And they expect an easy way to both update their applications and locate new ones. But Android Automotive does not provide these experiences out of the box. So where does that leave an OEM who needs to fill these gaps? There are two main routes to take.

The first option is for the OEM to develop these applications and common utilities themselves, or to work with a tier 1 or service provider partner to develop said software. This necessitates bringing in additional app developers with experience in Android. You also need resources dedicated to running infrastructure for OTA updates and cloud services. But it also requires a less common skillset specific to this space – developers with experience working directly on the Android OS, creating new system services and other functionalities that all the applications utilize. These are skills that are needed by an OEM in the Android Automotive space no matter what, but even more are required to develop these full experiences from scratch.

In order to cut back on the amount of resources required for the first option, OEM’s entering the space have a second route to pursue. This comes directly from Google – Google Automotive Services, or GAS. At its core, GAS is a bundle of apps and other utilities built on top of the AAOS system. Amongst these apps are those that fill the 3 key gaps discussed – Google Maps for maps, Google Play Store for app store, and Google Assistant for voice assistant.

In the rest of this article series, we intend to dive deeper into GAS and give you a clear picture of exactly how it fills the aforementioned gaps in an Android Automotive system. We also hope to present you with a sense of what requirements GAS has for those who integrate it, as well as what kind of development effort it would take to develop everything that a solution like GAS offers “in house”.

Author: Nick Dedenbach, Manager Android Automotive Team