Automotive & IVI

If you’re getting started with Android Automotive OS (AAOS), you’ll quickly run into something called Car Service in AOSP. It’s one of those essential components that makes Android work inside a car — not on your phone, but actually on the car’s infotainment system.

In this guide, we’ll break down Car Service in AOSP step-by-step, explain how it works, what it does, and walk through code examples so you can understand and start building with confidence.

What Is Car Service in AOSP?

In the world of Android Open Source Project (AOSP), Car Service is a system service designed specifically for the automotive version of Android. It’s what bridges the gap between car hardware (like sensors, HVAC, speed, fuel level) and Android apps or services that need that data.

Think of it as the middleman that manages and exposes car hardware features to Android applications safely and consistently.

Why Is Car Service Important in Android Automotive?

• Access to Vehicle Data: It lets apps access data like speed, gear, HVAC status, fuel level, etc.
• Security: Only authorized components can access sensitive vehicle data.
• Abstraction: It hides the car’s hardware complexity behind clean Android APIs.
• Interoperability: Developers can build apps that work across different car manufacturers.

Core Components of Car Service in AOSP

Let’s simplify the architecture. Here’s how the system flows:

Car Hardware Abstraction Layer (HAL)
          ↓
      Car Service (System)
          ↓
  Car APIs / CarApp Library
          ↓
   Third-party or System Apps

1. Car HAL (Hardware Abstraction Layer)

This is the lowest layer. It connects directly to the car’s ECU and other hardware via vendor-specific code.

2. Car Service

This lives in packages/services/Car in AOSP. It reads from the HAL and exposes data to the rest of Android using APIs.

3. Car APIs

Available via android.car namespace. Developers use these in their apps to access vehicle data in a clean, safe way.

Where Is Car Service Code in AOSP?

You’ll find the Car Service source code here:

/packages/services/Car/

Key files:

• CarService.java – The main system service.
• CarPropertyService.java – Handles access to vehicle properties.
• VehicleHal.java – Bridges to the HAL.
• VehicleStubHal.java – A fake HAL used for emulators and testing.

Let’s Look at Code: How Car Service Works

Here’s a super simplified example from CarService.java:

public class CarService extends Service {
    @Override
    public void onCreate() {
        super.onCreate();
        Log.i(TAG, "CarService started");

        // Initialize vehicle property manager
        mCarPropertyService = new CarPropertyService();
        mCarPropertyService.init();

        // Register the service to ServiceManager
        ServiceManager.addService("car_service", this);
    }
}

Here,

• The system starts CarService during boot.
• It initializes CarPropertyService which talks to the HAL.
• It registers itself to ServiceManager so apps can bind to it.

This is what makes vehicle data accessible through Android’s Car APIs.

Permissions and Security

Accessing vehicle data isn’t open to everyone — and that’s a good thing.

You’ll need permissions like:

<uses-permission android:name="android.car.permission.CAR_SPEED"/>
<uses-permission android:name="android.car.permission.CAR_ENGINE"/>

And apps must be system-signed or granted via whitelist in car_service.xml.

Accessing Vehicle Data from an App

Here’s how a developer might access the vehicle speed:

Car car = Car.createCar(context);
CarPropertyManager propertyManager = (CarPropertyManager) car.getCarManager(Car.PROPERTY_SERVICE);

float speed = (Float) propertyManager.getProperty(
    VehiclePropertyIds.PERF_VEHICLE_SPEED, 0);

Here,

• Connect to the Car service.
• Get the CarPropertyManager.
• Read the vehicle speed using a property ID.

Testing Car Service Without a Real Car

Don’t have an actual car ECU to test with? Use the VehicleStubHal!

In VehicleStubHal.java, you can simulate data:

@Override
public void getProperty(...) {
    if (propertyId == VehiclePropertyIds.PERF_VEHICLE_SPEED) {
        return new VehiclePropValue(..., 42.0f); // Fake speed
    }
}

Perfect for development and debugging on emulators.

Customizing Car Service for Your OEM

If you’re building a custom ROM for a car, you’ll likely need to:

1. Implement your own Car HAL in hardware/interfaces/automotive/vehicle.
2. Customize Car Service components in /packages/services/Car/.
3. Define new vehicle properties if needed.

Make sure you align with VHAL (Vehicle HAL) AIDL interface definitions.

Summary: Key Takeaways

