In the ever-evolving landscape of technology, where innovation and adaptability are paramount, Android has emerged as a dominant force. Beyond smartphones, Android’s influence has extended into various industries, including the automotive sector. A pivotal development in this journey has been the introduction of Project Treble and its subsequent integration into Android Automotive OS, ushering in a new era of modular advancements. This article delves into the essence of Project Treble and how its modular approach has transformed Android’s foray into the automotive realm.

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.

Conclusion

Project Treble’s modular approach and Android Automotive OS’s tailored architecture have revolutionized Android’s adaptability for both devices and vehicles. By separating hardware-specific components, manufacturers can efficiently update their systems. The integration of specialized APIs and services in Android Automotive OS streamlines infotainment, while Project Treble’s HAL enhancements and modularity ensure seamless hardware communication. These advancements collectively promise a future-proof, user-friendly experience for both drivers and passengers.