In-cabin cameras and driver monitoring

Increasingly, vehicles watch the driver. An infrared camera estimates where their eyes are pointed and whether they are closing. In several markets some form of this is becoming mandatory.

It is also the most privacy-sensitive component in the entire vehicle, and the architecture reflects that far more than most people expect.

What a driver monitoring system does#

DMS answers two questions continuously:

Is the driver looking at the road? Gaze direction, estimated from head pose and eye position.

Is the driver awake? Eye closure duration, blink rate, head nodding.

From those it derives a state — attentive, distracted, drowsy — and the vehicle responds: a chime, a seatbelt pulse, or on some systems a reduction in driver-assistance capability.

The architecture: images do not leave the module#

What Android actually receives#

Typically a small vendor interface carrying a state, not a camera stream.

@VintfStability
interface IDriverMonitoring {
    DriverState getState();
    void registerCallback(in IDriverStateCallback callback);
}
 
@VintfStability
parcelable DriverState {
    AttentionState attention;   // ATTENTIVE | DISTRACTED | DROWSY | UNKNOWN
    int confidencePercent;
    long timestampNanos;        // CLOCK_BOOTTIME, as everywhere else
}

Some programmes expose driver attention as a vehicle property instead, which gives you the existing permission and subscription machinery for free.

When there is a real camera feed#

Some in-cabin cameras are genuine cameras — for video calling, for a cabin monitor to check on rear-seat passengers, for occupant detection.

Those go through the ordinary Android camera stack, and the ordinary rules apply with more force:

<uses-permission android:name="android.permission.CAMERA"/>

Occupant detection is a different thing#

Do not confuse driver monitoring with occupant detection. They answer different questions and often use different hardware.

Occupant detection — is someone in the seat, are they a child, is a seatbelt fastened — usually comes from seat pressure sensors and belt buckle switches, and surfaces as vehicle properties rather than anything camera-based.

adb shell dumpsys car_service --list-properties | grep -i OCCUPANT

Privacy rules that are not negotiable#

The general telemetry rules apply, plus several specific to this:

Process on the edge. Vision runs on the module. Only the derived state moves.

Never store frames. No buffer, no cache, no "last frame for debugging". A debug build that writes frames to disk will eventually ship.

Never associate with identity. The system reports that the driver is drowsy, not that this person is. Correlating with a user profile turns a safety feature into surveillance.

Bound retention on the state too. Even the derived state is behavioural data. An unbounded log of when someone was drowsy is a subject-access problem and, potentially, evidence in a dispute.

Make the indicator honest. If the camera is active, the driver must be able to tell without inspecting a settings screen.

Testing without a face#

adb shell dumpsys car_service --list-properties | grep -i -E 'DRIVER|ATTENTION'
 
# If exposed as a property, inject state to test the UI response
adb shell dumpsys car_service --set-property <id> 2   # e.g. DROWSY

Next#

The other system Android observes but does not control.