# Android Automotive OS (AAOS)

> Android Automotive OS (AAOS) ist eine Android-Variante, die direkt auf der Infotainment-Head-Unit läuft, nicht auf dem Smartphone. Dazu kommen ein Car Service und ein Vehicle HAL, der Fahrzeug-Properties wie Geschwindigkeit, Klima oder Gang für Apps bereitstellt. Damit ist die Head Unit ein vollständiges Android-Gerät im Fahrzeugnetz, mit Apps, Berechtigungen, ADB und SELinux, und mit jeder Härtungslücke eines Smartphones plus einem Weg zu Fahrzeugfunktionen.

Android Automotive OS läuft direkt auf der Head Unit und spricht über den Vehicle HAL mit dem Fahrzeug. Der Unterschied zu Android Auto und was wir am Prüfstand finden.

Source: https://auto-st.com/de/glossar/android-automotive · Updated: 2026-10-07

## Was ist Android Automotive OS?

Android Automotive OS (AAOS) ist Android, gebaut als Betriebssystem einer Infotainment-Head-Unit (IVI). Es ist der komplette Android-Stack vom Linux-Kernel über die Systemdienste bis zu den Apps, erweitert um Automotive-Teile: einen Car Service, den Vehicle Hardware Abstraction Layer (VHAL) sowie fahrzeugspezifische APIs und Berechtigungen.

Der VHAL ist die Brücke zum Fahrzeug. Er stellt Fahrzeug-Properties bereit, jede mit einer ID, einem Typ und Zugriffsregeln: eingelegter Gang, Geschwindigkeit, Klimatemperatur, Sitzposition, Türstatus. Hinter dem VHAL sitzt Hersteller-Code, der mit einem Vehicle-Interface-Prozessor oder direkt mit CAN oder Ethernet spricht. Eine App liest oder schreibt Properties über den Car Service, der vor der Weitergabe die Android-Berechtigungen prüft.

## Wo ist es definiert?

Android Automotive definiert Google in der Dokumentation des Android Open Source Project, nicht eine ISO-Norm. Die AOSP-Seiten beschreiben die Architektur, die VHAL-Property-Definitionen, die Car Permissions und die Kompatibilitätsanforderungen an eine Head Unit. Die Security-Grundlagen kommen aus der allgemeinen Android-Dokumentation: SELinux im Enforcing Mode, Verified Boot, App-Sandboxing und die Regeln für Debug-Schnittstellen wie ADB.

## Was es in der Praxis bedeutet

Eine AAOS-Head-Unit ist ein Android-Gerät auf Rädern. Am Prüfstand bekommt sie dieselben Fragen wie jedes Android-Gerät und noch einige mehr. Wir sehen regelmäßig IVI-Units mit aktiviertem ADB in Serien-Builds, Apps mit `android:debuggable="true"`, exportierte Activities und Services, die jede App starten kann, System-Properties, die interne Konfiguration verraten, und Dateien, die sich ohne Root herunterziehen lassen. Auf Engineering-Builds läuft SELinux manchmal permissive.

Der Automotive-Teil erhöht den Einsatz. Eine VHAL-Property, die Schreibzugriff mit einer normalen Berechtigung erlaubt, oder ein Hersteller-Service, der rohe CAN-Frames weiterreicht, macht aus einer Schwäche auf App-Ebene eine auf Fahrzeugebene. Die Head Unit hängt außerdem oft am Gateway und leitet teils Diagnose weiter, damit ist sie ein naheliegender Pivot-Punkt.

## Wie AutoST es testet

AutoST verbindet sich über ADB mit der Head Unit oder einem Emulator und führt einen Härtungscheck aus: installierte Pakete und ihre Berechtigungen, exportierte Komponenten, herunterladbare Dateien, SELinux-Status und statische Analyse der APKs auf Debuggable-Flags und hart codierte Secrets. Jedes Finding kommt mit einer Abhilfe und landet im selben Fix Plan wie die UDS-, DoIP- und SOME/IP-Findings.

## Häufige Missverständnisse

AAOS ist nicht "nur das Radio". Darauf liegen Nutzerdaten, Zugangsdaten für vernetzte Dienste und ein Weg zu Fahrzeugfunktionen. Und ein von Google abgenommener Build ist nicht automatisch gehärtet: Die meisten Findings stecken in den Apps und Services, die OEM oder Tier-1 obendrauf setzen.

## FAQ

**Ist Android Automotive dasselbe wie Android Auto?**

Nein. Android Auto läuft auf dem Smartphone und spiegelt dessen Oberfläche auf das Display der Head Unit. Android Automotive OS ist das Betriebssystem der Head Unit selbst und läuft auch ohne verbundenes Smartphone.

**Kann eine Android-Automotive-App das Fahrzeug steuern?**

Nur über den Car Service und den Vehicle HAL, und nur für Properties, die ihre Berechtigungen erlauben. Lesen von Geschwindigkeit oder Gang braucht eine Car Permission, Schreiben auf Klima oder ähnliche Properties eine privilegierte oder Signatur-Berechtigung. Eine schwache Konfiguration dieser Berechtigungen ist genau das, wonach ein Härtungscheck sucht.

**Braucht Android Automotive eigene Security-Tests?**

Ja. Die Head Unit hat die Angriffsfläche eines Android-Geräts (Apps, ADB, exportierte Komponenten, SELinux) plus eine Verbindung ins Fahrzeugnetz. UDS-Tests an den Fahrzeug-Steuergeräten decken das nicht ab.

## Sources

- [Android Open Source Project: Android Automotive (Architektur, 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/de/glossar/ivi)
- [ADB (Android Debug Bridge)](https://auto-st.com/de/glossar/adb)
- [Android-IVI-Security-Checks, die jede Head Unit bestehen sollte](https://auto-st.com/de/insights/android-ivi-security-checks)
- [Der Bildschirm ist auch eine Angriffsfläche.](https://auto-st.com/de/ivi-security-test)
- [Gateway-Steuergerät (Central Gateway)](https://auto-st.com/de/glossar/gateway-steuergeraet)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/de/glossar/android-automotive