Get ready for an incredible driving experience as I unlock the secrets of Android Automotive! Just like your beloved gadgets and apps, now your car can deliver the same easy and exciting journey you’ve come to love. Picture this: seamless integration with your personal apps, an array of cutting-edge features, and a connection to the world at your fingertips!

The automotive industry is buzzing with excitement as Google’s Android Automotive OS takes the wheel. This sophisticated operating system is designed to elevate your driving experience to a whole new level — safe, connected, and entertaining.

Discover how car manufacturers worldwide are embracing Android Automotive OS. Some have already teamed up with Google to create state-of-the-art infotainment systems, powered by Google Automotive Services (GAS). Others are exploring the open-source AOSP with car extensions to craft their very own Android Automotive System.

Join me on this tech-filled journey as we dive into Android Automotive’s features, architecture, and compatibility, unlocking the full potential it holds for the future of transportation. Get ready to embrace the road ahead in style!

The journey of Android in the automotive industry

Evolution of In-Vehicle Infotainment (IVI)

The concept of IVI can be traced back to the earliest car radios, which allowed drivers and passengers to enjoy music while on the road. Over the years, IVI systems have undergone a significant transformation, adapting to advancements in technology and consumer demands. The integration of navigation systems, CD players, and later, DVD players marked key milestones in the evolution of IVI.

However, the real breakthrough came with the advent of smartphones and touch-screen technology. IVI systems now offer seamless integration with smartphones, enabling drivers to access their contacts, make hands-free calls, and use navigation apps directly from the car’s dashboard.

BTW, What is In-Vehicle Infotainment?

In-Vehicle Infotainment, commonly known as IVI, refers to the integrated multimedia system found in vehicles that provides entertainment, information, connectivity, and navigation services to drivers and passengers. These systems are designed to offer a wide array of features while ensuring minimal distraction to the driver, prioritizing safety on the road.

Android in the Car: Evolution and Advancements

Android’s entry into the automotive realm can be traced back to 2014 with the introduction of Android Auto. This groundbreaking technology allowed users to mirror their smartphone screens onto the car’s head unit display, providing access to various apps and functionalities while promoting safe driving practices.

Android Auto enabled drivers to interact with apps like Google Maps, Spotify, and messaging services using voice commands or simplified interfaces, reducing distractions while on the road. Around the same time, Apple CarPlay also emerged, offering a similar experience for iPhone users.

The Rise of Android Automotive OS

As the demand for a more integrated and seamless experience grew, the concept of Android Automotive OS came into play in 2017. Unlike Android Auto, Android Automotive OS operates directly within the car’s head unit, creating a dedicated Android environment for the vehicle.

Android Automotive OS extends beyond just mirroring smartphone apps and instead provides a complete operating system optimized for in-vehicle use. This level of integration offers a more unified and responsive user experience, with access to native apps and functionalities right from the head unit.

Polestar 2: Pioneering the Android Automotive Experience

A significant milestone in the Android automotive journey was marked by the launch of the Polestar 2. As the first vehicle to embrace Android Automotive OS fully, the Polestar 2 set a new standard for in-car technology. Powered by Google services, this all-electric vehicle showcased the potential of a fully integrated Android ecosystem within a car.

With Android Automotive OS, the Polestar 2 not only offered drivers seamless access to their favorite apps but also introduced intelligent voice assistants and personalized recommendations for an enhanced driving experience. Additionally, the system allowed over-the-air updates, ensuring that the vehicle’s software remained up-to-date with the latest features and improvements.

Android Open Source Project (AOSP) and Beyond

Behind the scenes, the Android Open Source Project (AOSP) has been the driving force behind the development of Android Automotive OS. AOSP serves as the foundation for Android, including its automotive variant, but it’s not a ready-to-deploy solution for automakers.

Automotive manufacturers require a front-end user interface, essential apps, and backend services to create a fully functional in-car experience. To address this, Google offers additional solutions and tools to assist automakers in developing custom interfaces and services on top of AOSP.

Google Automotive Services (GAS): Elevating the In-Car Experience

GAS provides a comprehensive set of integrated services, enhancing the functionality of Android Automotive OS. These services are akin to the familiar Google Mobile Services found on Android smartphones, ensuring a seamless user experience for drivers and passengers alike.

1. Play Store: GAS includes the Play Store, allowing users to discover and install a wide range of automotive and entertainment apps tailored for in-car use. This app marketplace opens up a world of possibilities, enabling drivers to customize their infotainment experience according to their preferences.
2. Google Assistant: With Google Assistant at their disposal, drivers can effortlessly interact with their vehicles using voice commands. From navigating to a destination to controlling media playback, Google Assistant’s natural language processing makes tasks while driving more convenient and safer.
3. Google Maps: The renowned mapping and navigation service, Google Maps, offers real-time traffic updates, turn-by-turn directions, and points of interest. Its integration in GAS ensures drivers have access to reliable and accurate navigation tools for a stress-free journey.

Operating with GAS: License Requirements and Quality Standards

To deploy GAS in their vehicles, automakers must obtain a per-unit license from Google. However, gaining access to GAS goes beyond just licensing; vehicles must also pass a series of tests, such as the Compatibility Test Suite (CTS), Vendor Test Suite (VTS), and Application Test Suite (ATS). These tests ensure that the integration of GAS meets Google’s stringent quality standards, providing a consistent and reliable experience across different car models.

Per-Unit License

When an automaker decides to integrate Google Automotive Services (GAS) into their vehicles, they must obtain a per-unit license from Google. This license is granted on a per-vehicle basis, meaning that for each individual car model that will use GAS, the automaker needs a separate license.

The per-unit license provides the automaker with the legal right to use Google’s suite of services, which includes popular applications such as the Play Store, Google Assistant, and Google Maps, as part of their infotainment system. These services enhance the overall user experience by offering access to a wide range of apps, voice-controlled assistance, and reliable navigation tools.

Quality Standards and Testing

To ensure a consistent and reliable experience for users across different car models and manufacturers, Google has established strict quality standards for GAS integration. These standards are verified through a series of tests:

1. Compatibility Test Suite (CTS): The Compatibility Test Suite evaluates whether the automaker’s implementation of GAS adheres to the defined standards and requirements set by Google. It checks if the system meets the necessary functionality, performance, and security criteria.
2. Vendor Test Suite (VTS): The Vendor Test Suite focuses on the hardware-specific aspects of the integration. It ensures that GAS functions seamlessly with the specific hardware components used in the infotainment system of each vehicle model.
3. Application Test Suite (ATS): The Application Test Suite assesses the compatibility of third-party apps with GAS. It ensures that apps from the Play Store, for example, work smoothly within the GAS environment and don’t cause conflicts or issues.

The automaker must thoroughly test their integration of GAS against these test suites and meet all the specified requirements. Successfully passing these tests is a crucial step in obtaining Google’s approval for using GAS in their vehicles.

Benefits of Meeting Quality Standards

Adhering to Google’s quality standards and passing the tests offers several significant benefits for the automaker and end-users:

1. Reliability: Meeting the quality standards ensures that the GAS integration functions reliably, minimizing potential glitches or disruptions in the in-car experience.
2. Consistency: A successful GAS integration means a consistent user experience across different car models from the same automaker or even across different manufacturers that have adopted GAS.
3. Access to Google Services: With GAS integration approved, the automaker gains access to a suite of Google services, offering users a familiar and feature-rich experience within their vehicles.
4. Future Compatibility: Complying with the quality standards ensures that the GAS integration will work well with future updates and improvements from Google, ensuring long-term support for the infotainment system.

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.

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).

Project Treble and Android Automotive OS

Project Treble is an initiative by Google introduced in Android 8.0 Oreo to address the challenges of Android fragmentation(Here Fragmentation refers to the situation where many Android devices run different versions of the operating system) and make it easier for device manufacturers to update their devices to newer Android versions. It separates the Android OS framework from the hardware-specific components, allowing manufacturers to update the Android OS without modifying the lower-level hardware drivers and firmware.

In the context of Android Automotive OS, Project Treble has a similar goal but is adapted to the specific needs of automotive infotainment systems. Android Automotive OS is built on top of the regular Android OS but is optimized for use in vehicles. It provides a customized user interface and integrates with car-specific hardware and features.

