An honest assessment of what AAOS contributes to a software-defined vehicle, what it deliberately does not do, and where the boundary between Android and the rest of the vehicle actually sits.
Intermediate8 minAAOS · Platforms · Architecture
You already know how works. What is worth being precise about is
where it sits in a software-defined vehicle, because the boundary is drawn in a
specific place and a lot of confusion comes from misplacing it.
Android's slice of the vehicle stack — Everything above the VHAL is Android's world. Everything below it belongs to the vehicle and speaks the vehicle's protocols.
The is the boundary, and it is a good one because it is narrow and
explicit. Above it, Android sees a typed key-value world of
. Below it, the implementation can be anything.
An application model that already works. Lifecycle, permissions, process
isolation, resource management, an installer, a settings framework. Building
that from scratch is years of work that adds no differentiation.
Distribution. vehicles get Play, which means an app catalogue
without the OEM negotiating with every developer individually. Even AOSP-only
builds inherit APK packaging and signing.
Developers. The pool of engineers who can write an Android app is enormous
compared with the pool who can write a QNX Screen application.
Multi-display and multi-user out of the box. Occupant zones, per-user
profiles and multiple displays are platform features rather than a bespoke
subsystem. In a vehicle with front and rear screens this is significant.
Graphics that keep up. SurfaceFlinger, hardware composer, GPU compositing and
a mature animation stack. Modern cockpit UI expectations are essentially phone
expectations, and Android already meets them.
These are not deficiencies to argue away in a design review. They are the reasons
the architecture around Android looks the way it does. An engineer who
understands why the safety island exists is far more useful than one who
proposes moving its function into Android.
Increasingly the same Android instance drives both the centre screen and the
. This works, and the way it works is worth being precise about,
because the safety question does not disappear — it gets partitioned.
The change runs in both directions, and this part often gets missed.
Ethernet replaces bespoke plumbing. When the vehicle speaks SOME/IP over
Ethernet, the VHAL becomes a network client instead of a bus decoder. That is a
substantially simpler and more testable thing to write.
A data broker makes development possible without hardware. Point the
VHAL at a broker instead of the vehicle, inject values from a script, and the
entire Android stack above becomes testable on a desk. This is the single largest
productivity change available to an AAOS team.
Consolidation gives Android better hardware. A cockpit SoC shared with the
cluster and ADAS is far more capable than a dedicated head-unit chip of the
previous generation.
becomes normal. Android already has and a
proper update mechanism. In a vehicle programme that has committed to shipping
updates, that maturity is an argument in Android's favour rather than an
inconvenience.
