# Android Automotive OS (AAOS) > 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. 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. Source: https://auto-st.com/glossary/android-automotive ยท Updated: 2026-10-07 ## 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 **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 - [Android Open Source Project: Android Automotive (architecture, Vehicle HAL, car service)](https://source.android.com/docs/automotive) - [Android Open Source Project: Security-Enhanced Linux in Android](https://source.android.com/docs/security/features/selinux) - [Android Developers: Android Debug Bridge (adb)](https://developer.android.com/tools/adb) ## Related - [IVI (In-Vehicle Infotainment)](https://auto-st.com/glossary/ivi) - [ADB (Android Debug Bridge)](https://auto-st.com/glossary/adb) - [Android IVI security checks every head unit should pass](https://auto-st.com/insights/android-ivi-security-checks) - [The screen is an attack surface too.](https://auto-st.com/ivi-security-testing) - [Gateway ECU (Central Gateway)](https://auto-st.com/glossary/gateway-ecu) --- AutoST by Zyberum. Canonical page: https://auto-st.com/glossary/android-automotive