The confusing case: a car running Android Automotive that also hosts Android Auto or CarPlay. Two Androids, one screen, and the handover rules between them.
Intermediate5 minProjection · Android Auto · CarPlay
The foundations topic separated Android Auto from Android Automotive OS. Now the
case that muddles them again: an AAOS vehicle that also supports Android Auto.
The projected session is, from AAOS's point of view, just another app.
The layering
AAOS (the vehicle's own Android) ├── native media app ├── native navigation ├── settings └── projection app ← hosts the phone session └── the phone's UI, streamed in as pixels
Two Androids competing for one screen and one set of speakers needs arbitration,
and getting it wrong is very visible to the driver.
Audio focus is the mechanism. The projection app requests focus like any
other app. When the phone plays music, the projection app holds media focus and
the car's own media app pauses.
Vehicle functions always win. A reversing camera, a collision warning, a
climate control interaction interrupts projection immediately. The car's own
safety and vehicle-control surfaces are never subordinate to a projected session.
Wireless projection uses a direct Wi-Fi link between phone and head unit,
established over Bluetooth.
How a wireless session starts
1. Phone and head unit are paired over Bluetooth2. Head unit uses BLE/Bluetooth to hand the phone Wi-Fi credentials3. Phone joins a direct Wi-Fi link with the head unit4. Video and audio stream over that link
CarProjectionManager, for a projection host appkotlin
val projection = car.getCarManager(Car.PROJECTION_SERVICE) as CarProjectionManagerprojection.registerProjectionRunner(serviceIntent)// Ask the platform to start the Wi-Fi access point for a wireless sessionprojection.startProjectionAccessPoint(callback)
This needs android.car.permission.CAR_PROJECTION — signature-level, because a
projection host takes over the screen and audio. It is a system app, not
something a third party ships.