How software actually reaches a sold vehicle — the difference between updating a head unit and updating a car, the preconditions nobody mentions, and what goes wrong.
Intermediate8 minOTA · Delivery · Regulation
is the mechanism the whole software-defined vehicle idea rests on. If
you cannot change software after the sale, nothing else in this section matters.
You already know Android's update mechanism. What is worth understanding is
everything around it, because updating a head unit and updating a vehicle are
different problems.
An update does not simply arrive. A long list of conditions must hold first, and
most real-world OTA frustration comes from these rather than from the download.
Condition
Why
Parked
You cannot reboot an ECU at 100 km/h
Not about to be driven
An interrupted install is the worst case
Sufficient battery
A flash that browns out mid-write can brick an ECU
Charging, for large updates
On an EV, a big flash is a real energy draw
Connectivity
Cellular data costs money and coverage is uneven
User consent
Legally required in most markets, and expected everywhere
Android's approach is the right mental model, and the wider
vehicle uses the same idea where it can.
┌─────────── slot A (running) ───────────┐ │ system, vendor, product │ ← in use, untouched └────────────────────────────────────────┘ ┌─────────── slot B (idle) ──────────────┐ │ new image written here while driving │ ← written in the background └────────────────────────────────────────┘ │ reboot into B │ ┌───────────┴────────────┐ │ boots and marks good? │ └───────┬────────────┬───┘ yes no │ │ B becomes active fall back to A automatically
Gotcha
A/B costs storage — roughly double for the partitions it covers. On a
cost-sensitive programme this is a real argument, and some ECUs deep in the
vehicle do not get A/B for that reason.
Those are the ones where a failed update is unrecoverable without a workshop
visit, and they are exactly why full-vehicle OTA is treated so much more
cautiously than infotainment OTA.
Install success rate is a seductive and insufficient metric. An update can
install perfectly and still be a failure: battery drain, a fault light, a feature
that no longer works in cold weather.
Rollout gates should include fault-code rates, customer contact volume, and
feature-level telemetry — not just "did the flash complete".
Assume your code will be replaced. Design for it. Persistent state must
survive an update, and must tolerate being read by a newer version.
Assume the versions around you will differ. During a staged rollout, your app
may run against an older VHAL or an older vehicle service. Handle absent
properties and unknown values rather than assuming a matched set.
Keep the update path small. Anything that shrinks the image — shared
libraries, avoiding duplicated assets, delta-friendly layouts — is cellular data
the customer does not pay for and install time they do not wait through.
Never assume connectivity. Features that break without a network will break,
and in a car that is a common state rather than an edge case.
Test the upgrade, not just the install. The interesting bugs are in migration
from the previous version with real accumulated state — not in a clean flash.