Project Treble in Android Automotive OS helps automotive manufacturers (OEMs) update their in-car infotainment systems more efficiently. Separating the Android OS framework from the hardware-specific components, allows OEMs to focus on developing and updating their unique infotainment features without being held back by delays caused by complex hardware integration.

Android Open Source Project (AOSP) Architecture

In the Android Open Source Project (AOSP) architecture, everything above the Android System Services is known as the “Android Framework,” and it is provided by Google. This includes various components like the user interface, app development framework, and system-level services.

On the other hand, the Hardware Abstraction Layer (HALs) and the Kernel are provided by System on a Chip (SoC) and hardware vendors. The HALs act as a bridge between the Android Framework and the specific hardware components, allowing the Android system to work efficiently with different hardware configurations.

In a groundbreaking move, Google extended the Android Open Source Project (AOSP) to create a complete in-vehicle infotainment operating system(we will look in detail later). Here’s a simple explanation of the extensions:

1. Car System Applications: Google added specific applications designed for in-car use, such as music players, navigation apps, and communication tools. These applications are optimized for easy and safe use while driving.
2. Car APIs: Google introduced specialized Application Programming Interfaces (APIs) that allow developers to access car-specific functionalities. These APIs provide standardized ways for apps to interact with car features like sensors and controls.
3. Car Services: Car Services are system-level components that handle car-specific functionalities, such as managing car sensors, audio systems, and climate controls. These services provide a consistent and secure way for apps to interact with car hardware.
4. Vehicle Hardware Abstraction Layer: To interact with the unique hardware components of different vehicles, Google developed the Vehicle Hardware Abstraction Layer (HAL). It acts as a bridge between the Android system and the specific hardware, enabling a seamless and consistent experience across various cars.

By combining these extensions with the existing Android system, Google created a fully functional and adaptable in-vehicle infotainment operating system. This system can be used in different vehicles without the need for significant modifications, offering a unified and user-friendly experience for drivers and passengers.

Treble Components

Project Treble introduced several new components to the Android architecture to enhance modularity and streamline the update process for Android devices.

Let’s briefly explain each of these components:

1. New HAL types: These are Hardware Abstraction Layers (HALs) that help the Android system communicate with various hardware components in a standardized way. They allow easier integration of different hardware into the Android system.
2. Hardware Interface Definition Language (HIDL): HIDL is a language used to define interfaces between HALs and the Android framework. It makes communication between hardware and software more efficient.
3. New Partitions: Treble introduced new partitions in the Android system, like the /vendor partition. These partitions help separate different parts of the system, making updates easier and faster.
4. ConfigStore HAL: This component manages configuration settings for hardware components. It provides a standardized way to access and update configuration data.
5. Device Tree Overlays: Device Tree Overlays enable changes to hardware configuration without having to modify the kernel. It allows for easier customization of hardware.
6. Vendor NDK: The Vendor Native Development Kit (NDK) provides tools and libraries for device manufacturers to develop software specific to their hardware. It simplifies the integration of custom functionalities.
7. Vendor Interface Object: The Vendor Interface Object (VINTF) defines a stable interface between the Android OS and the vendor’s HAL implementations. It ensures compatibility and smooth updates.
8. Vendor Test Suite (VTS): VTS is a testing suite that ensures HAL implementations work correctly with the Android framework. It helps in verifying the compatibility and reliability of devices.

Project Treble’s components make Android more modular, efficient, and customizable. They streamline communication with hardware, separate system components, and allow device manufacturers to update and optimize their devices more easily, resulting in a better user experience and faster Android updates.

Modularity in Android Automotive with Treble

Thanks to the architectural changes brought about by Project Treble and the expanded use of partitions, the future of Android Automotive has become significantly more flexible and adaptable. This enhancement extends beyond just the Human-Machine Interface (HMI) layer and allows for potential replacements of the Android framework, Board Support Package (BSP), and even the hardware if necessary.

In simpler terms, the core components of the Android Automotive system have been made more independent and modular. This means that manufacturers now have the freedom to upgrade or customize specific parts of the system without starting from scratch. The result is a highly future-proof system that can readily embrace emerging technologies and cater to evolving user preferences.

Let’s delve into the transition and see how this modularity was achieved after the implementation of Project Treble:

HALs before Treble

Before Project Treble, HAL interfaces were defined as C header files located in the hardware/libhardware folder of the Android system. Each new version of Android required the HAL to support a new interface, which meant significant effort and changes for hardware vendors.

In simpler terms, HALs used to be tightly coupled with the Android framework, and whenever a new Android version was released, hardware vendors had to update their HALs to match the new interfaces. This process was time-consuming and complex, leading to delays in device updates and making it difficult to keep up with the latest Android features.

Project Treble addressed this issue by introducing the Hardware Interface Definition Language (HIDL). With HIDL, HAL interfaces are now defined in a more standardized and independent way, making it easier for hardware vendors to implement and update their HALs to support new Android versions. This change has significantly improved the efficiency of Android updates and allowed for a more flexible and future-ready Android ecosystem.

Pass-through HALs

In the context of Android Automotive, Pass-through HALs are special Hardware Abstraction Layers (HALs) that use the Hardware Interface Definition Language (HIDL) interface. The unique aspect of Pass-through HALs is that you can directly call them from your application’s process, without going through the usual Binder communication.

To put it simply, when an app wants to interact with a regular HAL, it communicates using the Binder mechanism, which involves passing messages between different processes. However, with Pass-through HALs, you can directly communicate with the HAL from your app’s process. This direct calling approach can offer certain advantages in terms of efficiency and performance for specific tasks in the automotive context. It allows apps to access hardware functionalities with reduced overhead and faster response times.

Binderized HALs

In the Android Automotive context, Binderized HALs run in their dedicated processes and are accessible only through Binder Inter-Process Communication (IPC) calls. This setup ensures that the communication between the Android system and the HALs is secure and efficient.

Regarding Legacy HALs, Google has already created a wrapper to make them work in a Binderized environment. This wrapper acts as an intermediary layer, allowing the existing Legacy HALs to communicate with the Android framework through the Binder IPC mechanism. As a result, these Legacy HALs can seamlessly function alongside Binderized HALs, ensuring compatibility and a smooth transition to the new architecture.

In essence, the wrapper provides a bridge between the legacy hardware components and the modern Android system, enabling Legacy HALs to work cohesively in the Binderized environment. This approach ensures that the Android Automotive system can benefit from the improved performance and security of Binderized HALs while still supporting and integrating with older hardware that relies on Legacy HALs.

Ideal HALs

In an ideal scenario, Binderized HALs are the preferred approach for Hardware Abstraction Layers (HALs) in Android. Binderized HALs run in their dedicated processes and are accessed through the secure Binder Inter-Process Communication (IPC) mechanism. This design ensures efficient communication, better security, and separation of hardware functionalities from the Android system.

However, for some reasons, we didn’t bother implementing Binderized HALs as intended. Instead, we are using a different approach, possibly using legacy HALs that were not originally designed for Binder IPC. While this alternative approach may work, it might not provide the full benefits of Binderized HALs, such as improved performance and security.

It’s important to recognize that sticking to the ideal Binderized HALs offers several advantages and aligns with the best practices recommended by Google. If possible, it’s better to consider transitioning to Binderized HALs for a more robust and efficient Android Automotive system.

Detailed Architecture

Now, as you know, in Android 8.0, the Android operating system underwent a re-architecture to establish clear boundaries between the device-independent Android platform and device- or vendor-specific code. Before this update, Android had already defined interfaces called HAL interfaces, which were written in C headers located in hardware/libhardware.

With the re-architecture, these HAL interfaces were replaced by a new concept called HIDL (HAL Interface Definition Language). HIDL offers stable and versioned interfaces, which can be either written in Java or as client- and server-side HIDL interfaces in C++.

The primary purpose of HIDL interfaces is to be used from native code, especially focused on enabling the auto-generation of efficient C++ code. This is because native code is generally faster and more efficient for low-level hardware interactions. However, to maintain compatibility and support various Android subsystems, some HIDL interfaces are also exposed directly to Java code.

For instance, certain Android subsystems like Telephony utilize Java HIDL interfaces to interact with underlying hardware components. This allows them to benefit from the stable and versioned interface definitions provided by HIDL, ensuring seamless communication between the device-independent Android platform and device-specific code.