• Car Service in AOSP is the system layer that gives Android Automotive access to vehicle hardware.
• It abstracts complex car hardware into simple APIs.
• Apps use the android.car APIs to safely read and respond to vehicle state.
• Testing is possible with stub HALs — no real car needed!
• It’s secure, modular, and extensible.

Android Automotive OS is powering a growing number of infotainment systems, and at the heart of its vehicle interaction lies a critical component: VHAL Interfaces (IVehicle). These interfaces are what allow Android to talk to your car’s hardware. From reading the speedometer to turning on climate control, everything hinges on this system.

In this post, we’ll break down how VHAL Interfaces (IVehicle) work, why they’re essential, and how developers can work with them to build automotive apps that actually connect with vehicle systems.

What Is VHAL?

VHAL stands for Vehicle Hardware Abstraction Layer. Think of it as a translator between Android and the car’s underlying ECUs (Electronic Control Units). Cars have multiple ECUs controlling everything from brakes to lights, and Android Automotive needs a way to communicate with them.

That’s where VHAL Interfaces (IVehicle) come in. They define how Android gets and sets data to and from the vehicle hardware.

The Role of IVehicle Interface

In Android Automotive, IVehicle is the AIDL (Android Interface Definition Language) interface that enables communication between the Vehicle HAL and the framework.

You can think of IVehicle as a contract. It defines methods the Android system can call to:

• Get vehicle property values (e.g., speed, fuel level)
• Set values (e.g., adjust HVAC settings)
• Subscribe to updates

This interface must be implemented by car manufacturers or Tier-1 suppliers so that Android can access real-time vehicle data.

Anatomy of IVehicle Interface

Here’s a simplified look at what an IVehicle interface might look like:

interface IVehicle {
    VehiclePropValue get(in VehiclePropGetRequest request);
    StatusCode set(in VehiclePropValue value);
    void subscribe(in IVehicleCallback callback, in SubscribeOptions[] options);
    void unsubscribe(in IVehicleCallback callback, in int[] propIds);
}

Here,

• get(): Used to read a vehicle property.
• set(): Used to write or modify a property (like setting temperature).
• subscribe(): Listen for changes (like speed updates).
• unsubscribe(): Stop listening to property changes.

These methods form the foundation of vehicle interaction in Android Automotive.

What Is a Vehicle Property?

A vehicle property is any data point Android can interact with. Each has a unique ID, data type, and permission level. For example:

• VehicleProperty::PERF_VEHICLE_SPEED: Car speed
• VehicleProperty::HVAC_TEMPERATURE_SET: Climate control temperature
• VehicleProperty::FUEL_LEVEL: Fuel level

Each property is defined in the VehicleProperty.aidl file.

Implementing a Custom VHAL

Let’s say you’re a car maker. You want Android to read your custom battery voltage data. You’d do something like this:

1. Define the Property

#define VEHICLE_PROPERTY_CUSTOM_BATTERY_VOLTAGE (0x12345678)

2. Add It to Your Property List

VehiclePropConfig config = {
    .prop = VEHICLE_PROPERTY_CUSTOM_BATTERY_VOLTAGE,
    .access = VehiclePropertyAccess::READ,
    .changeMode = VehiclePropertyChangeMode::ON_CHANGE,
    .configArray = {},
    .configString = "Custom Battery Voltage",
};

3. Implement Logic in get()

VehiclePropValue get(const VehiclePropGetRequest& request) override {
    VehiclePropValue value = {};
    if (request.prop == VEHICLE_PROPERTY_CUSTOM_BATTERY_VOLTAGE) {
        value.prop = request.prop;
        value.value.floatValues = {12.6};
    }
    return value;
}

And that’s it. Now Android can read your custom battery voltage.

Why Are VHAL Interfaces (IVehicle) Important?

Without VHAL, Android is blind to the vehicle. These interfaces power key services like:

• HVAC control UI
• Instrument cluster apps
• Battery status for EVs
• Safety features

By standardizing communication, VHAL Interfaces (IVehicle) make it possible for third-party developers to build real, vehicle-aware apps. That’s a game-changer.

Example: Reading Vehicle Speed

Let’s look at a code snippet that reads the vehicle speed.

Requesting Speed in Framework (Java)

VehiclePropertyValue speed = vehicle.get(VehicleProperty.PERF_VEHICLE_SPEED);
float currentSpeed = speed.getValue().getFloatValue();

Here,

