AAOS: The Infotainment Platform

TL;DR

AAOS (Android Automotive OS) is the full Android stack running as a guest VM on QNX, not a phone projection layer. Car Service manages vehicle-aware features: property subscriptions, UX restrictions, occupant zone routing. VHAL bridges Android to the vehicle (speed, gear, HVAC, doors). AAOS has its own app ecosystem (OEM apps, Google Automotive Services, Play Store). Debug with adb, logcat, and dumpsys car_service. Do not confuse AAOS with Android Auto: one is an OS in your dash, the other is a phone app.

AAOS is what users touch, what OEM product teams demo, and where 80% of your adb sessions probably live. But it’s a guest. It doesn’t own the hardware, doesn’t route CAN frames, and doesn’t render the instrument cluster. Understanding where AAOS ends and QNX/VHAL begin prevents wasted debug cycles.

Full Android Stack as Guest VM

AAOS is not a stripped-down embedded Linux with an Android skin. It’s the real stack:

Layer	What It Includes
Linux kernel	Guest kernel (virtio drivers, not bare-metal)
Android Runtime (ART)	Java/Kotlin bytecode execution, GC, JIT
Native layer	HAL implementations, libhardware, vendor blobs
Android Framework	Activity Manager, Window Manager, Input, Permissions
Automotive extensions	Car Service, Car API, UX restrictions, multi-display
Apps	System UI, Launcher, Settings, OEM apps, Play Store apps

The guest kernel talks to hardware through VirtIO paravirtualized devices (virtual block, network, GPU, vsock) provided by the QNX hypervisor. AAOS thinks it has a machine; QNX decides what it actually gets.

flowchart TB
    subgraph GuestVM["AAOS Guest VM"]
        APPS["Apps · OEM · Play Store"]
        CAR["Car Service / Car API"]
        FW["Android Framework"]
        HAL["Vehicle HAL (VHAL client)"]
        LK["Guest Linux Kernel"]
        APPS --> CAR --> FW --> HAL --> LK
    end

    subgraph QNXHost["QNX Hypervisor Host"]
        VIRTIO["VirtIO Backends"]
        VHAL_SRV["VHAL Server"]
    end

    LK --> VIRTIO
    HAL <-->|"vsock / gRPC"| VHAL_SRV

Car Service: The Automotive Brain in Framework

Car Service (com.android.car) is a persistent system service, the automotive equivalent of ActivityManager for vehicle features. It starts at boot and never stops.

What Car Service manages:

Responsibility	Example
VHAL connection	Binds to Vehicle HAL, caches property values, dispatches updates
Property subscriptions	Apps subscribe to PERF_VEHICLE_SPEED, GEAR_SELECTION, etc.
UX restrictions	Blocks video playback while driving, limits keyboard input
Occupant zones	Routes audio/display/input to driver vs passenger
Power policy	Interacts with garage mode, screen off timers
User management	Driver profiles, admin restrictions

Apps don’t talk to VHAL directly. They use the Car API (android.car.*), which talks to Car Service, which talks to VHAL:

App → CarPropertyManager → Car Service → VHAL → (vsock) → QNX VHAL Server → CAN

Mental Model

AAOS is a luxury apartment rented inside QNX’s building. The apartment has its own kitchen (framework), furniture (apps), and intercom (Car Service). But QNX owns the plumbing, electricity, and front door. When water stops, you don’t fix it inside the apartment — you call the building manager (QNX/VHAL server).

VHAL: The Bridge to the Vehicle

VHAL (Vehicle Hardware Abstraction Layer) is the HAL interface between Android and vehicle hardware. On virtualized platforms, the VHAL client runs in AAOS; the VHAL server runs on QNX (Module 6.3 covers this in depth).

From AAOS’s perspective, VHAL exposes properties: typed, area-scoped values.

Property	Type	What Apps See
PERF_VEHICLE_SPEED	float	Current speed in m/s
GEAR_SELECTION	int (enum)	Park, Reverse, Drive, Neutral
HVAC_TEMPERATURE_SET	float	Target temp per zone
DOOR_LOCK	int (enum)	Locked/unlocked per door area

Car Service caches these and pushes updates to subscribed apps. If VHAL goes silent, every vehicle-dependent feature freezes: nav speed warnings, gear-dependent UI, climate controls.

Common Gotcha

Vehicle speed in logcat looks fine but the cluster shows zero? They’re different pipelines. Cluster speed typically comes from QNX directly (gateway → cluster renderer). IVI speed comes from VHAL → Car Service → apps. A bug in VHAL server affects Android; a bug in QNX gateway can affect both, or just one, depending on signal routing.

AAOS vs Android Auto: Not the Same Thing

This confusion persists in meetings, RFPs, and bug tickets. Nail the distinction:

	AAOS (Android Automotive OS)	Android Auto (Phone Projection)