Architecture of Android Automotive OS in Car

Android Automotive OS, a specialized version of the Android operating system, is designed to power in-car infotainment and other connected services. It serves as the primary operating system, providing access to various car services and applications.

It consists of three main components: the Vehicle HAL, Car Service, and Car Manager. Let’s take a closer look at how they work together.

Starting at the bottom layer are the Electronic Control Units (ECUs) connected to the vehicle bus, typically a CAN(Controller Area Network) bus. ECUs are integral to the vehicle as they monitor and control various aspects of its operation.

On the Android side, we have the Vehicle Hardware Abstraction Layer (VHAL). VHAL translates signals from the vehicle bus into vehicle properties, with over 150 predefined “system” properties in Android 12. For example, “PERF_VEHICLE_SPEED” represents the vehicle’s speed in meters per second, and manufacturers can add their own “vendor” properties.

The Car Service builds upon these vehicle properties and enriches them with additional information from other sources, creating a set of useful services for applications.

Applications don’t directly call the Car Service; instead, they interact with the Car Manager library, which implements the android.car.* packages. Demo car apps in the Android Open Source Project (AOSP) showcase how these android.car classes are meant to be used. These apps are typically pre-installed by the vehicle manufacturer and can access low-level functions, such as controlling the car’s side windows.

Finally, there are third-party Auto apps available on the Play Store or other app stores. These apps have limited access to certain parts of the car and must adhere to guidelines to prevent driver distraction. They offer functionalities like music streaming, audio books, and navigation.

Android Automotive OS (AAOS) Detailed architecture view

Android Automotive’s software component architecture is a layered system that allows seamless interaction between Car Apps, Car Manager, Car Service, and the underlying Vehicle HAL and ECUs.

This detailed architecture view enables developers and vehicle manufacturers to create innovative, safe, and user-friendly applications for an enhanced driving experience.

Vehicle HAL

The Vehicle HAL (Hardware Abstraction Layer) is a component that manages information about a vehicle and its functionalities. It stores this information as “Vehicle Properties.” These properties are like data points that represent various aspects of the vehicle.

For instance, some common Vehicle Properties include:

speed: a float value representing the vehicle’s speed in meters per second.

heating control setting: a float value indicating the temperature set for the heating system in degrees Celsius.

These properties are often linked to signals on the vehicle’s communication bus. When a signal changes on the bus, it can update the corresponding property in the Vehicle HAL. Additionally, these properties can be changed programmatically through an Android application.

In short, the Vehicle HAL manages and stores vehicle-related information as properties, and these properties can be updated both from signals on the vehicle bus and programmatically through an Android app.

System Property Identifiers

System Property Identifiers in the Vehicle HAL are unique labels used to categorize and identify specific properties. They are marked with the tag “VehiclePropertyGroup:SYSTEM” to distinguish them from other types of properties.

In Android 12, there are more than 150 such identifiers. Each identifier represents a different property related to the vehicle’s system and functionalities. For example, one of these identifiers is “HVAC_TEMPERATURE_SET,” which stands for the target temperature set for the vehicle’s HVAC system.

Let’s break down the details of the “HVAC_TEMPERATURE_SET” identifier:

• Property Name: HVAC_TEMPERATURE_SET
• Description: Represents the target temperature set for the HVAC (Heating, Ventilation, and Air Conditioning) system in the vehicle.
• Change Mode: The property is monitored in the “ON_CHANGE” mode, which means an event is triggered whenever the target temperature changes.
• Access: The property can be both read and written, allowing applications to retrieve the current target temperature and update it programmatically.
• Unit: The temperature values are measured in Celsius (°C).

System Property Identifiers in the Vehicle HAL are unique labels that categorize different properties related to the vehicle’s system. They provide standardized access to various functionalities, such as setting the target temperature for the HVAC system. By using these identifiers, Android applications can seamlessly interact with the vehicle’s hardware, enhancing user experience and control over various vehicle features.

Extending VehicleProperty

The Vehicle HAL also allows developers to extend the range of available Vehicle Properties by adding their own identifiers marked with “VehiclePropertyGroup:VENDOR.” This capability allows developers to tailor their applications to specific vehicle hardware and functionalities.

Extending a VehicleProperty requires defining the identifier in native code as shown below:

Native code:

constexpr int VENDOR_EXAMPLE = (int)(0x1001 | VehiclePropertyGroup::VENDOR | VehiclePropertyType::INT32 | VehicleArea::GLOBAL);

In C++, we define a new constant called “VENDOR_EXAMPLE” with a hexadecimal value of 0x1001. We use bitwise OR (|) to combine it with flags for VehiclePropertyGroup, VehiclePropertyType, and VehicleArea. The flags VehiclePropertyGroup::VENDOR indicate that it’s a vendor-specific property, VehiclePropertyType::INT32 indicates it’s an integer property, and VehicleArea::GLOBAL specifies that it applies globally to the vehicle.

Alternatively, it can be defined in Java as follows:

Java:

private static final int VENDOR_EXAMPLE = 0x1001 | VehiclePropertyGroup.VENDOR | VehiclePropertyType.INT32 | VehicleArea.GLOBAL;

In Java, we define a new private static final variable called “VENDOR_EXAMPLE” with a hexadecimal value of 0x1001. We use bitwise OR (|) to combine it with flags for VehiclePropertyGroup, VehiclePropertyType, and VehicleArea. The flags VehiclePropertyGroup.VENDOR indicate that it’s a vendor-specific property, VehiclePropertyType.INT32 indicates it’s an integer property, and VehicleArea.GLOBAL specifies that it applies globally to the vehicle.

This code allows you to create a new vendor-specific property called “VENDOR_EXAMPLE” that can be accessed and used in both C++ and Java code. It’s an integer property applicable globally to the vehicle, and the unique identifier 0x1001 helps distinguish it as a vendor-specific property.

VHAL Interfaces (IVehicle):

IVehicle.hal file

Please note that the below .hal files are not Java, C++ or scss files (I selected “auto mode” so it will take Java, C++, or scss)

BTW, What is .hal file?

A .hal file is a Hardware Abstraction Layer (HAL) file that defines the interface between a hardware device and the Android operating system. HAL files are written in the Hardware Interface Description Language (HIDL), which is a language for describing hardware interfaces in a platform-independent way.

package android.hardware.automotive.vehicle@2.0;
import IVehicleCallback;
interface IVehicle {
  /**
   * Returns a list of all property configurations supported by this vehicle
   * HAL.
   */
  getAllPropConfigs() generates (vec<VehiclePropConfig> propConfigs);
  /**
   * Returns a list of property configurations for given properties.
   *
   * If requested VehicleProperty wasn't found it must return
   * StatusCode::INVALID_ARG, otherwise a list of vehicle property
   * configurations with StatusCode::OK
   */
  getPropConfigs(vec<int32_t> props)
          generates (StatusCode status, vec<VehiclePropConfig> propConfigs);
  /**
   * Get a vehicle property value.
   *
   * For VehiclePropertyChangeMode::STATIC properties, this method must always
   * return the same value always.
   * For VehiclePropertyChangeMode::ON_CHANGE properties, it must return the
   * latest available value.
   *
   * Some properties like AUDIO_VOLUME requires to pass additional data in
   * GET request in VehiclePropValue object.
   *
   * If there is no data available yet, which can happen during initial stage,
   * this call must return immediately with an error code of
   * StatusCode::TRY_AGAIN.
   */
  get(VehiclePropValue requestedPropValue)
          generates (StatusCode status, VehiclePropValue propValue);
  /**
   * Set a vehicle property value.
   *
   * Timestamp of data must be ignored for set operation.
   *
   * Setting some properties require having initial state available. If initial
   * data is not available yet this call must return StatusCode::TRY_AGAIN.
   * For a property with separate power control this call must return
   * StatusCode::NOT_AVAILABLE error if property is not powered on.
   */
  set(VehiclePropValue propValue) generates (StatusCode status);
  /**
   * Subscribes to property events.
   *
   * Clients must be able to subscribe to multiple properties at a time
   * depending on data provided in options argument.
   *
   * @param listener This client must be called on appropriate event.
   * @param options List of options to subscribe. SubscribeOption contains
   *                information such as property Id, area Id, sample rate, etc.
   */
  subscribe(IVehicleCallback callback, vec<SubscribeOptions> options)
          generates (StatusCode status);
  /**
   * Unsubscribes from property events.
   *
   * If this client wasn't subscribed to the given property, this method
   * must return StatusCode::INVALID_ARG.
   */
  unsubscribe(IVehicleCallback callback, int32_t propId)
          generates (StatusCode status);
  /**
   * Print out debugging state for the vehicle hal.
   *
   * The text must be in ASCII encoding only.
   *
   * Performance requirements:
   *
   * The HAL must return from this call in less than 10ms. This call must avoid
   * deadlocks, as it may be called at any point of operation. Any synchronization
   * primitives used (such as mutex locks or semaphores) must be acquired
   * with a timeout.
   *
   */
  debugDump() generates (string s);
};