• The Java API calls the get() method on the IVehicle AIDL interface.
• This request travels through the HAL to the car’s CAN bus or hardware.
• The current speed is returned as a float.

Best Practices for Working with VHAL

1. Don’t poll: Use subscribe() instead of calling get() in a loop.
2. Permission-aware: Some properties require special permissions.
3. Optimize data flow: Avoid flooding the system with updates.
4. Test on real hardware: Simulators are helpful, but actual ECUs may behave differently.

Conclusion

If you want to build or integrate automotive systems with Android Automotive OS, you must understand how VHAL Interfaces (IVehicle) work. They’re the core pathway between Android and the car’s brain.

With the right implementation, you can create apps that do more than just run in the dashboard — they interact with the vehicle in real-time, improving safety, convenience, and experience.

VHAL Interfaces (IVehicle) are not just another Android abstraction. They’re what make Android truly automotive.

In today’s rapidly evolving automotive world, technology increasingly powers every aspect of your driving experience. One such advancement making a significant impact behind the scenes is Vehicle HAL. You might be wondering, what exactly is Vehicle HAL, and how does it affect the way you drive? Let’s break it down clearly and simply.

What Is Vehicle HAL? 

Vehicle HAL stands for Vehicle Hardware Abstraction Layer. Think of it as the translator between the car’s hardware (like sensors, cameras, control units) and the software apps that make your driving experience smarter and safer. It sits in the middle, handling the nitty‑gritty so app developers can focus on features — not on hardware quirks.

With Vehicle HAL, your car’s systems talk in a standard language. Whether it’s braking, lane‑keeping, infotainment, or diagnostics, everything works through that common interface. That consistency simplifies development, improves safety, and speeds up innovation.

Why Vehicle HAL Matters

1. One Interface, Many Devices

Vehicle HAL gives developers a single, reliable interface to access diverse hardware. Instead of building custom code for each sensor or device, they write once and it works across models — much faster and safer.

2. Faster Updates, Smarter Features

Need to add voice commands, predictive cruise control, or advanced diagnostics? Vehicle HAL decouples hardware from apps. That means updates come quicker and you get new features without long delays.

3. Safety First

By enforcing consistent behavior across hardware components, Vehicle HAL helps reduce bugs and improves reliability. Consistency boosts safety — especially in critical systems like braking or collision avoidance.

4. Interoperability & Modularity

Automakers and suppliers can plug in different parts — cameras, sensors, processors — from various vendors. As long as they follow Vehicle HAL standards, everything integrates seamlessly. This encourages competition and innovation while keeping quality high.

How Vehicle HAL Works

Let’s look at a basic example in Android’s Vehicle HAL environment to understand how it controls a vehicle’s power state.

// Example: Controlling Vehicle Power State with Vehicle HAL

public class VehiclePowerController {
    private VehicleHal vehicleHal;

    public VehiclePowerController(VehicleHal hal) {
        this.vehicleHal = hal;
    }

    // Method to turn vehicle power on or off
    public void setPowerState(boolean on) {
        try {
            int powerState = on ? VehiclePropertyIds.POWER_STATE_ON : VehiclePropertyIds.POWER_STATE_OFF;
            vehicleHal.setProperty(VehiclePropertyIds.POWER_STATE, powerState);
            System.out.println("Vehicle power turned " + (on ? "ON" : "OFF"));
        } catch (VehicleHalException e) {
            System.err.println("Failed to set power state: " + e.getMessage());
        }
    }
}

Here,

• VehicleHal is an object representing the hardware abstraction layer interface.
• The method setPowerState takes a boolean to turn the vehicle power on or off.
• VehiclePropertyIds.POWER_STATE_ON and POWER_STATE_OFF are constants representing the hardware power states.
• The setProperty method sends the command down to the hardware, abstracted away from the specific implementation.

This simple code showcases how Vehicle HAL hides the hardware complexities and presents a clean way to control vehicle functions programmatically.

Benefits of Vehicle HAL for Developers and Drivers

• For developers: Simplifies app development and testing across multiple vehicle platforms.
• For drivers: You get a smooth, consistent driving experience with new features delivered faster and more safely.
• For manufacturers: Promotes modular design, reducing costs and accelerating innovation.

The Future of Driving with Vehicle HAL

As connected and autonomous vehicles advance, the role of Vehicle HAL will grow even more crucial. It will support complex sensor networks, cloud integration, AI-driven decisions, and real-time data sharing between vehicles to make driving smarter, safer, and more enjoyable.

