Android is not the only answer to "what runs the screen". A large part of the industry runs plain Linux, and understanding why makes the trade-offs of your own platform much clearer.
Why not just use a desktop distribution#
Yocto: building a distribution rather than installing one#
Yocto is not a Linux distribution. It is a build system that produces one from recipes.
meta (Yocto core recipes)
meta-poky (reference distro policy)
meta-openembedded (community recipes)
meta-<soc-vendor> (kernel, bootloader, GPU drivers for your chip)
meta-agl (automotive services and profiles)
meta-<oem> (your applications, your branding, your policy)
↓
bitbake
↓
image + SDK + licence manifest + SBOMGotcha
The output that surprises people is not the image — it is the licence manifest and . Yocto emits a full account of every component and its licence, because that account is a shipping requirement. Getting it for free is one of the strongest practical arguments for the whole approach.
The cost, stated plainly#
A full Yocto build from cold is measured in hours and tens of gigabytes. Adding one library can trigger a large rebuild. New engineers find it opaque for weeks.
AGL: the shared baseline#
Every OEM building automotive Linux was solving the same problems separately. is the Linux Foundation project that pooled that work.
Things AGL contributes that you would otherwise write:
| Piece | What it handles |
|---|---|
| agl-compositor | Wayland compositor with automotive policy — which surface may be on top, and when |
| Application framework | Launching, sandboxing and permissioning applications |
| Audio (PipeWire/WirePlumber) | Routing, priority and ducking between sources |
| KUKSA integration | Vehicle signals as , through a data broker |
| Demo platform | A bootable reference on common dev boards |
Android versus Linux, decided honestly#
| Android Automotive | Automotive Linux / AGL | |
|---|---|---|
| App ecosystem | Play or APK sideload, huge developer pool | Build your own, or web apps |
| Time to a working UI | Fast — the framework is there | Slower — more assembly |
| Control over the stack | Bounded by AOSP's shape | Total |
| Licence exposure | Apache-2 base, Google terms for GAS | You choose every component |
| Memory and storage floor | High | Low, and tunable |
| Boot time | Harder to shorten | Easier to shorten |
| Graphics maturity | Excellent, phone-grade | Good, more integration work |
| Multi-user, multi-display | Built in | You design it |
| Talent pool | Very large | Smaller, more specialised |
| Google relationship | Required for GAS | None |
| Safety certification | Not for the framework | Not for stock Linux either |
Where both approaches meet#
The interesting development is that below the UI, the two converge.
Next#
The platform that handles what neither Android nor stock Linux will — QNX and safety operating systems.