Android Automotive OS: Die technische Realität der Implementierung
Letzte Woche haben wir die Grundlagen von Android Automotive OS (AAOS) beleuchtet. Heute gehen wir einen Schritt weiter: Wie funktioniert AAOS technisch und vor welchen Herausforderungen stehen Entwickler in der Praxis?
Android Automotive Architektur
Android Automotive basiert technisch auf dem Android Open Source Project (AOSP). Das bedeutet: Es ist ein offenes System, das von Fahrzeugherstellern individuell angepasst werden kann. Damit die Software mit dem Fahrzeug kommunizieren kann, braucht es eine strukturierte Architektur mit mehreren Schichten:
- Android App: Die sichtbare Anwendung für Nutzerinnen und Nutzer, zum Beispiel Musikplayer oder Eco-Analyse.
- Android Framework: Stellt grundlegende Funktionen für Apps bereit, etwa Benachrichtigungen, UI-Elemente oder Services.
- Car Services: Vermitteln zwischen Apps und Fahrzeugdaten und regeln, welche App welche Informationen anfragen darf.
- Vehicle HAL (Hardware Abstraction Layer): Übersetzt Anfragen aus der Softwarewelt in eine Sprache, die die Hardware versteht.
- Vehicle Hardware: Die eigentlichen Sensoren und Steuergeräte im Fahrzeug, wie Geschwindigkeitssensor, Batteriesteuerung oder Reifendrucksensoren.
Auf dieser Grundlage lassen sich Datenpunkte wie Geschwindigkeit, Batteriestand oder der aktuelle Gang auslesen.
Zentral für den Datenzugriff sind die von AAOS definierten Berechtigungen:
- Normale Berechtigungen: Zum Beispiel Mediensteuerung. Können von Apps ohne Zustimmung der Nutzerin oder des Nutzers verwendet werden.
- Gefährliche Berechtigungen: Zum Beispiel Geschwindigkeit, aktueller Gang oder Standort. Nur mit ausdrücklicher Zustimmung nutzbar.
- Signature Berechtigungen: Besonders geschützt. Nur von Fahrzeugherstellern oder durch sie signierten Apps verwendbar, etwa für sicherheitskritische oder besonders sensitive Daten.
GAS versus Non GAS
Bei der Implementierung von AAOS können Fahrzeughersteller grundsätzlich zwei Varianten wählen: mit Google Services (GAS) oder ohne (Non GAS).
Wird AAOS mit Google Services verwendet, wie bei Volvo, Renault, Nissan oder Polestar, sind Google Maps, der Play Store und weitere Dienste direkt im Fahrzeug verfügbar. Setzen OEMs auf eigene Navigationslösungen und App Stores, verwenden sie Non GAS. Die zugrunde liegende Schnittstelle von AAOS bleibt jedoch erhalten.
Für App-Entwickler macht das einen großen Unterschied:
- GAS : Die App wird über den Google Play Store veröffentlicht, durchläuft den Review-Prozess von Google und ist anschließend in allen GAS-Fahrzeugen automatisch verfügbar.
- Non GAS: Die Stores sind herstellerspezifisch. Es gibt unter anderem den Harman Ignite Store (für die VW-Gruppe) und den Appning Store von Forvia (für Marken wie BMW, Mercedes, Smart, Lotus oder Zeekr). Apps müssen dort hochgeladen, technisch geprüft und zusätzlich individuell von den OEMs freigegeben werden.
Templates versus Custom
Unabhängig von den genauen Designrichtlinien (mehr dazu in einem späteren Artikel) müssen Entwickler entscheiden, ob sie mit Templates oder vollständig eigenen Oberflächen arbeiten wollen.
Google stellt verschiedene UI-Komponenten wie Listen, Grids oder Nachrichtenansichten bereit, die sicherheitsgeprüft sind und teilweise während der Fahrt bedienbar sein sollen. OEMs können diese Templates übernehmen, anpassen oder erweitern. Im Idealfall passt sich die App damit automatisch dem Infotainment-Design des jeweiligen Fahrzeugs an.
In der Praxis werden Templates oft nur teilweise oder uneinheitlich implementiert – insbesondere bei non-GAS-Systemen. Eine einzige App-Version, die in allen Stores problemlos funktioniert, ist daher schwer umsetzbar. Bei GAS hingegen funktionieren die Templates aktuell soweit stabil und einheitlich.
Mit Jetpack Compose können vollständig eigene Benutzeroberflächen erstellt werden. Das bietet maximale Flexibilität im Design, bedeutet aber auch, dass sich die App nicht mehr an das OEM-Design anpasst. Sie sieht dann bei allen Fahrzeugen gleich aus.
Fazit
Android Automotive OS bietet technisch eine enorme Flexibilität für Hersteller und Entwickler. Gleichzeitig steht das Ökosystem noch am Anfang. Unterschiedliche Store-Strukturen, fragmentierte Template-Implementierungen und die Trennung zwischen GAS und Non GAS bringen klare Herausforderungen mit sich. Wer AAOS-Apps entwickeln will, muss strategisch planen und flexibel auf die verschiedenen Anforderungen der Hersteller reagieren.