Conclusion

In conclusion, Vehicle HAL is revolutionizing the automotive space by breaking down the barriers between hardware and software. It’s making cars more adaptable, feature-rich, and user-friendly, changing the way you interact with your vehicle every day. Whether it’s through better safety, easier updates, or improved performance, Vehicle HAL is quietly refashioning the future of driving, one line of code at a time.

Drive smarter, safer, and connected — thanks to Vehicle HAL.

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

Let’s dive into its main layers.

Android Automotive Architecture

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

It consists of the following four main generic components:

Application Framework

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

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

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

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

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

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

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

BTW, What is OEM?

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

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

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

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

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

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

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

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

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

Android Automotive System Services

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

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

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

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

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

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

Overview of the different Car Managers along with their respective descriptions

Hardware Abstraction Layer (HAL)

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

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

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

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

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

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

Board Support Package (BSP)

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

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

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

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

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

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

AIDL & HIDL

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

AIDL (Android Interface Definition Language):

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

HIDL (HAL Interface Definition Language):

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

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

Conclusion 

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

If you’re an OEM or Tier 1 developer integrating Google Automotive Services (GAS) into your Android Automotive OS (AAOS) stack, compliance isn’t just a formality — it’s a binding agreement with Google. Their guidelines are intentionally strict to preserve platform security, ensure a consistent user experience, and maintain API reliability across the ecosystem.

This article takes a deep dive into what GAS compliance actually entails — offering actionable insights for engineers, system architects, and product owners navigating the AAOS landscape.

Quick Primer: What Is GAS?

Google Automotive Services (GAS) is a proprietary suite of applications running on Android Automotive OS (AAOS). It includes:

• com.google.android.apps.maps (Google Maps)
• com.google.android.googlequicksearchbox (Google Assistant)
• com.android.vending (Play Store)
• com.google.android.gms (Play Services)

Unlike Android Auto, which mirrors from a paired phone, GAS apps run natively on the IVI (In-Vehicle Infotainment) hardware. That requires full-stack integration — kernel to UI.

Licensing GAS (OEM Legal Requirement)

Before any technical work begins, your OEM must sign a GAS License Agreement with Google. This is model-specific, meaning:

• Each vehicle/trim with a different infotainment configuration = separate GAS approval
• Google reserves the right to audit or revoke if compliance slips

As a developer, you’ll typically get access to the GAS Partner Portal after your OEM is approved — where SDKs, sample projects, and certification tools are hosted.

Hardware & OS Prerequisites

To be GAS-compliant, your hardware must meet strict thresholds.

Minimum Hardware Spec

Android Automotive OS

To integrate Google Automotive Services, your IVI system must use a Google-certified build of Android Automotive OS. This typically involves:

• A certified AOSP base, often from a recent LTS (Long-Term Support) branch
• HALs and BSPs tailored for IVI use cases, compliant with VHAL (Vehicle HAL) standards
• A custom UI that respects Google Automotive Services guidelines for system behavior, Assistant integration, and safe navigation

Note: Google prohibits UI customizations that interfere with system-level navigation, Assistant triggers, or driving safety workflows. GAS will not support heavily skinned or fragmented UI shells that break these requirements.

The Test Suites — All Mandatory

Google requires your system to pass a set of test suites to ensure stability and UX consistency.

Compatibility Test Suite (CTS)

Tests Android APIs, permissions, and behavior.

$ run_cts --module CtsAppSecurityHostTestCases
$ run_cts --module CtsMediaTestCases

Failures often involve:

• Custom permission models
• Background activity restrictions
• Missing system apps

Vendor Test Suite (VTS)

Validates hardware interface layers. You’ll need to flash your build and execute these over adb/fastboot.

$ run_vts --plan VtsKernelTest

Typical failures:

• Bad binder transaction handling
• Incomplete HIDL implementation

Automotive Test Suite (ATS)

Tests GAS apps in the context of AAOS.

Key checks include:

• Intent resolution from Assistant (ACTION_NAVIGATE_TO)
• Overlay permission use
• Play Store update flow

Drivable Test Suite (DTS)

DTS evaluates runtime behavior during actual vehicle use. Google may perform this directly or via OEM-conducted telemetry logs.

Integration Tips for GAS Developers

1. Use CarApp API for Custom Apps

