Android Automotive OS is Google’s in‑car operating system that runs directly on a vehicle’s hardware. Not to be confused with Android Auto (a phone projection platform), Android Automotive OS Architecture is a complete software stack, ready for infotainment, driver assistance apps, and full vehicle integration. 

Let’s dive into its main layers.

Android Automotive Architecture

A high-level architecture diagram of the Android Automotive OS is given below.

It consists of the following four main generic components:

Application Framework

Application Framework layer, also known as the HMI (Human-Machine Interface) is responsible for providing the user interface for the car’s infotainment system. It includes both user applications, such as music players and navigation apps, as well as system applications, such as the car’s settings and the voice assistant.

It is important to design applications in this layer with most core business functions moved to the Services layer. This approach ensures scalability and easy updates for the future.

The Application Framework layer contains further parts, which are as follows:

1. Android Open Source Project (AOSP): The Android Open Source Project (AOSP) is the base software for Android devices. It includes all the necessary components like system apps, application frameworks, system services, and HAL interfaces. These components are organized as “GIT-tree packages.”

In AOSP, you find generic system apps like the default launcher, contacts app, and clock app. The application framework provides tools for app development. System services manage important functions like network connectivity and security. HAL interfaces help interact with device-specific hardware.

When you install Android on a device, all these components are stored in the /system partition, which is like the “core” of the Android system. Custom ROMs replace these files to offer different features and optimizations.

2. OEM and 3rd party applications: The OEM and 3rd party applications are the “face” of the car’s infotainment system. They’re the things that people see and interact with. The HMI is the way that people interact with those applications. And the application background services are the things that keep the whole system running smoothly.

BTW, What is OEM?

OEM stands for Original Equipment Manufacturer. In general, an OEM is a company that manufactures products that are sold under another company’s brand name. For example, Bose is an OEM for sound systems. They make sound systems that are sold under the brand names of other companies, such as Toyota, Ford, and Honda.

In other words, Bose is the company that actually makes the sound system, but Toyota, Ford, and Honda are the companies that sell the sound system to their customers.

In the context of Android Automotive OS architecture, an OEM is a car manufacturer that uses the Android Automotive OS as the operating system for its car’s infotainment system.

OEMs have a lot of flexibility in how they use the Android Automotive OS. They can customize the look and feel of the system, add their own applications, and integrate the system with their car’s other systems.

Here are some examples of OEMs that use the Android Automotive OS:

Volvo: Volvo is a Swedish car manufacturer that uses the Android Automotive OS in its XC40 Recharge electric car.

Renault: Renault is a French car manufacturer that uses the Android Automotive OS in its Megane E-Tech electric car.

Honda: Honda is a Japanese car manufacturer that uses the Android Automotive OS in its e:NS1 electric car.

These components are stored in the /product partition on the car’s hard drive. This is a separate partition from the /system partition, which contains the Android operating system itself. This separation allows OEMs and developers to customize the car’s infotainment system without affecting the underlying Android operating system.

Android Automotive System Services

This layer contains all the important System services that handle various essential functions in the Android Automotive system, like managing network connections, power, and security features.

One interesting aspect of this layer is that it acts like a protective shield of security for the system. Instead of allowing applications to directly communicate with the hardware through the Hardware Abstraction Layer (HAL), they interact with the System services. These services act as an intermediary between the applications and the hardware.

This approach has a significant advantage in terms of security. By using the Services layer as a middleman, OEMs can ensure that the hardware’s sensitive functionalities are accessed and controlled in a secure manner. It prevents direct access to the hardware from regular applications, reducing the risk of potential vulnerabilities or unauthorized access.

The Android Automotive System Services layer contains further parts, which are as follows:

1. Car Services: Car services are an important part of the Android Automotive Architecture Service Layer. They provide a consistent, secure, and efficient way for applications to interact with the car’s hardware and software. Some examples of these services include CarPropertyService, CarAudioService, CarClimateControlService, and CarNavigationService.

2. Car Managers: Car managers are a set of system managers that provide access to the car’s hardware and software. They are implemented as a set of classes, each of which is responsible for a specific area of the car, such as the audio system, the climate control system, or the navigation system.

Overview of the different Car Managers along with their respective descriptions

Hardware Abstraction Layer (HAL)

