Skip to content

Learn AAOS · Interactive

Cockpit zones and displays

Almost every multi-display bug in automotive comes from code that says “the display”, “the user” or “the current Activity” as though there were one of each. Here there are five displays, four zones and four users, and you can watch the assumption break.

5 displays · 4 occupant zonesUX restrictions applied live
Property simulator

Occupant zones

A zone ties a seat to its displays and to a user. Nothing here is “the” display or “the” user.

Driverzone 0

SEAT_ROW_1_LEFT

Driver profile

display 1 · display 0

Front passengerzone 1

SEAT_ROW_1_RIGHT

vacant

display 2

Rear leftzone 2

SEAT_ROW_2_LEFT

vacant

display 3

Rear rightzone 3

SEAT_ROW_2_RIGHT

vacant

display 4

What each display is showing

parked · nothing restricted
Instrument clusterdisplay 1

Cluster view

distractionOptimized — allowed while driving

Driver profileDriver80%driver-facing
Centre screendisplay 0

Navigation

distractionOptimized — allowed while driving

Driver profileDriver70%driver-facing
Front passengerdisplay 2

Video player

not distraction-optimised

vacantFront passenger70%
Rear leftdisplay 3

Nothing running

vacantRear left60%
Rear rightdisplay 4

Nothing running

vacantRear right60%

Restrictions police the driver-facing displays only. A rear passenger keeps watching whatever they were watching, which is why SEAT_OCCUPANCY and the zone graph matter as much as the speed does.

Where does the Activity land?

with a launch display

ActivityOptions options = ActivityOptions.makeBasic();
options.setLaunchDisplayId(0);
startActivity(intent, options.toBundle());

lands on

Centre screen · display 0

Exactly where you asked.

Driving state
PERF_VEHICLE_SPEED

0 m/s · 0 km/h

Above zero, UX restrictions apply to the driver-facing displays.

NIGHT_MODE
Users

User 0 keeps running headless underneath, holding the vehicle services. Switching the foreground user does not restart it.

Occupancy
SEAT_OCCUPANCY

SEAT_ROW_1_LEFT

SEAT_OCCUPANCY

SEAT_ROW_1_RIGHT

SEAT_OCCUPANCY

SEAT_ROW_2_LEFT

SEAT_OCCUPANCY

SEAT_ROW_2_RIGHT

Displays
id 1
PER_DISPLAY_BRIGHTNESS
id 0
PER_DISPLAY_BRIGHTNESS
id 2
PER_DISPLAY_BRIGHTNESS
id 3
PER_DISPLAY_BRIGHTNESS
id 4
PER_DISPLAY_BRIGHTNESS
Activity launch

Turn this off to see where an unqualified startActivity actually goes.

Display ids here follow the usual convention — 0 is the default display. On a real product they come from the occupant zone configuration, not from a constant.

Things worth trying

  • Put a video on the centre screen, then drive. It is blocked. Put the same video on a rear display and drive — it keeps playing. Restrictions police the driver, not the vehicle.
  • Turn off “name a launch display”. Every Activity lands on display 0, in front of the driver, whoever you meant it for. This is the single most common multi-display bug.
  • Give each zone a different user. “The current user” now has four different answers depending on which screen you are asking about — which is why storage, preferences and accounts all differ per display.
  • Switch the foreground user. The driver’s screens change; user 0 keeps running headless underneath, holding the vehicle services. It does not restart.
  • Set Settings running on the cluster and drive. Blocked — because it is not marked distractionOptimized, not because of anything about Settings itself.

What this models, and what it does not

The zone-to-seat-to-display-to-user mapping, the driver-facing distinction, and the way UX restrictions follow driving state are all real, and they are the parts people get wrong. Display ids follow the usual convention, with 0 as the default; on a real product they come from the occupant zone configuration rather than a constant.

The full detail lives in occupant zones and multi-display, the headless system user model and UX restrictions.