If you’re building companion apps, use the androidx.car.app APIs (Jetpack):

class MyCarScreen(carContext: CarContext) : Screen(carContext) {
    override fun onGetTemplate(): Template {
        return MessageTemplate.Builder("Welcome to MyCar App")
            .setTitle("MyCar")
            .setHeaderAction(Action.APP_ICON)
            .build()
    }
}

2. Use MediaBrowserServiceCompat for Media Apps

GAS expects media apps to use Android’s MediaBrowserServiceCompat so that Assistant can control them

class MyMediaService : MediaBrowserServiceCompat() {
    override fun onCreate() {
        super.onCreate()
        // Setup your media session and player
    }
    
    override fun onLoadChildren(parentId: String, result: Result<List<MediaItem>>) {
        // Populate UI content
    }
}

3. Assistant Support = Deep Linking Required

Make sure you support Google Assistant voice intents. This requires implementing App Actions schema or handling common Intents.

<intent-filter>
    <action android:name="android.media.action.MEDIA_PLAY_FROM_SEARCH" />
</intent-filter>

Handle queries like “Play Arijit Singh songs on MyCar App”.

Privacy & Data Handling for GAS Compliance

As a developer, your GAS integration must comply with Google and regional privacy rules.

You must:

• Avoid tracking without user consent
• Route sensitive data via Android Keystore or SafetyNet
• Support user-level account deletion (GDPR/CCPA)
• Never misuse the Location or Microphone data exposed via GAS APIs

Pro Tips for Dev Teams

• Use Emulator Images from AOSP: GAS builds aren’t public, but you can prototype using AAOS emulator images from Google’s android-automotive GitHub.
• Leverage VHAL correctly: Don’t shortcut vehicle HAL integrations — Google’s certification expects clean VehicleProp handling.
• Automate testing with TradeFed: You’ll be running these tests often. Use TradeFederation to orchestrate builds and reports.

Conclusion: Build for Compliance, Not Just Launch

GAS compliance is a high bar. But it’s not just bureaucracy — it’s about delivering a polished, secure, responsive infotainment system users can trust.

As a developer, your role is to make sure the AAOS stack:

• Runs clean, certified builds
• Passes all test suites
• Delivers a user experience aligned with Google’s best practices
• Handles data securely and transparently

Once certified, your GAS integration unlocks the full power of Google’s ecosystem — and keeps your vehicles competitive in a connected world.

Android has come a long way since powering our phones. Today, it’s in dashboards, infotainment systems, and even under the hood of cars. But how exactly did Android evolve from a smartphone OS to a critical player in the automotive world?

In this blog post, we’ll explore the fascinating journey of Android in the automotive industry, from its humble beginnings to the modern Android Automotive OS (AAOS). We’ll explain everything in a clear and easy-to-understand way, covering code examples, system architecture, and how this evolution affects developers, car manufacturers, and everyday drivers.

From Mobile OS to Infotainment: The Early Days

When Android was first introduced by Google in 2008, its open-source nature caught the attention of many industries — including automotive.

The Introduction of Android Auto

In 2015, Google officially launched Android Auto — a platform that allowed Android smartphones to project a simplified interface onto the car’s infotainment system. Drivers could use apps like Google Maps, Spotify, and WhatsApp with voice commands and touch input, enhancing safety and usability.

How It Works:
 Android Auto runs on the phone, not the car. The car merely acts as a display and controller.

// Example: Launching a voice command with Google Assistant
val intent = Intent(Intent.ACTION_VOICE_COMMAND)
startActivity(intent)

This architecture meant quick updates and a wide range of compatible vehicles. But it also had limitations — OEMs (Original Equipment Manufacturers) had little control over the UI or deep integration with car hardware.

The Rise of Android Automotive OS (AAOS)

Recognizing the limitations of projection-based systems, Google introduced Android Automotive OS — a full-fledged, car-ready version of Android that runs natively on the vehicle’s hardware.

What Makes Android Automotive OS Special?

• Embedded OS: No need for a phone. The OS is pre-installed and controls the infotainment system.
• Deeper Hardware Access: Unlike Android Auto, AAOS can integrate with HVAC, seat controls, vehicle telemetry, and more.
• Customizable UI: OEMs can customize the look and feel while still leveraging the power of Android.

Architecture of Android Automotive OS

Let’s break down how Android Automotive OS works under the hood.

1. HAL (Hardware Abstraction Layer)

