Android Automotive OS · VHAL · GAS
Android Auto and Android Automotive OS share a name and nothing else. The first projects your phone onto a screen in the car. The second is the car's operating system.
Skip that distinction and every document you read afterwards will quietly stop making sense. So let's follow one thing — a vehicle signal — all the way up to the app.
More people conflate these than you would expect.
| Android Auto | Android Automotive OS (AAOS) | |
|---|---|---|
| Runs on | Your phone | The car's head unit |
| Needs a phone? | Yes — plug in and project | No |
| Vehicle data? | Practically none | Yes — HVAC, gear, EV range … |
| App store | Play on the phone | Play in the car (GAS vehicles) |
| Who builds it | App developers | OEMs / Tier 1s / app developers |
AAOS is a platform, built on AOSP. An OEM ships it in a car and builds its own system apps on top. That is why "writing an Android app" and "building a car that runs Android" end up described with the same words.
The boundaries in this diagram tend to be organisational boundaries too.
The AAOS stack. The two blue-outlined layers are the automotive-specific ones
In a published account of Honda's AAOS work on TECH PLAY, the split is described exactly this way: the OEM takes the layers above the HAL, while the hardware domain stays with the Tier 1. On the audio side, the article describes AudioFlinger at the centre with CarAudioManager added alongside it, plus the existing AudioFocus mechanism and the native AAudio path.
This is the part that makes car Android car Android.
Apps never read CAN frames. The VHAL converts vehicle signals into "Vehicle Properties", a uniform shape, and apps read and write those. That is what keeps differences between models and buses from leaking into app code.
The entry point is the Car class; you pull the managers out of it.
// Get CarPropertyManager from a Car instance
Car car = Car.createCar(context);
CarPropertyManager mgr =
(CarPropertyManager) car.getCarManager(Car.PROPERTY_SERVICE);
// One-shot read — the model name, for example
String model = mgr.getProperty(
String.class, VehiclePropertyIds.INFO_MODEL, 0).getValue();
// Subscribe to changes — the current gear, for example
mgr.registerCallback(callback,
VehiclePropertyIds.CURRENT_GEAR,
CarPropertyManager.SENSOR_RATE_ONCHANGE);Terms worth knowing
android.car — the package that is the entry point to car servicesCarPropertyManager — read and modify vehicle properties: speed, fuel, gear, batteryVehiclePropertyIds — predefined IDs such as INFO_MODEL and CURRENT_GEARFrom Android 14, system property definitions were split out of the VHAL interface into the AIDL interface android.hardware.automotive.vehicle.property. The CarPropertyManager and CarPropertyService stacks also gained asynchronous get/set APIs and APIs supporting a fake VHAL mode in Car Service.
That fake VHAL is the practical way in: you can exercise property reads and writes without a vehicle in front of you.
Reading properties (section 03) covers maybe half of automotive work. Here are the things AAOS has and a phone does not, in roughly the order you meet them when you build something.
Each VHAL property has a config alongside its value, and that config decides most of how your app behaves.
| Field | Values | What it means |
|---|---|---|
| access | READ / WRITE / READ_WRITE | Read-only or writable. Speed is read-only; the HVAC target temperature is read-write |
| changeMode | STATIC / ON_CHANGE / CONTINUOUS | STATIC never changes after boot (the model name). ON_CHANGE reports only when the value changes (the gear). CONTINUOUS changes all the time and is reported at a chosen rate (speed) |
| areaId | GLOBAL / seat / window / door / mirror / wheel | The same "seat heater" is a separate area for the driver and the front passenger |
| status | AVAILABLE / UNAVAILABLE / ERROR | When there is no value, you get this status instead |
A property ID is a set of bits. It is a 32-bit value built from "group (SYSTEM or VENDOR) | area type | value type | number". OEM-specific properties live in the VENDOR group.
// Building an OEM property ID (example)
VehiclePropertyGroup.VENDOR // 0x20000000
| VehicleArea.GLOBAL // 0x01000000
| VehiclePropertyType.INT32 // 0x00400000
| 0x0101 // a running number inside that OEMPermissions are set per property. Some can be read by any app (the model, the gear), some need a runtime grant from the user (speed), and some can only be held by the OEM's system apps (controlling the HVAC). Day 3 of section 07b exists so you feel these steps yourself.
Since Android 13 the VHAL is AIDL (HIDL before that). AOSP ships a reference implementation in which a fake hardware layer (FakeVehicleHardware) reads property definitions from JSON. That is what the emulator's fake VHAL really is. An OEM replaces this layer with code that talks to its own vehicle network.
AAOS has driving states (PARKED / IDLING / MOVING) and a set of UX restrictions for each. The OEM configures the combinations, for example "no video and no setup while idling, fully restricted while moving".
// Declare that a screen may stay up while driving (AndroidManifest.xml)
<activity android:name=".DistractionOptimizedMainActivity" ...>
<meta-data android:name="distractionOptimized" android:value="true"/>
</activity>Screens without this declaration are blocked while driving. Screens that declare it still have to shrink to the restrictions delivered by CarUxRestrictionsManager (a maximum string length, no keyboard, no video and so on). "Usable while driving" means a screen that cuts itself down to fit the restrictions.
A phone basically has one output. A car has several: driver, rear seats, external speakers. AAOS splits the cabin into audio zones and gives each zone volume groups and output devices. The OEM writes that mapping in car_audio_configuration.xml.
AUDIO_DEVICE_OUT_BUS, treated as addressable "buses" (for example music on bus_1, navigation prompts on bus_2)CarAudioService. There are three kinds — Exclusive (the newcomer takes focus), Reject (the newcomer is refused) and Concurrent (both play). Music playing quietly under a navigation prompt is a Concurrent caseThe Honda talk mentioned in section 02 spends time on AudioFlinger and CarAudioManager because this layer is designed differently in every car.
AP_POWER_STATE_REQ / AP_POWER_STATE_REPORT). Switching off the car does not cut the system at once; suspend or shutdown is prepared in stepsOEMs restyle the screens to match their brand, but they do not rewrite the AOSP app code every time. Apps built from Car UI library components (toolbar, lists and so on) can have colors, sizes and layouts replaced from outside with RRO (Runtime Resource Overlay). That is how "a different look in every model, the same app underneath" is made.
In short
distractionOptimized and shrink to the UX restrictionsAAOS on its own ships with neither Google Maps nor Play.
GAS (Google Automotive Services) is the set of Google services layered on top of AAOS — Google Maps, Google Play, the assistant. AAOS is open source; GAS is licensed by the OEM. That is the dividing line.
A car advertised as "Google built-in" is a car carrying GAS. Being able to install apps from the Play Store in the car is likewise limited to vehicles from GAS partners.
Shipping GAS means passing certification
The product has to meet Google's compatibility, performance and security requirements, which brings a certification campaign with it. Four suites come up repeatedly:
Google-accredited third-party labs exist for this work — HARMAN's Automotive Engineering Services, for instance, has announced accreditation for AAOS and GAS certification testing.
A term with very little written about it, so it is worth stating plainly.
Carma is the name of the Car Ready Mobile Apps program: Google's route for bringing existing mobile apps onto AAOS large screens without much rework. Its shape:
The trade is explicit: give up use while driving, and the porting cost drops to near zero. That is a different goal from building a driving-safe app from scratch with the Car App Library.
| What you want | What you use |
|---|---|
| Run an existing app on the car's screen while parked | Carma (Car Ready Mobile Apps) |
| Build an app usable while driving | androidx.car.app — Car App Library templates |
| Read or write vehicle data | android.car / CarPropertyManager |
How an app joins the program. Google's published criteria, in short:
Announced at I/O in May 2024, the program started rolling apps out to cars with Google built-in in early 2025. If a search for "CaRMA" led you here: it is the same program — Carma, CaRMA and Car Ready Mobile Apps all refer to it.
The specification is in motion, so check the date on anything you read.
Headlines about Android Automotive OS, refreshed automatically every day (needs JavaScript).
In-car voice assistance is migrating from Google Assistant to Gemini. A rollout to roughly four million GM vehicles was reported in April 2026, and Google has said the rollout extends from Android Auto vehicles to Google built-in vehicles — names mentioned include the Lincoln Nautilus, Honda Passport, and select Chevrolet, Cadillac, GMC, Acura and Volvo models.
In Google built-in cars, Gemini sits closer to vehicle systems: infotainment settings, app state, EV information, owner's-manual content, and the car's own UX restrictions.
Google has announced "Android Automotive OS for Software Defined Vehicles", slated for release in late 2026 as an open-source program via AOSP. The scope moves beyond infotainment toward vehicle software generally.
Everything below the app layer can be exercised on a laptop. The steps, as of Android Studio in 2026:
adb shell cmd car_service inject-vhal-event <propertyId> <value> injects a property change; adb shell cmd car_service help lists the rest.adb shell dumpsys car_service, and read properties from your app through Car.createCar(context).getCarManager(Car.PROPERTY_SERVICE) — the CarPropertyManager from section 03.Certification-stage testing (CTS-for-cars, GAS requirements) still needs an OEM bench or an accredited lab, but nothing in the first months of development requires a vehicle.
If you want to work on AAOS rather than just read about it, the employers, skills per layer, pay ranges and where the jobs are posted are covered in Android Automotive OS engineer — jobs, salary and how to find AAOS work.
Where this page stands
Everything here comes from published primary documentation and public articles. It contains no confidential information about any specific vehicle, program or company. Specifications change — verify against current AOSP documentation before you implement.
Assuming the setup from section 07, one or two hours a day. The goal for day seven: explain the layer structure in your own words.
PERF_VEHICLE_SPEED) through CarPropertyManager and show it on screen. Change the value in Extended controls → Car data and confirm the callback fires.SecurityException. Check in the AOSP list which permissions are system-app only, and write down what a normal app cannot see.adb shell dumpsys car_service. Somewhere the diagrams from sections 02–03 line up with a real log.Twelve terms worth memorizing
VHAL (vehicle HAL; turns CAN signals into properties) / HAL (hardware abstraction layer) / CarService (the system service that hands out properties) / CarPropertyManager (the app-side API for reading them) / GAS (Google Automotive Services: Maps, Play, Assistant and friends) / GMS (the phone-side equivalent) / Car App Library (template-based UI for cars) / DHU (Desktop Head Unit, the Android Auto test tool) / Carma (Car Ready Mobile Apps: existing apps allowed while parked) / OEM (the car maker) / Tier1 (the supplier that builds units for the maker) / CTS / ATS (compatibility and automotive certification test suites)
Books worth reading
[PR] Links go to Amazon.co.jp search results; this site may earn a referral fee. Check editions and stock on the store.
Short answers to the questions that bring most readers to this page.