getAllPropConfigs():

This interface returns a list of all the properties that are supported by the VHAL. This list includes the property ID, property type, and other metadata.

• Generates (vec<VehiclePropConfig> propConfigs).
• Lists the configuration of all properties supported by the VHAL.
• CarService uses supported properties only.

getPropConfigs(vec<int32_t> props):

This interface returns the configuration of a specific property. The configuration includes the property ID, property type, access permissions, and other metadata.

• Generates (StatusCode status, vec<VehiclePropConfig> propConfigs).
• Returns the configuration of selected properties.
• Allows querying the configuration of specific properties.

set(VehiclePropValue propValue):

This interface allows you to write a value to a property. The value that you write must be of the correct type for the property.

• Generates (StatusCode status).
• Writes a value to a property.
• The result of the write operation is defined per property.

subscribe(IVehicleCallback callback, vec<SubscribeOptions> options):

This interface allows you to subscribe to a property so that you are notified when its value changes. The callback that you provide will be called whenever the value of the property changes.

• Generates (StatusCode status).
• Starts monitoring a property value change.
• For zoned properties, there is an additional unsubscribe(IVehicleCallback callback, int32_t propId) method to stop monitoring a specific property for a given callback.

VHAL Callback Interfaces:

IVehicleCallback.hal

package android.hardware.automotive.vehicle@2.0;
interface IVehicleCallback {
    /**
     * Event callback happens whenever a variable that the API user has
     * subscribed to needs to be reported. This may be based purely on
     * threshold and frequency (a regular subscription, see subscribe call's
     * arguments) or when the IVehicle#set method was called and the actual
     * change needs to be reported.
     *
     * These callbacks are chunked.
     *
     * @param values that has been updated.
     */
    oneway onPropertyEvent(vec<VehiclePropValue> propValues);
    /**
     * This method gets called if the client was subscribed to a property using
     * SubscribeFlags::SET_CALL flag and IVehicle#set(...) method was called.
     *
     * These events must be delivered to subscriber immediately without any
     * batching.
     *
     * @param value Value that was set by a client.
     */
    oneway onPropertySet(VehiclePropValue propValue);
    /**
     * Set property value is usually asynchronous operation. Thus even if
     * client received StatusCode::OK from the IVehicle::set(...) this
     * doesn't guarantee that the value was successfully propagated to the
     * vehicle network. If such rare event occurs this method must be called.
     *
     * @param errorCode - any value from StatusCode enum.
     * @param property - a property where error has happened.
     * @param areaId - bitmask that specifies in which areas the problem has
     *                 occurred, must be 0 for global properties
     */
    oneway onPropertySetError(StatusCode errorCode,
                              int32_t propId,
                              int32_t areaId);
};

After seeing this file you might be wondering about, what is oneway method.

A oneway method in a HAL file is a method that does not require a response from the hardware device. Oneway methods are typically used for asynchronous operations, such as sending a command to the hardware device or receiving a notification from the hardware device.

Here is an example of a oneway method in a HAL file:

oneway void setBrightness(int brightness);

This method sets the brightness of the hardware device to the specified value. The method does not require a response from the hardware device, so the caller does not need to wait for the method to complete before continuing.

Oneway methods are often used in conjunction with passthrough HALs. Passthrough HALs are HALs that run in the same process as the calling application. This means that oneway methods in passthrough HALs can be invoked directly by the calling application, without the need for a binder call.

onPropertyEvent(vec<VehiclePropValue> propValues):

This callback is called whenever the value of a property that you are subscribed to changes. The callback will be passed a list of the properties that have changed and their new values.

• A one-way callback function.
• Notifies vehicle property value changes to registered callbacks.
• This function should be used only for properties that have been subscribed to for monitoring.

onPropertySetError(StatusCode errorCode, int32_t propId, int32_t areaId):

This callback is called if an error occurs when you try to set the value of a property. The callback will be passed the error code and the property ID that was being set.

• A one-way callback function.
• Notifies errors that occurred during property write operations.
• The error can be related to the VHAL level or specific to a property and an area (in the case of zoned properties).

These interfaces and callbacks form the core communication mechanism between the VHAL and other components, such as CarService and applications, allowing for the configuration, querying, writing, and monitoring of vehicle properties. The usage of these interfaces may vary depending on the specific implementation of the VHAL in different systems or platforms.

Properties Monitoring and Notification

In the context of the Vehicle Hardware Abstraction Layer (VHAL) and its properties, the IVehicle::subscribe method and IVehicleCallback::onChange callback are used for monitoring changes in vehicle properties. Additionally, there is a ChangeMode enum that defines how the properties behave in terms of their update frequency.

IVehicle::subscribe

• The IVehicle::subscribe method is used to register a callback (implementing IVehicleCallback) to receive updates when the subscribed properties change.
• This method allows applications to start monitoring specific vehicle properties for value changes.

IVehicleCallback::onChange

• The IVehicleCallback::onChange callback function is invoked when there are updates to the subscribed properties.
• When a property changes and the VHAL detects the change, it notifies all registered callbacks using this callback function.

ChangeMode Enum

• The ChangeMode enum defines how a particular property behaves in terms of its update frequency. It has the following possible values:
• STATIC: The property never changes.
• ON_CHANGE: The property only signals an event when its value changes.
• CONTINUOUS: The property constantly changes and is notified at a sampling rate set by the subscriber.

These definitions allow applications to subscribe to properties with different update behaviors based on their specific needs. For example, if an application is interested in monitoring the vehicle speed, it may subscribe to the speed property with the CONTINUOUS change mode to receive a continuous stream of speed updates at a certain sampling rate. On the other hand, if an application is interested in the vehicle’s daytime/nighttime mode, it may subscribe with the ON_CHANGE change mode to receive updates only when the mode changes from day to night or vice versa.

The use of these definitions and methods allows for efficient monitoring and notification of changes in vehicle properties, ensuring that applications can stay up-to-date with the latest data from the vehicle’s sensors and systems.

Car Service

The car service is a system service that provides a number of APIs for applications to interact with the vehicle’s hardware and software. It is implemented as a persistent, system app named com.android.car. The service name is car_service, and the interface is android.car.ICar.

You can think of it like a special app that the car uses, called “com.android.car”. Its main job is to make sure the tools are available for other apps.

If you want to talk to Car Service, you use something called “android.car.ICar”. To get more information about the car service, you can use the dumpsys car_service command. This command will print out a list of all the available APIs and their descriptions. You can also use the -h option to get a list of all the available options.

The code for Car Service is located in a place called “packages/services/Car/service”.

Car Manager

The Car Manager is like a supervisor for the car-related tasks in Android. It’s made up of special classes that create a way for apps to work with car-related stuff. These classes are in the “android.car.*” group, and they make up the tools for Android Automotive.

You can think of Car Manager as a special set of instructions that apps can follow to interact with car-related things. If you want to learn more about these classes, you can check out the link “https://developer.android.com/reference/android/car/classes“.

Car Manager is a library that comes with the Android system and is located in a place called “/system/framework/android.car.jar”. This library helps the device manage car-related tasks and interactions.

The code that makes up Car Manager is in the “packages/services/Car/car-lib” location.

Car Manager Interfaces: A Brief Overview

