Skip to content

Cluster, Camera & Displays

ADAS integration

Lane keeping, adaptive cruise and emergency braking run on their own safety-rated hardware. What Android receives, what it must never do, and how to display a system you do not control.

Advanced6 minADAS · Safety · Cluster

covers everything from a lane departure warning to automatic emergency braking. It is the most safety-critical software in the vehicle, and Android's relationship to it is narrower than most people assume.

Android's role, stated plainly#

Why the separation is absolute#

Three independent reasons, any one of which would be sufficient:

Safety rating. ADAS functions carry an rating — often C or D. Demonstrating that level of integrity requires determinism, bounded timing and tool qualification that a general-purpose operating system with a garbage collector cannot provide.

Timing. An emergency braking decision has a latency budget measured in milliseconds. A Binder round trip through a framework that might be garbage collecting is not an acceptable link in that chain.

Availability. The function must work when Android is rebooting, updating, or crashed.

What Android receives#

State, usually as vehicle properties or a vendor interface:

InformationTypical form
Is adaptive cruise engaged?A state enum
What is the set speed?A number
Following distance settingAn enum: 1–4 bars
Lane keeping statusAvailable / active / unavailable
Detected lane markingsSimplified geometry, for the cluster
Detected vehicles aheadPosition and classification, for display
Why is a feature unavailable?A reason code

Displaying something you do not control#

Age out the state rather than holding it
private var lastUpdateNanos = 0L
 
fun onAdasState(state: AdasState) {
    lastUpdateNanos = SystemClock.elapsedRealtimeNanos()
    render(state)
}
 
// On the render tick
fun tick() {
    val ageMs = (SystemClock.elapsedRealtimeNanos() - lastUpdateNanos) / 1_000_000
    when {
        ageMs < 200  -> { /* current — draw normally */ }
        ageMs < 1000 -> renderDegraded()      // visibly less confident
        else         -> renderUnavailable()   // stop claiming anything
    }
}

The handover problem#

Some ADAS features hand control back to the driver: adaptive cruise disengaging, lane centring reaching its limit.

Settings that Android does own#

Where Android legitimately participates is configuration, not operation.

A setting write, like any other vehicle property
properties.setIntProperty(
    VendorProperties.ADAS_FOLLOWING_DISTANCE, GLOBAL, 3,
)

Even here, the ADAS module decides whether to accept the change, and may refuse — because the vehicle is moving, because the feature is currently unavailable, because a safety condition is not met.

Debugging across the boundary#

What Android can see
adb shell dumpsys car_service --list-properties | grep -i -E 'ADAS|CRUISE|LANE'
adb shell lshal | grep -i adas
adb logcat -b all | grep -i adas

What to push back on#

Requirements that arrive on Android and belong elsewhere:

  • "The head unit shall warn the driver of an imminent collision."
  • "The infotainment system shall disable lane keeping when the driver requests."
  • "Android shall guarantee the ADAS indicator is displayed within 100 ms."
  • Anything giving Android an availability figure it cannot meet.

Next#

The connectivity module — starting with the key in the driver's pocket.

References & further reading

Code links target the main branch on cs.android.com. AOSP moves — if a path 404s, search the symbol instead.