Choosing when to commit an Android SDV update

The VM boots. Does the feature work?

Suppose a vehicle update changes a service that supplies information to the cockpit. The updated VM boots, but another service can no longer interpret its responses. Calling the update complete at this point would confuse a working boot image with a working feature.

This is an illustrative integration failure, not a reported vehicle defect. Android's SDV Update Manager provides a useful place to examine it: the documented process separates preparation, activation and commitment. The system integrator still supplies the client that coordinates the vehicle update. [1]

My recommendation is to make that client own an explicit commit decision. Before making a supported update permanent, it should obtain the agreed evidence for the affected service dependencies. A screen returning after reboot is useful evidence about that screen. It does not establish that the updated service and its consumers still agree.

Start with the update type

AAOS SDV Core is an Android-based environment for native services. The integration guide distinguishes it from the JVM-based application environment and describes communication between instances. It should not be read as a description of every production infotainment system. [2]

The Update Manager supports system updates and service-bundle updates. A system update uses the inactive system slot; a service-bundle update stages APEX packages. Both require activation across a reboot in the documented workflow, but the payload and completion operations differ. [1]

For a release review, name the unit you are changing. A system image, a service bundle and an external controller's firmware are not interchangeable. The last of these needs its own evidence and update contract; this documentation does not establish its recovery behavior.

A successful activation leaves a decision outstanding

In the documented manager, PREPARE stages the payload. ACTIVATE makes it take effect after reboot. After successful post-reboot verification, ACTIVATE_POST_REBOOT_COMPLETE waits for the client to choose Commit or Rollback. The reported percentage and the manager's state are separate status information. [1]

In the example, the client needs to know which service revision it is evaluating, which consumers must communicate with it and what evidence counts as a pass. A response from one endpoint may establish reachability while leaving a changed data meaning untested. A compatibility probe should exercise the changed contract, not just establish that a process is alive.

Consider a proposed service revision that changes a numeric response from degrees Celsius to tenths of a degree without changing its field name or type. At 22 degrees, the service now returns 220. An updated consumer converts it to 22; an older consumer treats it as 220. Both may parse the response and report a healthy connection. This deliberately incompatible, hypothetical change shows why a reachability check is insufficient; adding a field alone would not establish such a failure.

For this example, the acceptance probe must check the interpreted value at each affected consumer. A result of 220 at the old consumer fails the agreed contract even when the service and VM remain available. The integrator can preserve the old unit, introduce an explicitly versioned contract, or coordinate the consumer updates. The manager does not select or validate those product decisions.

The SDV system-update guidance makes the same boundary explicit at network level: correctly updating a single system does not guarantee communication across the participating systems. It calls for coordinated deployment or changes that preserve compatibility. [3]

Compare the evidence before committing

The following decisions are proposed review outcomes, not results from a VM or vehicle test.

This distinction also changes the user-facing message. After preparation, “Ready to restart” may fit the product. During acceptance checks, a completion message would be premature. The exact wording depends on whether the user is allowed to interact at that stage, which this platform document does not decide.

Rollback has a scope and an end

The manager documents a user-data checkpoint around activation. Commit makes the supported update permanent and commits the checkpoint; rollback follows different paths depending on the current state and can require a further reboot. System and service-bundle updates also have different sources for their boot-attempt limits. [1]

Do not turn this into an unlimited undo promise. In particular, do not infer that a change sent to a remote controller, another VM or a cloud service is covered by this VM's checkpoint. List those effects separately. If accepting the update depends on reversing one of them, the release needs an explicit recovery mechanism for that effect.

Nor should the client wait forever for an unbounded set of checks. Define the affected dependencies, the evidence deadline and the failure path before starting. Testing that path matters as much as testing a successful commit: a rejected dependency should leave the operator with a known state, not just a progress screen that stopped changing.

Do not substitute a phone's partition diagram

The SDV system-update guide retrieved on 12 October 2026 describes a non-virtual A/B configuration. This is the documented configuration, not a claim about every OEM build. Android's Virtual A/B overview describes snapshots for dynamic partitions and a later merge, rather than a second physical copy of every dynamic partition. These descriptions belong to different configurations. [3][4]

For this case, the useful conclusion is narrow: identify the target's update mechanism and preserve the distinction between activation and commitment. A familiar Android version number is insufficient evidence for the partition layout, rollback scope or vehicle-wide coordination in a particular build.

The owner of the release should be able to point to the evidence that justified Commit, the components that evidence covered and the recovery path exercised before release. That is a more useful acceptance record than a screenshot of 100 percent.