How to Inspect Application Rollbacks and Recovery States on Android Using ADB dumpsys rollback

In modern Android architecture—spanning modular system updates via Project Mainline APEX containers and standard APK packages—updating system components or user applications carries the risk of regressions, bootloops, or critical crashes. To prevent an unstable application or system update from rendering a mobile handset unusable, Android incorporates the Rollback Manager (RollbackManagerService). When an application or system module is updated with rollback support enabled, Android creates an atomic snapshot of the previous package version alongside its private user data directory. If the updated package subsequently crashes repeatedly during startup or triggers Rescue Party alerts, the system can automatically revert to the prior stable snapshot. Using Android Debug Bridge (ADB) and dumpsys rollback, QA engineers and system developers can audit active rollback sessions, verify snapshot expiration timers, and test disaster recovery procedures.

Architecture of the Android Rollback Manager

The RollbackManagerService coordinates rollback lifecycle events across both application APKs and Mainline APEX modules:

• Rollback Data Snapshots: When an app is upgraded with the --enable-rollback flag, the system creates an isolated backup snapshot of the app’s internal user data directory (/data/user/0/<package>/) under /data/misc/rollback/.
• Rollback Expiration Lifetime: Snapshots are retained for a designated time window (typically 14 days for standard apps, or until the next reboot cycle for staged APEX updates) before being automatically purged by the system to reclaim disk storage.
• Rescue Party Integration: If an updated application or system package crashes during initialization (e.g. 5 crashes within 30 seconds), the Android Rescue Party subsystem intercepts the failure and invokes RollbackManager.commitRollback() to revert the package without requiring user intervention.
• Staged APEX Rollbacks: For low-level operating system modules (such as Media, Conscrypt, or ART runtime), rollbacks are staged at boot time via apexd.

Dumping Rollback Manager State via ADB

Connect your Android device with USB debugging enabled, open your terminal, and query the rollback service:

adb shell dumpsys rollback

The diagnostic dump provides a structured inventory of available rollback packages, active session tokens, committed rollbacks, and filesystem snapshot paths.

Analysing Available Rollback Sessions and Package Versions

In the terminal output, locate the Available rollbacks: block:

Available rollbacks:
  RollbackId: 104
    Packages:
      com.example.analyticsapp 102 -> 101
    Staged: false
    State: available
    Timestamp: 2026-11-06T12:00:00Z
    BackupDir: /data/misc/rollback/104

Key attributes to inspect include:

• RollbackId: An integer token identifying the atomic rollback transaction.
• Version Transition (102 -> 101): Confirms the installed version code (102) and the target recovery version code (101) to which the app will revert if triggered.
• State: Indicates whether the rollback snapshot is active (available), pending execution (committed), or invalid (deleted).
• BackupDir: The secured filesystem directory holding the snapshotted user data and APK/APEX binaries.

Installing Applications with Rollback Support Enabled via ADB

By default, installing an update via standard ADB does not preserve a rollback snapshot. To explicitly enable rollback tracking when updating an APK via ADB, supply the --enable-rollback flag:

# Install updated package with rollback snapshot creation enabled
adb install -r --enable-rollback app-v2-update.apk

After installation, re-run adb shell dumpsys rollback to verify that a new RollbackId entry was successfully created for your package.

Simulating and Executing an Application Rollback via ADB

In automated testing and CI/CD validation pipelines, you can trigger a rollback programmatically without waiting for simulated app crashes:

# Trigger rollback for a specific RollbackId
adb shell cmd rollback commit-rollback 104

Observe the execution sequence in Logcat:

adb logcat -d -s RollbackManager:V PackageManager:V | grep -i rollback

The logs will confirm that the package manager reinstalled version 101, restored the snapshotted user database files, and broadcasted the ACTION_PACKAGE_ENABLE_ROLLBACK intent.

Inspecting Recently Committed Rollback History

Following a rollback event, dumpsys rollback updates its historical audit log:

Recently committed rollbacks:
  RollbackId: 104
    Packages:
      com.example.analyticsapp 102 -> 101
    Timestamp: 2026-11-07T14:45:00Z
    Status: SUCCESS

This allows mobile fleet administrators to confirm whether an application automatically self-healed following an unstable deployment.

Purging Stale Rollback Snapshots to Reclaim Storage

If obsolete rollback data directories consume significant disk space on test devices, you can command the rollback service to expire and clean up outdated snapshots immediately:

# Force expiration of older rollback sessions
adb shell cmd rollback expire-rollbacks

Utilising dumpsys rollback gives mobile engineers comprehensive control to validate application resilience, verify user data preservation, and maintain flawless recovery mechanisms across modern Android releases.