OTA updates & rollback analysis

Investigate slots, snapshots, boot success, and update failure using evidence.

10 min readChapter 44 of 50Advanced
In this chapter

An update is a state transition, not simply “copy new system files.” This lesson teaches you to reason about A/B and Virtual A/B from a synthetic evidence packet. It does not ask you to install an OTA, change a slot, or run a destructive recovery command.

Before you start#

Required earlier lessons: Boot & partitions, Verified Boot & encryption, and Debug, test & contribute. Review Root, Recovery, and a Safe Android Lab if the difference between user-data reset and image restoration is unclear. No device or Android build is needed.

Learning goals#

You will distinguish legacy A/B partition updates from Virtual A/B snapshots, describe update_engine’s role at a high level, reason about snapshot merge and boot success/rollback, and label synthetic evidence without claiming it came from a real run.

Practice#

Apply, boot, confirm, merge
  1. Apply accepted payload

    update_engine coordinates writes; snapshots/COW represent dynamic-partition changes.

  2. Select candidate boot slot

    Boot-critical physical partitions use slots; selection is not a successful boot.

  3. Boot and health confirmation

    Candidate must reach the product’s success condition.

  4. Snapshot merge / finalization

    Merge changes into the base after success; pending and complete are different states.

Conceptual model. A simplified successful Virtual A/B path, not the failure packet below. Dynamic changes use snapshots/COW rather than a complete second dynamic-partition copy; policy is device-specific.

In classic A/B updates, the device boots one slot while update_engine applies an update to the other slot. After a successful update, boot control marks the new slot active; the bootloader tries it. The old slot can provide a fallback if the new one does not become successful under the device’s boot-control policy. Exact partition sets and policy are device-specific. See AOSP’s legacy A/B update overview and Android 14 update_engine source.

Virtual A/B reduces the need to keep full duplicate copies of dynamic partitions: boot-critical physical partitions use slots, while dynamic-partition changes are represented by snapshots/COW data; after successful boot confirmation, the device merges snapshot changes into the base. snapuserd and snapshot-management components participate in supported configurations. AOSP’s Virtual A/B overview and implementation guidance describe these phases. The overview states that Virtual A/B updates roll back to the previous version if the new OS fails to boot; the exact flow before merge completion is device-specific, and you should not assume every failure, phase, or OEM configuration behaves identically.

The update_engine service consumes an OTA payload and coordinates update operations; boot control tracks slot state and bootability. Android 14’s IBootControl interface separately exposes bootable/successful state and active-slot operations (pinned AIDL). Verified Boot checks integrity/authenticity policy for booted images. Rollback indices reject disallowed older software; they are not the same thing as the automatic fallback to an alternate slot (Verified Boot). AOSP documents user-data checkpointing as a separate topic (not retrieved in this review), and it may also participate in update rollback. Keep these mechanisms distinct: update application, slot selection, snapshot merge, verified boot, and anti-rollback answer different questions.

Static evidence packet — synthetic, not executed

Fallback before snapshot merge

Synthetic teaching data, not a device capture.

  1. Start on _a; apply target _b

    The supplied payload check passes and update application completes.

  2. Try _b

    No recorded health mark; the packet records two attempts.

  3. Fallback: _a active, _b unbootable

    The candidate did not reach the recorded success state. Cause remains unknown.

  4. Merge not started

    Rollback index is reported unchanged; that does not mean anti-rollback was disabled.

Synthetic teaching data. Interpretation of the fictional packet only. Fallback to a prior slot is not cryptographic anti-rollback. No startup root cause or general recovery action is established.

The following packet is invented for practice. It is deliberately labeled SYNTHETIC; do not cite it as a device log, AOSP test result, or real execution. In the Virtual A/B profile, _b denotes the boot-critical target slot; dynamic partitions use snapshot/COW state rather than a second full dynamic-partition slot, as described in the AOSP Virtual A/B overview.

text
SYNTHETIC DEVICE PROFILE
  Design: Virtual A/B; current slot _a; target slot _b
  Snapshot state: created; merge state: none

SYNTHETIC UPDATE RECORD
  payload verification: PASS
  update_engine apply: completed
  boot-control active slot after reboot: _b
  post-boot health mark: absent
  boot attempts recorded for _b: 2
  boot-control state after second failed attempt: _a active, _b unbootable
  snapshot merge: not started
  rollback-index value reported: unchanged
  user-data checkpoint: not reported

Task: write a four-step timeline, one strongest supported conclusion, two things the packet does not establish, and the next safe evidence you would request. A plausible conclusion is that the update payload was applied and the new slot was selected, but the new slot did not reach the recorded success/health mark; boot control then selected the prior slot, while merge had not begun. This is a rollback-to-old-slot interpretation, not proof that update_engine itself was defective.

Alternative hypotheses include a boot failure in the new image, a missing/late health confirmation, or a boot-control policy/event not represented in the short packet. Payload verification passing says nothing about successful framework startup. “Rollback-index unchanged” does not prove that anti-rollback was disabled or that every image version is acceptable. The packet provides no boot logs, exact build identities, health-service evidence, or OEM policy. Request those before assigning root cause.

Evidence discipline

For an actual authorized lab, record the source revision, device type, current/target slot, update phase, boot success state, relevant update_engine and boot-control evidence, and whether a Virtual A/B snapshot merge began/completed. Do not use an undocumented shell command to force slot changes. In this lesson, your artifact must say synthetic exercise; no runtime update performed.