The Car Manager encompasses an array of 23 distinct interfaces, each tailored to manage specific aspects of the vehicle’s digital infrastructure. These interfaces serve as pathways through which different services and applications communicate, collaborate, and coexist harmoniously. From input management to diagnostic services, the Car Manager interfaces span a spectrum of functionalities that collectively enhance the driving experience.

PROPERTY_SERVICE:

The PROPERTY_SERVICE interface plays a crucial role in the Car Manager ecosystem. It serves as a gateway to access and manage various vehicle properties. These properties encompass a wide range of information, including vehicle speed, fuel level, engine temperature, and more. Applications and services can tap into this interface to gather real-time data, enabling them to offer users valuable insights into their vehicle’s performance.

Permissions and Security

One crucial aspect of the PROPERTY_SERVICE interface is its robust permission system. Access to vehicle properties is regulated, ensuring that applications adhere to strict security measures. Each property is associated with specific permissions that must be granted for an app to access it.

Code and Implementation

The core functionality of the PROPERTY_SERVICE (CarPropertyManager) is implemented in the “CarPropertyManager.java” file, which resides within the “packages/services/Car/car-lib/src/android/car/hardware/property/” directory. This file encapsulates the methods, data structures, and logic required to facilitate seamless communication between applications and vehicle properties.

INFO_SERVICE:

The INFO_SERVICE interface serves as an information hub within the Car Manager framework. It facilitates the exchange of data related to the vehicle’s status, health, and performance. This interface enables applications to access diagnostic information, maintenance schedules, and any potential issues detected within the vehicle.

Permissions and Security

To ensure the security and privacy of vehicle information, the CarInfoManager enforces a robust permission system. Access to static vehicle information is governed by the “PERMISSION_CAR_INFO” permission, granted at the “normal” level. This approach guarantees that only authorized applications can access critical data about the vehicle.

Code and Implementation

The core functionality of the CarInfoManager is encapsulated within the “CarInfoManager.java” file. This file resides in the “packages/services/Car/car-lib/src/android/car/” directory and contains the methods, structures, and logic necessary for retrieving and presenting static vehicle information to applications.

CAR_UX_RESTRICTION_SERVICE:

As safety and user experience take center stage in the automotive industry, the CAR_UX_RESTRICTION_SERVICE interface emerges as a critical player. This interface is designed to manage and enforce user experience restrictions while the vehicle is in motion. It ensures that applications adhere to safety guidelines, preventing distractions that could compromise the driver’s focus on the road.

Implementation and Code: CarUxRestrictionsManager.java

The core functionality of the CarUxRestrictionsManager is implemented in the CarUxRestrictionsManager.java file. This file can be found in the following directory: packages/services/Car/car-lib/src/android/car/drivingstate/. Within this file, you’ll find the logic, methods, and data structures that facilitate the communication between the CarDrivingStateManager and other relevant components.

Design Structure of CarService

The CarService plays a crucial role in the Android Car Data Framework, providing a structured and organized approach to accessing a range of car-specific services. Here we aim to dissect the architecture and design of the CarService, focusing on its implementation and the interaction of various components. We’ll use the CarProperty service as an example to illustrate the design pattern, recognizing that a similar approach is adopted for other CarServices within the CarImpl.

The car-lib makes use of the reference to the CarProperty Android service by calling the getCarServices(“property”) AIDL method, as provided by ICar. This very generic and simple method is implemented by the CarService in ICarImpl to return the specific service requested through the getCarService method, specified with the name of the service as its parameter. Thus, ICarImpl follows the Factory pattern implementation, which returns the IBinder object for the requested service. Within the car-lib, Car.Java will obtain the service reference by calling the specific client interface using ICarProperty.Stub.asInterface(binder). With the returned service reference, the CarPropertyManager will access the methods as implemented by the CarPropertyService. As a result, the car service framework-level service access is abstracted following this implementation pattern, and applications will include car-lib and utilize Car.Java to return respective Manager class objects.

Here is a short summary of the flow:

• Your application (car-lib) uses the Car service framework to access specific vehicle functionalities.
• You request a specific service (e.g., CarProperty) using the getCarService method provided by ICarImpl.
• ICarImpl returns a Binder object representing the requested service.
• You convert this Binder object into an interface using .asInterface(binder).
• This interface allows your application to interact with the service (e.g., CarPropertyService) in a more abstract and user-friendly manner.

Understanding the pattern of classes and their relationships is important when adding new services under CarServices or making modifications to existing service implementations, such as extending CarMediaService to add new capabilities or updating CarNavigationServices to enhance navigation information data.

Car Properties and Permissions

Accessing car properties through the Android Car Data Framework provides developers with a wealth of vehicle-specific data, enhancing the capabilities of automotive applications. However, certain properties are protected by permissions, requiring careful consideration and interaction with user consent. Let’s jump into the concepts of car properties, permissions, and the nuanced landscape of access within the CarService framework.

Understanding Car Properties

Car properties encapsulate various aspects of vehicle data, ranging from basic information like the car’s VIN (Vehicle Identification Number) to more intricate details.

String vin = propertyManager.getProperty<String>(INFO_VIN, VEHICLE_AREA_TYPE_GLOBAL)?.value

All of the car properties are defined in the VehiclePropertyIds file. They can be read with CarPropertyManager. However, when trying to read the car VIN, a SecurityException is thrown. This means the app needs to request user permission to access this data.

Car Permissions

Just like a bouncer at a club, Android permissions control which apps can access specific services. This ensures that only the right apps get the keys to the digital kingdom. When it comes to the Car Service, permissions play a crucial role in determining which apps can tap into its features.

However, the Car Service is quite selective about who gets what. Here are a few permissions that 3rd party apps can ask for and possibly receive:

1. CAR_INFO: Think of this as your car’s digital diary. Apps with this permission can access general information about your vehicle, like its make, model, and year.
2. READ_CAR_DISPLAY_UNITS: This permission lets apps gather data about your car’s display units, such as screen size and resolution. It’s like letting apps know how big the stage is.
3. CONTROL_CAR_DISPLAY_UNITS: With this permission, apps can actually tweak your car’s display settings. It’s like allowing them to adjust the stage lighting to set the perfect ambiance.
4. CAR_ENERGY_PORTS: Apps with this permission can monitor the energy ports in your car, like charging points for electric vehicles. It’s like giving them the backstage pass to your car’s energy sources.
5. CAR_EXTERIOR_ENVIRONMENT: This permission allows apps to access data about the external environment around your car, like temperature and weather conditions. It’s like giving them a sensor to feel the outside world.
6. CAR_POWERTRAIN, CAR_SPEED, CAR_ENERGY: These permissions grant apps access to your car’s powertrain, speed, and energy consumption data. It’s like letting them peek under the hood and see how your car performs.

Now, here’s the twist: some permissions are VIP exclusive. They’re marked as “signature” or “privileged,” and only apps that are built by the original equipment manufacturer (OEM) and shipped with the platform can get them. These are like the golden tickets reserved for the chosen few — they unlock advanced features and deeper integrations with the Car Service.

Car Apps

Car apps form an integral part of the connected car ecosystem, enabling drivers and passengers to access a wide variety of features and services. These apps cater to different aspects of the driving experience, from entertainment and communication to navigation and vehicle control. Let’s explore some noteworthy examples of car apps:

1. CarLauncher: Picture this as your car’s home screen. The CarLauncher app greets you with a user-friendly interface, helping you access other apps and features effortlessly.
2. CarHvacApp: When you need to adjust the temperature in your car, the CarHvacApp steps in. It’s like a digital thermostat, allowing you to control the heating, ventilation, and air conditioning with ease.
3. CarRadioApp: The CarRadioApp is your virtual DJ, giving you access to radio stations and helping you tune in to your favorite music and shows.
4. CarDialerApp: Need to make a call while driving? The CarDialerApp is your go-to. It lets you make calls without taking your eyes off the road.
5. CarMapsPlaceholder: Although not specified, this app hints at the potential for navigation and maps. It could become your digital navigator, guiding you through unknown territories.
6. LocalMediaPlayer: If you’re in the mood for some tunes, the LocalMediaPlayer app has you covered. It’s your personal music player, allowing you to enjoy your favorite tracks during your drive.
7. CarMessengerApp: Stay connected without distractions using the CarMessengerApp. It handles messages and notifications, ensuring you can stay in touch while staying safe.
8. CarSettings: Just like the settings on your phone, the CarSettings app lets you personalize your driving experience. Adjust preferences, set up connections, and more, all from the driver’s seat.
9. EmbeddedKitchenSinkApp: This app is like a Swiss Army knife of demos! It showcases a variety of features and possibilities, giving you a taste of what your car’s technology can do.