The Hardware Abstraction Layer (HAL) plays a crucial role. It acts as a bridge between the vehicle’s hardware, specifically the Electronic Control Units (ECUs), and the rest of the system, including the application framework and system services.

The HAL’s main purpose is to expose standardized interfaces that the system services can use to communicate with the different hardware components inside the vehicle. This creates a “vehicle-agnostic” architecture, meaning that the Android Automotive system doesn’t need to know the specific details of each car’s hardware.

By using the HAL, the system services can interact with the vehicle’s hardware in a consistent and standardized way. This enables data exchange and control of various car functionalities, such as handling sensors, managing displays, and controlling audio and climate systems.

Vehicle HAL: Vehicle HAL is a crucial component in Android Automotive architecture. Its main purpose is to provide a standardized and adaptable way for the system services to communicate with car-specific hardware and functionalities.

The Vehicle HAL provides access to a variety of car-specific features, including:

• Signals to/from the ECUs in the vehicle: The ECUs (Electronic Control Units) are the electronic brains of the car. They control everything from the engine to the climate control system. The Vehicle HAL provides access to the signals that are sent between the ECUs, which allows the Android Automotive system to monitor and control the car’s systems.
• Signals generated from the vehicle microcontroller unit to the IVI OS: The IVI OS (In-Vehicle Infotainment Operating System) is the software that runs on the car’s infotainment system. The Vehicle HAL provides access to the signals that are generated by the car’s microcontroller unit, which allows the IVI OS to interact with the car’s hardware.
• Access to service-oriented functions available on the vehicle network (e.g.: SOME-IP): SOME-IP is a standard for service-oriented communication in vehicles. The Vehicle HAL provides access to the SOME-IP services that are available on the car’s network, which allows the Android Automotive system to communicate with other devices in the car.

Board Support Package (BSP)

In the Android Automotive architecture, BSP stands for “Board Support Package.” It is a crucial component that plays a vital role in making the Android Automotive system compatible with specific hardware configurations, especially System on a Chip (SoC) devices.

System on a Chip (SoC) refers to a type of semiconductor integrated circuit(IC) that incorporates multiple essential components of a computer or electronic system onto a single chip. It is a complete computing system on a single chip, including the central processing unit (CPU), memory, graphics processing unit (GPU), input/output interfaces, and various other components.

The BSP is an important part of the Android Automotive architecture because it allows the operating system to interact with the car’s hardware. This is necessary for the operating system to run and for applications to function properly.

The BSP is also important because it allows OEMs to customize the car’s infotainment system. OEMs can extend the BSP with their own code and applications, which allows them to add features that are specific to their car.

The BSP is typically developed by the SoC vendor or by an OEM. It is then provided to the Android Automotive team, who integrate it into the Android Automotive operating system.

Linux Kernel: The BSP typically contains the Linux kernel image, which is the core of the operating system. The Linux kernel handles hardware interactions and provides a foundation for running Android on the given hardware platform.

AIDL & HIDL

In the Android Automotive architecture, both AIDL (Android Interface Definition Language) and HIDL (HAL Interface Definition Language) play essential roles in enabling communication between different components of the system.

AIDL (Android Interface Definition Language):

• AIDL is a communication interface used primarily for inter-process communication (IPC) between applications running on the Android system.
• In Android Automotive, AIDL is used for communication between user applications and system services. It enables apps to interact with system services and access certain functionalities provided by the Android framework.
• AIDL is commonly used for remote method invocation, where one application can request services from another application running in a different process.

HIDL (HAL Interface Definition Language):

• HIDL is a communication interface used for interacting with the Hardware Abstraction Layer (HAL).
• In Android Automotive, HIDL allows system services and other components to communicate with the hardware-specific functionalities of the vehicle.
• The HAL abstracts the hardware-specific details and exposes standardized interfaces through HIDL, allowing the rest of the system to interact with the vehicle’s hardware in a consistent manner.

So, AIDL is used for communication between user applications and system services, while HIDL facilitates communication between the Android system services and the Hardware Abstraction Layer (HAL).

Conclusion 

This high-level walkthrough of the Android Automotive OS architecture explained how each layer — from apps down to car hardware — connects and interacts. You’ve seen how vehicle data is accessed in a clean and structured way. Whether you’re an OEM building new car platforms or a developer creating in-vehicle apps, this architecture provides a powerful, secure, and modern foundation.