Android Automotive OS: The Technical Reality of Implementation
Last week we explored the fundamentals of Android Automotive OS (AAOS). Today we go a step further: how does AAOS work under the hood, and what practical challenges do developers face?
Android Automotive Architecture
Technically, Android Automotive is built on the Android Open Source Project (AOSP). That makes it an open system that carmakers can tailor to their needs. To let software talk to the vehicle, AAOS relies on a layered architecture:
- Android App: The visible application for drivers and passengers, such as a music player or eco-analysis tool.
- Android Framework: Provides core services for apps, e.g. notifications, UI elements, and background services.
- Car Services: Mediate between apps and vehicle data and control which app may request which information.
- Vehicle HAL (Hardware Abstraction Layer): Translates software requests into a language the hardware understands.
- Vehicle Hardware: The actual sensors and ECUs in the car—speed sensor, battery controller, tire-pressure sensors, etc.
On this foundation, apps can read data points such as speed, battery level, or current gear.
Access to data is governed by AAOS permission levels:
- Normal permissions: e.g. media control. Apps can use them without user approval.
- Dangerous permissions: e.g. speed, gear, or location. Require explicit user consent.
- Signature permissions: Highly protected. Only available to carmakers or OEM-signed apps, typically for safety-critical or highly sensitive data.
GAS vs Non-GAS
OEMs can deploy AAOS in two ways: with Google Automotive Services (GAS) or without (Non-GAS).
With GAS (used by Volvo, Renault, Nissan, Polestar), Google Maps, the Play Store, and other services ship directly in the car. OEMs opting for their own navigation and app stores run Non-GAS; the underlying AAOS API surface stays the same.
For developers, the difference is substantial:
- GAS: Apps are published via the Google Play Store, pass Google’s review, and then appear automatically in all GAS cars.
- Non-GAS: Stores are OEM-specific—e.g. Harman Ignite Store (VW Group) or Forvia Appning Store (BMW, Mercedes, Smart, Lotus, Zeekr). Apps must be uploaded, technically vetted, and individually approved by each OEM.
Templates vs Custom
Regardless of detailed design guidelines (more on that in a later article), developers must decide between Google’s templates or fully custom UIs.
Google supplies UI components—lists, grids, message views—tested for safety and, in some cases, usable while driving. OEMs can adopt, tweak, or extend these templates. Ideally, the app automatically matches the infotainment theme of each car.
In practice, templates are often only partially or inconsistently implemented—especially in Non-GAS systems. A single app version that works flawlessly in every store is therefore hard to achieve. In GAS cars, templates are currently more stable and uniform.
With Jetpack Compose, developers can build completely custom UIs, offering maximum design freedom—but the app then ignores OEM styling and looks identical across vehicles.
Conclusion
Android Automotive OS offers enormous technical flexibility for OEMs and developers. Yet the ecosystem is still young. Divergent store structures, fragmented template implementations, and the GAS/Non-GAS split create clear challenges. Anyone building AAOS apps must plan strategically and remain agile to meet varied OEM requirements.