These apps can be found in the “packages/apps/Car/” and “packages/services/Car/” directories. They’re designed to enhance your driving journey, making it safer, more enjoyable, and personalized. Whether you need navigation, communication, entertainment, or just a touch of convenience, Car Apps have you covered.

Third-Party Car Apps

When it comes to third-party apps for Car and Automotive, there are a few important things to keep in mind. These apps fall into specific categories, each offering unique functionalities while keeping driver distraction in check. Let’s take a look at the supported app categories:

1. Media (Audio) Apps: These apps transform your car into a mobile entertainment center. They allow you to enjoy your favorite music, podcasts, and audio content while driving, keeping you entertained throughout your journey.
2. Messaging Apps: Messaging apps take a hands-free approach. They use text-to-speech and voice input to let you stay connected without taking your hands off the wheel or your eyes off the road. You can receive and send messages while keeping your focus on driving.
3. Navigation, Parking, and Charging Apps (New in 2021): The latest addition to the lineup, these apps are your navigational companions. They help you find your way with turn-by-turn directions, locate parking spots, and even guide you to charging stations for electric vehicles.

To ensure that these third-party apps meet the highest standards of quality and safety, Google has provided a set of references and guidelines for developers:

1. Getting Started with Car Apps: https://developer.android.com/training/cars/start
2. Quality Guidelines for Car Apps: https://developer.android.com/docs/quality-guidelines/car-app-quality
3. Navigation Guidelines for Car Apps: https://developer.android.com/training/cars/navigation

These apps, available on platforms like the Play Store for Auto and Automotive, are tailored to provide a safe and streamlined experience while you’re on the road. Here’s what you should know:

1. Limited Access to System APIs: Third-party apps don’t have free reign over the car’s system APIs. They operate within controlled boundaries to ensure that your driving experience remains secure and focused.
2. Stricter Restrictions for Safety: The focus is squarely on safety. Third-party apps are subject to strict limitations to minimize any potential distractions for drivers. This ensures that your attention stays where it matters most: on the road.
3. Google’s Driver Distraction Guidelines: Google takes driver distraction seriously. Before an app can be listed on Google Play for Android Automotive OS and Android Auto, it must adhere to specific design requirements. These guidelines are in place to ensure that apps contribute to a safe driving environment.

It’s important to note that while third-party apps for Cars and Automotive may have certain limitations, they still play a valuable role in enhancing your driving experience. They provide convenience, entertainment, and useful features, all while maintaining a strong commitment to safety.

So, the next time you explore third-party apps for your car, remember that they’re designed with your well-being in mind.

Developing for Android Automotive

The realm of Android development has extended its reach beyond smartphones and tablets, embracing the automotive landscape with open arms. Developers now have the opportunity to create apps that enhance the driving experience, making vehicles smarter, safer, and more connected. In this context, let’s delve into exploring the tools, requirements, and considerations that drive this exciting endeavor.

Key highlights of developing for Android Automotive include:

1. SDK Availability: Android Studio offers automotive SDKs for Android versions R/11, S/12, and T/13. These SDKs extend their capabilities to the automotive domain, providing developers with the tools and resources they need to create engaging and functional automotive apps.
2. Minimum Android Studio Version: To develop automotive apps, developers need Android Studio version 4.2 or higher. This version includes the necessary tools and resources for automotive development, such as the Automotive Gradle plugin and the Automotive SDK.
3. Transition to Stability: Android Studio version 4.2 transitioned to a stable release in May 2021. This means that it is the recommended version for automotive development. However, developers can also use the latest preview versions of Android Studio, which include even more features and improvements for automotive development.

Automotive AVD for Android Automotive Car Service Development

The Automotive AVD (Android Virtual Device) provides developers with a platform to emulate Android Automotive systems, facilitating the refinement of apps and services before deployment to physical vehicles. Let’s explore the key components and aspects of the Automotive AVD.

SDK and System Image

The Automotive AVD operates within the Android 10.0 (Q) (latest T/13) software development kit (SDK). This SDK version is specifically tailored to the needs of Android Automotive Car Service. The AVD utilizes the “Automotive with Google Play Intel x86 Atom” system image, replicating the architecture and features of an Android Automotive environment on Intel x86-based hardware.

AVD Configuration

The AVD configuration is structured around the “Automotive (1024p landscape) API 29” and in the latest “Automotive (1024p landscape) API 32” setup. This configuration mimics a landscape-oriented 1024p (pixels) display, which is representative of the infotainment system commonly found in vehicles. This choice of resolution and orientation ensures that developers can accurately assess how their apps will appear and function within the context of an automotive display.

Exterior View System (EVS)

In the fast-paced world of automotive technology, every second counts, especially when it comes to ensuring the safety of both drivers and pedestrians. One crucial component in modern vehicles is the rearview camera, which provides drivers with a clear view of what’s behind them. However, the challenge arises when the camera system needs to be up and running within mere seconds of ignition, while the Android operating system, which controls many of the vehicle’s functions, takes significantly longer to boot. Here we will explore a groundbreaking solution to this problem — the Exterior View System (EVS), a self-contained application designed to minimize the delay between ignition and camera activation.

Problem

In vehicles, there is a camera located at the rear (back) of the vehicle to provide the driver with a view of what’s behind them. This camera is useful for parking, reversing, and overall safety. However, there is a requirement that this rearview camera should be able to show images on the display screen within 2 seconds of the vehicle’s ignition (engine start) being turned on.

Challenge

The challenge is that many vehicles use the Android operating system to power their infotainment systems, including the display screen where the rearview camera’s images are shown. Android, like any computer system, takes some time to start up. In this case, it takes tens of seconds (meaning around 10 or more seconds) for Android to fully boot up and become operational after the ignition is turned on.

Solution

Exterior View System (EVS): To address the problem of the slow boot time of Android and ensure that the rearview camera can show images within the required 2 seconds, a solution called the Exterior View System (EVS) is proposed.

So, What is Exterior View System (EVS)

The Exterior View System (EVS) emerges as a pioneering solution to the problem of delayed camera activation. Unlike traditional camera systems that rely heavily on the Android OS, EVS is an independent application developed in C++. This approach drastically reduces the system’s dependency on Android, allowing EVS to become operational within a mere two seconds of ignition.

The Exterior View System (EVS) in Android Automotive is a hardware abstraction layer (HAL) that provides support for rearview and surround view cameras in vehicles. EVS enables OEMs to develop and deploy advanced driver assistance systems (ADAS) and other safety features that rely on multiple camera views.

The EVS HAL consists of a number of components, including:

• A camera manager that provides access to the vehicle’s cameras
• A display manager that controls the output of the camera streams
• A frame buffer manager that manages the memory used to store camera frames
• A sensor fusion module that combines data from multiple cameras to create a single, unified view of the vehicle’s surroundings.

Architecture

The Exterior View System’s architecture is designed to maximize efficiency and speed while maintaining a seamless user experience. The following system components are present in the EVS architecture:

EVS Application

There’s an EVS application example written in C++ that you can find at /packages/services/Car/evs/app. This example shows you how to use EVS. The job of this application is to ask the EVS Manager for video frames and then send these frames to the EVS Manager so they can be shown on the screen. It’s designed to start up as soon as the EVS and Car Service are ready, usually within two seconds after the car turns on. Car makers can change or use a different EVS application if they want to.

EVS Manager

The EVS Manager, located at /packages/services/Car/evs/manager, is like a toolbox for EVS applications. It helps these applications create different things, like showing a basic rearview camera view or even a complex 6DOF(Six degrees of freedom (6DOF) refers to the specific number of axes that a rigid body is able to freely move in three-dimensional space.) multi-camera 3D view. It talks to the applications through HIDL, a special communication way in Android. It can work with many applications at the same time.

Other programs, like the Car Service, can also talk to the EVS Manager. They can ask the EVS Manager if the EVS system is up and running or not. This helps them know when the EVS system is working.

EVS HIDL interface