Read the state as a sequence, not a single status

The synthetic packet is intentionally incomplete. An update investigator first reconstructs ordered state transitions, then asks which component owns each transition. A useful conceptual sequence is:

  1. Package accepted: payload metadata/signatures and compatibility checks are considered. A “verified” package is not yet a booted system.
  2. Update applied: update_engine processes operations from the payload. In classic A/B, writes target partitions in the inactive slot; Virtual A/B also maintains snapshot/COW state for changed logical partitions.
  3. Boot target selected: boot control records which slot to try. A reboot into that slot is evidence of selection, not successful startup.
  4. Boot and health confirmation: early boot, Verified Boot, init, framework, and device-specific health reporting determine whether the candidate reaches its success condition. A failure may consume retries or trigger fallback; exact policy depends on implementation.
  5. Snapshot merge / finalization: on Virtual A/B, changes represented by snapshots are merged after the system is running and considered successful. A “merge pending” state differs from both “not started” and “complete.”

These boundaries help avoid false diagnoses. For example, an error before payload application suggests a different path than a boot loop after slot switch. A new slot that boots but never reaches a health mark suggests incomplete startup/confirmation rather than necessarily a bad payload. A merge error occurs after a later phase than payload verification. A bootloader rejection can implicate verified state or rollback policy; it is not interchangeable with an update_engine payload-application error.

When reading source, keep the owners distinct. The system/update_engine tree contains the update client/service implementation and payload processing. The system/core/fs_mgr/libsnapshot tree covers snapshot management and merge-related mechanisms used by Virtual A/B. Boot-control behavior is mediated through platform interfaces and device integration; the bootloader and product implementation may not be fully present in public AOSP. These trees are maps for source navigation, not complete descriptions of every product. Pin each path to the same release tag before comparing it with a log from a different build.

Also distinguish payload verification from Verified Boot. An OTA package can be validated for update application, while the bootloader later makes a separate trust decision about the images it loads. The word “verified” in a report must be tied to the exact component and check. Ask: verified which bytes, using what metadata/key, at what stage, for which target? A log line saying one verification succeeded is not a universal authenticity statement.

What evidence would discriminate the hypotheses?

Suppose two plausible explanations are “the new image failed during startup” and “the system started but the success mark was not recorded.” Request evidence that distinguishes them: boot attempt/reason and boot logs for the new slot; framework/system-server startup or health service evidence; timestamps tying the health mark to the attempted boot; and exact target build fingerprints for both slots. If the event occurs after successful boot but during merge, request snapshot/merge progress and storage-space evidence. These are requests for authorized logs or source inspection—not instructions to change slot metadata.

Likewise, “the rollback index was unchanged” is not enough to diagnose a rollback-protection failure. To reason about anti-rollback, one needs the relevant verified metadata/index values, the bootloader’s reported decision, and the device’s stored minimum-index state where available. These details may be unavailable in a generic emulator or public source tree. Report the boundary as unknown rather than guessing or asking the learner to inspect protected device state.

Contrast cases (reasoning only)

Use these as counterexamples when checking your timeline:

  • Payload fails before slot switch: the current slot may remain active; there is no evidence that the candidate image was booted. Do not call this a boot rollback.
  • Candidate boots and is marked successful, merge remains pending: the new system may be operating while storage finalization continues. Do not infer that merge completed merely from a successful boot.
  • Candidate is rejected by verification or rollback policy: boot selection may return to the old slot, but the decisive failure is in the trust/acceptance path, not necessarily application health.
  • Device disconnected during observation: the state is unknown. A missing log is not proof that update_engine or boot control did nothing.

For every case, the learner should identify what event is known, what subsystem could own the next transition, and what evidence is missing. This is deliberately an analysis exercise rather than a command recipe: a wrong slot or incomplete merge state can affect bootability and data, so no universal manual recovery action belongs in this lab.

Knowledge check#

  1. What is the difference between booting the new slot and marking it successful?
  2. In Virtual A/B, why is snapshot merge a distinct phase after first boot?
  3. Does automatic slot fallback mean rollback indices are irrelevant?
  4. The synthetic packet says payload verification: PASS. What does that prove, and what does it not prove?

Answers#

  1. Boot selection chooses which image to try. A successful-health confirmation tells boot control the new system has reached the point required by policy; without it, attempts may be exhausted and the old slot selected.
  2. The updated view can initially include snapshot/COW data. Merge later incorporates changes into base storage and has its own progress and failure/revert considerations.
  3. No. Slot fallback is an update/boot recovery path; rollback indices are a separate anti-downgrade policy applied to accepted images.
  4. It establishes only that the payload verification stage recorded success in this synthetic record. It does not prove the new OS boots, passes health checks, merges snapshots, or works on hardware.

Checkpoint#

Pass when the timeline keeps payload application, slot selection, health confirmation, and merge separate; your conclusion cites only packet fields; and the artifact explicitly labels the packet synthetic. Revise if you say that a passing payload proves a successful boot or that rollback index and A/B fallback are one mechanism. Not yet evidenced is required for real-device behavior because no device was updated.

If slot terminology is unclear, revisit Boot & partitions. For integrity versus downgrade policy, revisit Verified Boot & encryption. For safe lab boundaries, revisit Root, Recovery, and a Safe Android Lab.

Sources#

A little further beneath the surface.

Check your understanding with the checkpoint. Marking a chapter as read saves a bookmark, not a proficiency assessment.