This layer interacts directly with the vehicle’s hardware. OEMs implement Vehicle HALs to expose data like speed, fuel level, and climate control to Android.

2. Vehicle HAL Interface (AIDL-based)

Android Automotive uses AIDL (Android Interface Definition Language) to define communication between system services and vehicle HALs.

// AIDL example to access vehicle property
interface IVehicle {
    int getProperty(int propertyId);
}

3. Car Services Layer

These are system services provided by AAOS (like CarSensorManager, CarInfoManager, etc.) that expose car-related data to apps.

val car = Car.createCar(context)
val sensorManager = car.getCarManager(Car.SENSOR_SERVICE) as CarSensorManager

Developer Experience: Building Apps for Android in Cars

With AAOS, developers now build apps that run directly on the car. These can be media, navigation, or communication apps.

App Categories Supported:

• Media (e.g., Spotify)
• Messaging (e.g., WhatsApp)
• Navigation (e.g., Google Maps alternatives)

Sample Media App Setup

Android Automotive media apps are built on the MediaBrowserService framework:

class CarMediaService : MediaBrowserServiceCompat() {
    override fun onGetRoot(
        clientPackageName: String,
        clientUid: Int,
        rootHints: Bundle?
    ): BrowserRoot? {
        return BrowserRoot("root", null)
    }

    override fun onLoadChildren(
        parentId: String,
        result: Result<List<MediaItem>>
    ) {
        result.sendResult(emptyList()) // Placeholder
    }
}

This setup allows your media app to appear natively within the car’s infotainment system.

OEM Adoption and Industry Impact

More manufacturers are embracing Android in the automotive industry due to its flexibility and Google ecosystem support.

Popular Cars Running AAOS:

• Volvo XC40 Recharge
• Polestar 2
• Renault Mégane E-Tech
• GM, Honda, Ford, and Stellantis also announced future integration

OEMs can add their own app stores, integrate voice assistants like Alexa, and modify the interface, all while running on a solid Android foundation.

Privacy, Security & Updates

One of the major concerns with embedded software in cars is security. Google addresses this with:

• Verified boot & partitioned OS layers
• Google Play Protect (on supported systems)
• Monthly security patches (when implemented by OEMs)
• OTA (Over-the-Air) updates to push bug fixes and new features

What’s in It for You, the Driver?

Faster Access

No waiting for your phone to connect. No dropped Bluetooth. Everything just works.

Built-In Voice Control

“Hey Google, take me to the nearest gas station.” Simple, natural, and hands-free.

Fewer Distractions

Designed with safety in mind, the interface limits visual overload. You only see what you need, when you need it.

Better Personalization

Since AAOS runs directly in the car, it can save preferences across profiles and adapt to whoever’s behind the wheel.

The Future of Android in the Automotive Industry

We’re only scratching the surface of what Android can do for mobility.

Upcoming Trends:

• Integration with EV battery data
• Smart assistant for predictive driving
• Multi-screen support (rear-seat entertainment)
• Seamless phone-to-car sync with Android 15+

Google is also working on extending AI-powered user experiences using contextual data like location, calendar events, and habits to provide real-time driving recommendations and proactive assistance.

Conclusion

The journey of Android in the automotive industry showcases how adaptable and scalable the Android ecosystem truly is. From phone projection systems to embedded car platforms, it has revolutionized how drivers interact with their vehicles.

For developers, this is a golden era — you can now build apps not just for phones and tablets, but for the road itself. For OEMs, it’s an opportunity to build smarter, more connected vehicles. And for users, it means safer, more personalized, and enjoyable driving experiences.

As Android continues its journey on wheels, the road ahead looks smarter, safer, and more open than ever.

FAQ

Q: What is Android Automotive OS?
 A: Android Automotive OS (AAOS) is an operating system developed by Google that runs directly on a vehicle’s hardware, unlike Android Auto which runs on a smartphone.

Q: How is Android Auto different from Android Automotive OS?
 A: Android Auto is a projection system that mirrors apps from your phone. AAOS is a standalone OS installed in the car, offering deeper integration with vehicle functions.

Q: Can I build apps for Android Automotive?
 A: Yes! You can build navigation, media, and communication apps using standard Android tools and frameworks, with slight modifications for car compliance.

Q: Which cars use Android Automotive OS?
 A: Cars like the Polestar 2, Volvo XC40, and some models by GM, Honda, and Renault run Android Automotive OS.