The EVS HIDL interface is how the EVS system’s camera and display parts talk to each other. You can find this interface in the android.hardware.automotive.evs package. There’s an example version of it in /hardware/interfaces/automotive/evs/1.0/default that you can use to test things out. This example makes fake images and checks if they work properly.

The car maker (OEM) needs to make the actual code for this interface. The code is based on the .hal files in /hardware/interfaces/automotive/evs. This code sets up the real cameras, gets their data, and puts it in special memory areas that Gralloc (Gralloc is a type of shared memory that is also shared with the GPU) understands. The display part of the code has to make a memory area where the app can put its images (usually using something called EGL), and then it shows these images on the car screen. This display part is important because it makes sure the app’s images are shown instead of anything else on the screen. Car makers can put their own version of the EVS code in different places, like /vendor/… /device/… or hardware/… (for example, /hardware/[vendor]/[platform]/evs).

Kernel drivers

For a device to work with the EVS system, it needs special software called kernel drivers. If a device already has drivers for its camera and display, those drivers can often be used for EVS too. This can be helpful, especially for display drivers, because showing images might need to work together with other things happening in the device.

In Android 8.0, there’s an example driver based on something called v4l2 (you can find it in packages/services/Car/evs/sampleDriver). This driver uses the kernel for v4l2 support (a way to handle video) and uses something called SurfaceFlinger to show images.

It’s important to note that the sample driver uses SurfaceFlinger, which isn’t suitable for a real device because EVS needs to start quickly, even before SurfaceFlinger is fully ready. However, the sample driver is designed to work with different hardware and lets developers test and work on EVS applications at the same time as they develop EVS drivers.

Typical control flow

The EVS application in Android is a C++ program that interacts with the EVS Manager and Vehicle HAL to offer basic rearview camera functionality. It’s meant to start early in the system boot process and can show appropriate video based on available cameras and the car’s state (gear, turn signal). Manufacturers can customize or replace this application with their own logic and visuals.

Since image data is provided in a standard graphics buffer, the application needs to move the image from the source buffer to the output buffer. This involves a data copy, but it also gives the app the flexibility to manipulate the image before displaying it.

For instance, the app could move pixel data while adding scaling or rotation. Alternatively, it could use the source image as an OpenGL texture and render a complex scene onto the output buffer, including virtual elements like icons, guidelines, and animations. More advanced applications might even combine multiple camera inputs into a single output frame for a top-down view of the vehicle surroundings.

Overall, the EVS application provides the essential connection between hardware and user presentation, allowing manufacturers to create custom and sophisticated visual experiences based on their specific vehicle designs and features.

Display Sharing — EVS Priority and Mechanism

The integration of exterior cameras in vehicles has transformed the way drivers navigate their surroundings. From parallel parking to navigating tight spaces, these cameras offer valuable assistance. However, the challenge arises when determining how to seamlessly switch between the main display, which often serves multiple functions, and the exterior view provided by EVS. The solution lies in prioritizing EVS for display sharing.

EVS Priority over Main Display

The EVS application is designed to have priority over the main display. This means that when certain conditions are met, EVS can take control of the main display to show its content. The main display is the screen usually used for various functions, like entertainment, navigation, and other infotainment features.

Grabbing the Display

Whenever there’s a need to display images from an exterior camera (such as the rearview camera), the EVS application can “grab” or take control of the main display. This allows the camera images to be shown prominently to the driver, providing important visual information about the vehicle’s surroundings.

Example Scenario — Reverse Gear

One specific scenario where this display-sharing mechanism is used is when the vehicle’s reverse gear is selected. When the driver shifts the transmission into reverse, the EVS application can immediately take control of the main display to show the live feed from the rearview camera. This is crucial for assisting the driver in safely maneuvering the vehicle while reversing.

No Simultaneous Content Display

Importantly, there is no mechanism in place to allow both the EVS application and the Android operating system to display content simultaneously on the main display. In other words, only one of them can be active and show content at any given time.

In short, the concept of display sharing in this context involves the Exterior View System (EVS) having priority over the main display in the vehicle. EVS can take control of the main display whenever there’s a need to show images from an exterior camera, such as the rearview camera. This mechanism ensures that the driver receives timely and relevant visual information for safe driving. Additionally, it’s important to note that only one of the applications (EVS or Android) can display content on the main screen at a time; they do not operate simultaneously.

Automotive Audio

In today’s contemporary world, cars have surpassed their basic role of transportation. They’re now a vital part of our lives, providing comfort, connectivity, and an experience that goes beyond the road. The audio system inside vehicles plays a major role in enhancing this experience. The domain of car audio is intricate and captivating, marked by its distinct challenges and innovations. In this piece, we’ll delve into automotive audio systems and the exceptional features that set them apart.

What is special about audio in vehicles?

Automotive Audio is a feature of Android Automotive OS that allows vehicles to play infotainment sounds, such as media, navigation, and communications. AAOS is not responsible for chimes and warnings that have strict availability and timing requirements, as these sounds are typically handled by the vehicle’s hardware.

Here are some of the things that are special about audio in vehicles:

Many audio channels with special behaviors

In a vehicle, there can be many different audio channels, each with its own unique purpose. For example, there may be a channel for music, a channel for navigation instructions, a channel for phone calls, and a channel for warning sounds. Each of these channels needs to behave in a specific way in order to be effective. For example, the music channel should not be interrupted by the navigation instructions, and the warning sounds should be audible over all other channels.

Critical chimes and warning sounds

In a vehicle, it is important to be able to hear critical chimes and warning sounds clearly, even over loud music or other noise. This is why these sounds are often played through a separate set of speakers, or through the speakers at a higher volume.

Interactions between audio channels

The audio channels in a vehicle can interact with each other in a variety of ways. For example, the music channel may be muted when the navigation instructions are spoken, or the warning sounds may override all other channels. These interactions need to be carefully designed in order to ensure that the audio system is safe and effective.

Lots of speakers

In order to provide good sound quality in a vehicle, there are often many speakers installed. This is because the sound waves need to be able to reach all parts of the vehicle, even if the driver and passengers are not sitting directly in front of the speakers.

In addition to these special features, audio in vehicles is also subject to a number of challenges, such as:

Noise

There is often a lot of noise in a vehicle, from the engine, the road, and the wind. This noise can make it difficult to hear the audio system, especially the critical chimes and warning sounds.

Vibration

The vehicle can vibrate, which can also make it difficult to hear the audio system.

Temperature

The temperature in a vehicle can vary greatly, from very hot to very cold. This can also affect the performance of the audio system.

Despite these challenges, audio in vehicles is an important safety feature and can also be a great way to enjoy music and entertainment while driving.

Automotive Sounds and Streams

The world of automotive sounds and streams is a testament to the intersection of technology, design, and human experience. The symphony of sounds within a vehicle, coupled with the seamless integration of streaming services, creates a holistic journey that engages our senses and transforms the act of driving into an unforgettable adventure

In car audio systems using Android, different sounds and streams are managed:

Logical Streams

Logical streams are the streams of audio data that are generated by Android apps. These streams are tagged with AudioAttributes, which provide details like where they come from, and information about the type of audio, such as its importance, latency requirements, and desired output devices.

Physical Streams

Physical streams are the streams of audio data that are output by the vehicle’s audio hardware. These are the actual sounds that come out of the speakers. These streams are not tagged with AudioAttributes, as they are not controlled by Android. They are made by mixing logical streams together. Some sounds, like important warnings, are managed separately from Android.

The main difference between logical streams and physical streams is that logical streams are controlled by Android, while physical streams are not. This means that Android can control the volume, routing, and focus of logical streams, but it cannot control the volume, routing, or focus of physical streams.

Android App Sounds

Apps make sounds, like music or navigation. These sounds are sent to a mixer and then to the speakers. The mixer combines different sounds and makes them into one.

External Sounds

External sounds are sounds that are generated by sources other than Android apps, such as seatbelt warning chimes. These sounds are managed outside of Android and are not subject to the same audio policies as Android sounds. Some sounds shouldn’t go through Android, so they go directly to the mixer. The mixer can ask Android to pause other sounds when these important sounds play.