What it is	Full OS running on the vehicle’s SoC	Phone app projecting UI to the car’s display
Where compute runs	Vehicle head unit (guest VM on QNX)	User’s phone (USB/Wi-Fi to head unit)
Apps	Installed on vehicle storage, Play Store (if GAS)	Only apps Google certifies for projection
Vehicle integration	Direct VHAL access, native vehicle properties	Limited: mostly media, nav, messaging via phone
Offline capability	Full functionality without phone	Requires phone connected
OEM customization	Deep: launcher, system UI, HAL, Car Service	Minimal: Google-controlled UI template
Your debug tools	ADB, logcat, dumpsys, systrace	Mostly phone-side logcat; head unit shows surface
Typical use today	Primary IVI in new vehicle programs	Secondary UX, legacy head units, user preference

AAOS Build Flavors: AOSP vs GAS vs OEM

AOSP (Android Open Source Project) is the base, with no Google apps. GAS (Google Automotive Services) adds Play Store, Maps, Assistant, and requires Google certification. OEM builds layer custom launchers, skins, and pre-installed apps on either base.

Your daily work differs by flavor: GAS builds have Google Play Services updates and CTS/VTS requirements; AOSP-only builds give OEMs full control but no Play Store. Both still use Car Service and VHAL; the vehicle integration layer is the same.

App Ecosystem

AAOS supports three app categories. OEM system apps — custom launchers, brand settings, vehicle companion apps — ship pre-installed and OEM-signed. Google Automotive Services (GAS) adds Maps, Assistant, and Play Store (if licensed) as Google-signed apps in the GAS bundle. Third-party and Play Store apps like Spotify, WhatsApp (where permitted), and parking apps distribute through the Play Store or sideloading.

Automotive apps use the Car App Library for driving-optimized UX (templates, limited interaction). Not every phone app works. Apps must be automotive-compatible or explicitly adapted.

Development implications:

• System apps require platform signing keys or priv-app placement
• Play Store apps go through automotive compatibility review
• UX restrictions (Driving State) can block your app during testing; use adb shell cmd car_service set-driving-state to simulate

Key Tools: ADB, logcat, dumpsys

ADB provides shell access, app installation, port forwarding, and bugreport capture — start with adb root && adb shell. logcat streams live system logs; filter vehicle-related tags with adb logcat -s CarService:V VHAL:V. dumpsys car_service dumps Car Service internal state — VHAL connection, cached properties, and subscribers — via adb shell dumpsys car_service.

High-value debug commands:

# Car Service health: properties, subscribers, VHAL connection
adb shell dumpsys car_service

# Vehicle property values right now
adb shell dumpsys android.hardware.automotive.vehicle.IVehicle/default

# Simulate driving for UX restriction testing
adb shell cmd car_service set-driving-state true

# Full bugreport for JIRA attachment
adb bugreport bugreport.zip

Filter logcat tags you’ll see daily: CarService, CAR.HAL, VhalClient, CarPropertyService, ActivityManager.

Where You'll See This

Your typical AAOS debug flow:

1. Reproduce on bench or in vehicle with adb logcat -c (clear) then repro
2. Check Car Service first. Is VHAL connected? Are properties updating?
3. Isolate layer: app bug vs Car API vs VHAL client vs QNX server
4. Cross-check QNX if vehicle data is wrong at the source (Module 6.3)

Common tickets and where to look:

• “Nav doesn’t know vehicle speed” → dumpsys car_service, check PERF_VEHICLE_SPEED subscription
• “Video plays while driving” → UX restrictions / driving state, Car Service policy
• “App can’t read door status” → VHAL property permissions and area IDs
• “System UI crash loop” → logcat AndroidRuntime — may be unrelated to vehicle at all

AAOS teams own the UX and app layer. When vehicle data is wrong, split the ticket: AAOS consumer vs QNX producer.

Connect the Dots

Module 6.1 (QNX) is the hypervisor host running this guest VM. Module 6.3 (VHAL Deep Dive) traces the property path from Car Service to CAN. Module 6.4 (Display & Audio) covers how AAOS shares screens and speakers with QNX. Module 7.1 (AMSS) is a separate subsystem; telematics runs on the modem, not in AAOS.

What to remember

1. AAOS is a full Android OS in a guest VM, not phone projection.
2. Car Service is the central vehicle feature manager; apps go through it, not VHAL directly.
3. VHAL bridges Android to real vehicle data: client in AAOS, server on QNX.
4. AAOS ≠ Android Auto: onboard OS vs phone projection.
5. Debug trio: adb, logcat, dumpsys car_service.

Check Your Understanding

1. What is the correct data flow when an AAOS app reads vehicle speed?

A. App → VHAL directly → CAN busB. App → Car API → Car Service → VHAL client → (vsock) → VHAL server on QNXC. App → QNX gateway → Android FrameworkD. App → Android Auto → Phone sensor → Head unit

2. Which statement best distinguishes AAOS from Android Auto?

A. They are the same product with different brandingB. AAOS runs as a full OS on the vehicle SoC; Android Auto projects phone UI to the displayC. Android Auto has deeper VHAL integration than AAOSD. AAOS only works with Qualcomm chips; Android Auto works with any chip

3. Which command is most useful for checking whether Car Service is connected to VHAL and receiving property updates?

A. adb shell pidin arB. adb shell slog2info -wC. adb shell dumpsys car_serviceD. adb shell dmesg | grep virtio