Android Automotive OS: an introduction

This is the first in a series of blogs about Android Automotive OS

What is Android Automotive OS?

Android Automotive OS (AAOS) is a version of Android designed to run in a vehicle head unit and provide the “In Vehicle Infotainment” (IVI) system. In modern vehicles, the IVI system controls the heating and ventilation, provides audio streaming, shows the rear-view (and side view) cameras, offers navigation … and many other things besides.

The core of AAOS is part of the Android Open Source Project (AOSP), and since it is open source anyone can use the code to create an IVI product. But don’t get too carried away with that thought. The code in AOSP is just the bare bones, with a very basic home screen and a few “demo quality” apps for music, heating controls and such like. An auto manufacturer still has a lot of work to do before they have a viable product.

Of course, Google has a solution. They license a set of proprietary APIs called Google Automotive Services, or GAS. This is similar to Google Mobile Services (GMS) in the mobile world: GAS provides Play Store, Google Navigation, and Google Assistant (for voice activation and hands-free driving), among other things. The first vehicle to be sold with AAOS in the head unit was the Polestar 2 in March 2020, which includes GAS and the full suite of Google services. But, GAS is a little controversial in the automotive world because of the loss of control the Google license implies, not to mention sharing valuable data with Google which the auto manufacturers would rather keep to themselves. Expect to see versions of AAOS without GAS in the near future.

Note that Google have another product with a similar name: Android Auto. This is a completely different beast. The Auto app runs on a normal Android phone and uses a USB or (recently) WiFi connection to the head unit. The head unit is NOT running Android. In most cases it is actually running an embedded Linux operating system developed by the vehicle manufacturer. This blog is absolutely NOT about Android Auto

Why AAOS?

“Why” is always the more difficult question. My observations are twofold

The attraction from the car manufacturer’s point of view is that AAOS will reduce development and maintenance costs. Most cars on the market today have an IVI system that is developed in-house, or in partnership with a Tier 1 software provider. Development is expensive and slow. On the other hand, AAOS is an off-the-shelf solution with a full set of media codecs, a suite of apps (if you license GAS), and a fantastic developer network. Also, it is much easier (cheaper) to hire Android developers than C++ developers who know the Qt programming environment

AAOS is also a win for customers. The current crop of IVI systems don’t have a great reputation for usability, whereas AAOS has the familiar Android UX and the ability to install new apps from an app store. On that last point, the experience here will depend on whether the manufacturer has licensed GAS or not. If not, there will probably still be some kind of app store, just not the full Google Play Store.

Architecture

AAOS is an add-on to normal Android. The main components are the vehicle HAL, Car Service and Car Manager, as shown here:

Starting from the bottom, we have the Electronic Control Units (ECUs). They are part of the vehicle. They monitor and control every aspect of the vehicle. They are connected to a vehicle bus, usually a CAN bus.

On the Android side of the vehicle bus we have the Vehicle Hardware Abstraction Layer (VHAL), which represents signals from the bus as vehicle properties. There are over 150 pre-defined “system” properties in Android 12. For example, there is one named PERF_VEHICLE_SPEED which represents the speed in metres per second. OEMs can add their own “vendor” properties.

The Car Service takes vehicle properties and adds information from other sources to create a set of services that are useful to applications.

Applications do not call the Car Service directly. Rather, they call the Car Manager library, which implements the android.car.* packages (https://developer.android.com/reference/android/car/packages). There are some demo car apps in AOSP which show how the android.car classes are meant to be used. These apps are mostly system apps, which is to say that they are written by the manufacturer and provided pre-installed with the vehicle. They can access low level functions, such as lowering and raising the side windows.

Finally, we have third party Auto apps that you can install from Play Store – or another app store. They are quite limited in the parts of the car they can access and must follow guidelines to avoid driver distraction. These are things like streaming music, audio books and navigation. For more information, look at https://developer.android.com/training/cars/start

The Automotive user interface

AAOS is designed to be easy to use while driving. It has a simple tile-based UI with large icons. Here is a screenshot of the default UI from AOSP 12, with the navigation bar at the bottom and status bar at the top

The icons on the navigation bar are Home, Phone, Apps, HVAC, and Notifications. The Apps icon takes you to the app menu where you will find the pre-installed system apps plus any that you have installed yourself. The gear wheel at the top left takes you into a simplified settings menu, and touching the user icon top right allows you to say who is driving the car.

You will almost certainly never see an actual vehicle with this layout. This is where vehicle manufactures are encouraged to stamp their own branding and UX. For example, the Polestar 2 implementation is very different to the default.

Conclusion

From my experience it seems that the majority of auto manufactures are integrating AAOS into their cars: AAOS is going to be in a vehicle near you quite soon. This is going to be a learning curve, not only for the auto makers, but also for the Android developers as they add features to cope with the automotive environment.