Glanceable UI is a key pillar of in-car user experiences, especially in vehicles powered by Android Automotive OS (AAOS). With safety at the core, designing for “at-a-glance” interaction ensures drivers get the information they need with minimal distraction.

In this blog post, we’ll explore:

• What Jetpack Glance is
• How it helps build Glanceable UIs for AAOS
• A practical example: Media playback glance widget
• Best practices for in-car glance design

What Is Jetpack Glance?

Jetpack Glance is a lightweight UI toolkit by Google that allows developers to build glanceable app widgets using Jetpack Compose principles.

While it’s widely used for Android home screen widgets, it also plays a growing role in automotive contexts, where modular, safe, and context-aware UI components are essential.

Key Benefits:

• Declarative UI (Compose-style)
• Lightweight and fast
• Surface-aware (homescreen, dashboard, etc.)
• Seamlessly integrates with AAOS and Assistant

Why Glanceable UI Matters in Cars

An ideal in-car interface (for media, navigation, etc.) should be so intuitive, voice-driven, glanceable, and minimal that drivers can use it with little or no visual attention — keeping their eyes on the road and hands on the wheel.

Android Automotive is designed to operate under strict UX restrictions to reduce cognitive load and visual complexity while driving. Glanceable UI is about showing just enough information for a quick decision or action.

Example Use Cases:

• Resume last media playback
• Quick access to a recent contact
• Show estimated time to destination
• Weather or fuel level notifications

Setup: Adding Jetpack Glance to Your AAOS Project

First, make sure to add the required dependencies:

dependencies {
    implementation("androidx.glance:glance:1.1.1")
    implementation("androidx.glance:glance-appwidget:1.1.1")
}

Jetpack Glance is evolving, so make sure to check the latest versions here.

Example: Glanceable Media Playback Widget

Let’s say you want to display a media card with the currently playing song, a thumbnail, and basic controls like play/pause.

Step 1: Create Your Glance Widget

class MediaPlaybackWidget : GlanceAppWidget() {
    override suspend fun provideGlance(context: Context, id: GlanceId) {
        provideContent {
            MediaPlaybackContent()
        }
    }
}

Step 2: Build the UI Using Glance

@Composable
fun MediaPlaybackContent() {
    val mediaState = rememberMediaState()

    Column(
        modifier = GlanceModifier
            .fillMaxWidth()
            .padding(16.dp)
            .background(ImageProvider(R.drawable.widget_bg))
    ) {
        Text(
            text = mediaState.title,
            style = TextStyle(fontSize = 18.sp, fontWeight = FontWeight.Bold),
            maxLines = 1
        )
        Text(
            text = mediaState.artist,
            style = TextStyle(fontSize = 14.sp, color = Color.Gray),
            maxLines = 1
        )

        Row(
            horizontalAlignment = Alignment.CenterHorizontally,
            modifier = GlanceModifier.fillMaxWidth()
        ) {
            Image(
                provider = ImageProvider(R.drawable.ic_prev),
                contentDescription = "Previous",
                modifier = GlanceModifier.clickable { /* skipPrevious() */ }
            )
            Spacer(modifier = GlanceModifier.width(8.dp))
            Image(
                provider = if (mediaState.isPlaying)
                    ImageProvider(R.drawable.ic_pause)
                else
                    ImageProvider(R.drawable.ic_play),
                contentDescription = "Play/Pause",
                modifier = GlanceModifier.clickable { togglePlayback() }
            )
            Spacer(modifier = GlanceModifier.width(8.dp))
            Image(
                provider = ImageProvider(R.drawable.ic_next),
                contentDescription = "Next",
                modifier = GlanceModifier.clickable { /* skipNext() */ }
            )
        }
    }
}

Pro Tips for Designing Glanceable UI in AAOS

UX Restrictions You Must Follow

Google enforces strict glanceable design rules for AAOS:

• No scrolling UI
• No long lists
• No non-essential buttons
• Only relevant, context-sensitive info
• Safety is non-negotiable: Design for drivers, not passengers

If your app violates these, it may be rejected or hidden when driving.

Conclusion

Jetpack Glance enables a new era of modular, composable, and glance-friendly UI for Android Automotive OS. By respecting the driving context and focusing on essential, actionable information, developers can create interfaces that enhance the in-car experience—without compromising safety.

Remember: In the car, less is more. Show less, do more.