Android Automotive OS (AAOS)
Android Automotive OS runs natively on the head unit and talks to the vehicle through the Vehicle HAL. How it differs from Android Auto and what we find on the bench.
Updated This page as Markdown
In short
Android Automotive OS (AAOS) is a version of Android that runs directly on the in-vehicle infotainment head unit, not on a phone. It adds a car service and a Vehicle HAL that exposes vehicle properties such as speed, HVAC or gear to apps. That makes the head unit a full Android device inside the vehicle network, with apps, permissions, ADB and SELinux, and every hardening gap of a phone plus a path towards vehicle functions.
What is Android Automotive OS?
Android Automotive OS (AAOS) is Android built to run as the operating system of an in-vehicle infotainment (IVI) head unit. It is the full Android stack, from the Linux kernel through system services to apps, extended by automotive parts: a car service, the Vehicle Hardware Abstraction Layer (VHAL) and car-specific APIs and permissions.
The VHAL is the bridge to the vehicle. It exposes vehicle properties, each with an ID, a type and access rules: current gear, speed, HVAC temperature, seat position, door state. Behind the VHAL sits vendor code that talks to a vehicle interface processor or directly to CAN or Ethernet. An app reads or writes properties through the car service, which checks Android permissions before passing the call on.
Where is it defined?
Android Automotive is defined by Google in the Android Open Source Project documentation, not by an ISO standard. The AOSP pages describe the architecture, the VHAL property definitions, the car permissions and the compatibility requirements a head unit has to meet. Security baselines come from general Android documentation: SELinux in enforcing mode, verified boot, application sandboxing and the rules for debug interfaces such as ADB.
What it means in practice
An AAOS head unit is an Android device with wheels attached. On the bench it gets the same questions as any Android device, and some on top. We regularly see IVI units with ADB enabled in production builds, apps marked android:debuggable="true", exported activities and services that any app can start, system properties that reveal internal configuration, and files that can be pulled without root. On engineering builds SELinux is sometimes permissive.
The automotive part raises the stakes. A VHAL property that allows writes with a normal permission, or a vendor service that forwards raw CAN frames, turns an app-level weakness into a vehicle-level one. The head unit is also often connected to the gateway and sometimes carries diagnostic routing, so it is a natural pivot point.
How AutoST tests it
AutoST connects to the head unit or an emulator over ADB and runs a hardening assessment: installed packages and their permissions, exported components, pullable files, SELinux posture and static analysis of APKs for debuggable flags and hard-coded secrets. Findings come with a remediation each and land in the same Fix Plan as the UDS, DoIP and SOME/IP findings.
Common misunderstandings
AAOS is not “just the radio”. It holds user data, credentials for connected services and a path into vehicle functions. And a locked-down Google-compliant build is not automatically hardened: most findings sit in the vendor apps and services that the OEM or Tier-1 adds on top.
FAQ
Frequently asked questions
Is Android Automotive the same as Android Auto?
No. Android Auto runs on the phone and projects its interface onto the head unit display. Android Automotive OS is the operating system of the head unit itself and keeps running without any phone connected.
Can an Android Automotive app control the vehicle?
Only through the car service and the Vehicle HAL, and only for properties its permissions allow. Read access to speed or gear needs a car permission, write access to HVAC or similar properties needs a privileged or signature permission. Weak configuration of these permissions is exactly what a hardening check looks for.
Does Android Automotive need its own security tests?
Yes. The head unit has the attack surface of an Android device (apps, ADB, exported components, SELinux) plus a link to the vehicle network. UDS tests on the vehicle ECUs do not cover it.
Sources
Related pages
- GlossaryIVI (In-Vehicle Infotainment)IVI is the vehicle head unit that runs apps, media and connectivity, often on Android or Linux. Why it is a large attack surface and what hardening checks look for.
- GlossaryADB (Android Debug Bridge)ADB is the Android debug interface over USB or TCP port 5555. Why it is the first thing to check on an Android head unit, and what an open ADB gives an attacker.
- InsightsAndroid IVI security checks every head unit should passHardening checks for an Android head unit: build type, debug flags, ADB exposure, SELinux, exported components, app flags and secrets, and what each means.
- PlatformThe screen is an attack surface too.AutoST checks Android infotainment over ADB: dangerous permissions, exposed components, pullable files, SELinux posture and APK static analysis, with per-finding fixes.
- GlossaryGateway ECU (Central Gateway)The gateway ECU connects the vehicle networks and decides which messages cross between them. Why it is the key security boundary and how its diagnostic routing fails.