External sounds are typically managed outside of Android because they have strict timing requirements or because they are safety-critical. For example, a seatbelt warning chime must be played immediately when the seatbelt is not buckled, and it must be audible over any other sounds that are playing. This is why external sounds are typically handled by the vehicle’s hardware, rather than by Android software.

Contexts

Contexts are used to identify the purpose of the audio data. This information is used by the system to determine how to present the audio, such as the volume level, the priority, and whether or not it should be interrupted by other sounds.

Buses

Buses are logical groups of physical streams that are routed to the same output device. This allows the system to mix multiple audio streams together before sending them to the speakers.

Audio Flinger

AudioFlinger is the system service that manages the audio output. It uses the context to mix logical streams down to physical streams called buses. This allows multiple logical streams to be mixed together, even if they are in different formats or have different priorities.

The IAudioControl::getBusForContext method maps from context to bus. This method is used by applications to get the bus that is associated with a particular context. This information can be used to route the audio output to the desired speakers.

For example, the NAVIGATION context could be routed to the driver’s side speakers. This would ensure that the navigation instructions are always audible, even if the music is playing.

The physical streams, contexts, and buses are an important part of the Android audio system. They allow the system to intelligently manage the audio output and ensure that the most important sounds are always audible.

Audio Context

Audio contexts are groups of audio usages that are used to simplify the configuration of audio in Android Automotive OS. Let’s first discuss audio usage

Audio Usage

In Android Automotive OS (AAOS), AudioAttributes.AttributeUsages are like labels for sounds. They help control where the sound goes, how loud it is, and who has control over it. Each sound or request for focus needs to have a specific usage defined. If no usage is set, it’s treated as a general media sound.

Android 11 introduced system usages, which are special labels that require specific permissions to use. These are:

1. USAGE_EMERGENCY
2. USAGE_SAFETY
3. USAGE_VEHICLE_STATUS
4. USAGE_ANNOUNCEMENT

To set a system usage, you use AudioAttributes.Builder#setSystemUsage. If you try to mix regular usage with system usage, it won’t work.

package com.softaai.automotive.audio

import android.media.AudioAttributes;

/**
 * Created by amoljp19 on 8/12/2023.
 * softAai Apps.
 */
public class AudioAttributesExample {

    public static void main(String[] args) {
        // Constructing AudioAttributes with system usage
        AudioAttributes.Builder attributesBuilder = new AudioAttributes.Builder()
                .setSystemUsage(AudioAttributes.USAGE_ALARM); // Set a system usage (alarm)

        // You can also set a general usage, but not both a system usage and a general usage
        // attributesBuilder.setUsage(AudioAttributes.USAGE_MEDIA); // Uncommenting this line would cause an error

        // Building the AudioAttributes instance
        AudioAttributes audioAttributes = attributesBuilder.build();

        // Checking the associated system usage or usage
        int systemUsage = audioAttributes.getSystemUsage();
        System.out.println("Associated System Usage: " + systemUsage);

    }
}

In this example:

1. We use AudioAttributes.Builder to create an instance of audio attributes.
2. We use setSystemUsage to specify a system context for the audio, in this case, an alarm usage.
3. Attempting to set both a system usage and a general usage using setUsage would result in an error, so that line is commented out.
4. We then build the AudioAttributes instance using attributesBuilder.build().
5. Finally, we use audioAttributes.getSystemUsage() to retrieve the associated system usage and print it.

Audio Context

Audio contexts are used in Android to identify the purpose of a sound. This information is used by the system to determine how to present the sound, such as the volume level, the priority, and whether or not it should be interrupted by other sounds.

The following are the audio contexts that are currently defined in Android:

1. MUSIC: This is for playing music in the vehicle, like your favorite songs.
2. NAVIGATION: These are the directions your vehicle’s navigation system gives you to help you find your way.
3. VOICE_COMMAND: When you talk to the vehicle, like telling it to change settings or do something for you.
4. CALL_RING: When someone is calling you, this is the ringing sound you hear.
5. CALL: This is for when you’re having a conversation with someone on the phone while in the vehicle.
6. ALARM: A loud sound that might go off if something needs your immediate attention.
7. NOTIFICATION: These are little messages or reminders from the vehicle’s systems.
8. SYSTEM_SOUND: The sounds you hear when you press buttons or interact with the vehicle’s controls.

The following table summarizes the mapping between audio contexts and usages in Android Automotive OS:

The audio context for a sound can be specified by the application that is playing the sound. This is done by setting the context property of the AudioAttributes object that is used to create the sound.

The system uses the audio context to determine how to present the sound. For example, the volume level of a sound may be higher for the MUSIC context than for the NOTIFICATION context. The system may also choose to interrupt a sound of a lower priority with a sound of a higher priority.

Audio contexts are an important part of the Android audio system. They allow the system to intelligently manage the audio output and ensure that the most important sounds are always audible.

Chimes and warnings

Chimes and warnings within vehicles serve as auditory cues that communicate vital information to the driver and occupants. From seatbelt reminders to collision warnings, these sounds are designed to promptly draw attention to situations that require immediate action. These auditory cues enhance situational awareness and contribute to the overall safety of the driving experience.

Android’s Role in Automotive Audio

While Android has become a ubiquitous operating system for various devices, it presents certain considerations when it comes to automotive safety. Android, in its standard form, is not classified as a safety-critical operating system. Unlike dedicated safety-critical systems found in vehicles, Android’s primary focus is on delivering a versatile and user-friendly platform.

The Absence of an Early Audio Path

In the context of chimes and warnings, Android lacks an early audio path that is essential for producing regulatory and safety-related sounds. An early audio path would involve direct access to the audio hardware, ensuring that these crucial sounds are played promptly and without interruption. Android, being a multifunctional operating system, may not possess the mechanisms required for such instantaneous audio playback.

Regulatory Sounds Beyond Android

Given the critical nature of regulatory chimes and warnings, generating and delivering these sounds falls outside the Android operating system. To ensure that these sounds are reliable and timely, they are often generated and mixed independently from Android, later integrating into the vehicle’s overall audio output chain. This approach guarantees that regulatory sounds maintain their integrity, even in scenarios where Android might face limitations due to its primary focus on versatility.

Safety-Critical Considerations

The absence of an early audio path within Android highlights a broader concern related to the safety-critical nature of automotive audio. As vehicles continue to integrate advanced technologies, including infotainment systems and connectivity features, the challenge lies in finding the balance between innovation and safety. Regulatory bodies and automotive manufacturers collaborate to ensure that safety-critical elements, such as chimes and warnings, are given the utmost attention and reliability.

The Road Ahead: Safety and Technology Integration

The integration of technology, including operating systems like Android, into vehicles is a testament to the dynamic evolution of the automotive landscape. As the industry continues to innovate, addressing safety concerns remains paramount. The future promises advancements that bridge the gap between safety-critical needs and technological capabilities. This may involve further synchronization between Android and the vehicle’s safety systems, ensuring that critical alerts and warnings are delivered seamlessly and without compromise.

In short, the realm of chimes and warnings in automotive audio underscores the delicate balance between safety and technology. While Android contributes significantly to the modern driving experience, there are specific safety-critical aspects, such as regulatory sounds, that demand specialized attention. The collaborative efforts of regulatory bodies, automotive manufacturers, and technology providers will continue to shape a safer and more immersive driving journey for all.

Conclusion

Android Automotive represents a tailored adaptation of the Android operating system for automobiles. This evolution brings about the implementation of key components such as the Vehicle Hardware Abstraction Layer (VHAL), Car Service, and Car Manager. These additions contribute to a more integrated and seamless experience for both drivers and passengers.

Furthermore, Android Automotive extends its capabilities by accommodating external cameras, providing enhanced visibility and safety features. This inclusion aligns with the contemporary emphasis on comprehensive vehicle awareness.

Within the realm of audio, Android Automotive introduces notable advancements. The concept of audio zones or buses offers a nuanced approach to audio management, permitting various audio sources to be directed to specific areas within the vehicle. Additionally, context-based routing enhances the overall auditory experience by adapting audio output to suit the immediate surroundings and conditions.

As the automotive landscape continues to evolve, Android Automotive emerges as a platform that not only transforms the in-car experience but also sets a precedent for the convergence of technology and mobility. The introduction of these features underscores Android’s commitment to redefining the future of driving, focusing on comfort, safety, and innovation.