How to Inspect Recovery System Services and Resume on Reboot on Android Using ADB dumpsys recovery

Android Recovery Architecture and the Resume-on-Reboot (RoR) Framework

In modern Android architecture, seamless over-the-air (OTA) operating system updates are essential for maintaining security patch compliance and delivering platform enhancements. However, file-based encryption (FBE) historically introduced a major operational obstacle for unattended night-time updates: after an OTA update applies and the device reboots, user data partitions remain locked in Direct Boot mode. Until the user manually enters their lock screen PIN, pattern, or password, Credential Encrypted (CE) storage cannot be unlocked, preventing background alarms, corporate MDM syncing, and messaging services from functioning.

To overcome this friction, Android 11 (API level 30) and later releases introduced the Resume-on-Reboot (RoR) framework, managed by RecoverySystemService. When an authorized system client (such as Google Play Services or an enterprise Device Policy Controller) schedules an unattended OTA reboot, RecoverySystemService coordinates with hardware security modules (such as Keymint or StrongBox) to securely encrypt the user’s synthetic lockscreen password with an ephemeral key. Upon reboot, the hardware Keystore verifies the device’s authenticated boot state and automatically unlocks CE storage without requiring manual user PIN entry.

Beyond Resume-on-Reboot, RecoverySystemService communicates directly with the Bootloader Control Block (BCB) and recovery partition, orchestrating factory data wipes, recovery mode reboots, and enterprise wipe confirmations. Through the Android Debug Bridge (ADB), engineers and security auditors can inspect active recovery service states, verify RoR hardware support, and audit reboot preparation records using dumpsys recovery.

Establishing an ADB Session and Verifying Service Availability

To inspect the recovery subsystem, connect your target Android smartphone or tablet via USB or Wireless ADB, and ensure USB debugging is authorised:

# Verify device connectivity
adb devices -l

# Check that recovery system service is registered and responsive
adb shell service check recovery

If the service is operational, the output confirms Service recovery: found. You can now execute diagnostic dumps against the recovery subsystem.

Dumping Recovery Service Telemetry via dumpsys recovery

Executing dumpsys recovery queries RecoverySystemService directly, outputting runtime parameters, active client preparation states, and Resume-on-Reboot readiness:

# Dump complete RecoverySystemService diagnostic state
adb shell dumpsys recovery

A typical diagnostic dump reveals essential hardware and operational metrics:

RecoverySystemService:
  mContext: android.app.ContextImpl@...
  mIsResumeOnRebootSupported: true
  mNeedRebootEscrow: false
  mRebootEscrowReady: false
  mRebootEscrowListener: null
  mUnattendedRebootPrepared: false
  mLastPreparedForUnattendedRebootPackage: null
  mPrepareForUnattendedRebootTime: 0
  mRebootEscrowProvider: com.android.server.recoverysystem.RebootEscrowProviderKeyStoreProvider

Understanding Recovery Telemetry Attributes

Each property in the dump reflects a vital phase in the OTA update and reboot lifecycle:

• mIsResumeOnRebootSupported: A boolean flag indicating whether the device chipset, hardware HAL, and bootloader support Resume-on-Reboot. Devices lacking hardware-backed keystore integration or compliant Keymint HALs will report false.
• mNeedRebootEscrow: Indicates whether an active OTA update process has requested cryptographic key escrow prior to reboot.
• mRebootEscrowReady: Confirms that synthetic lockscreen credentials have been successfully encrypted, verified, and loaded into hardware-backed escrow storage. When true, the device is prepared to reboot and automatically unlock CE storage.
• mUnattendedRebootPrepared: Indicates whether the system has satisfied all prerequisites for an unattended overnight reboot.
• mLastPreparedForUnattendedRebootPackage: Identifies the package name of the system updater client (e.g. com.google.android.gms) that initiated the RoR preparation workflow.
• mRebootEscrowProvider: Identifies the cryptographic provider backing escrow storage—typically RebootEscrowProviderKeyStoreProvider or RebootEscrowProviderServerBasedImpl.

Auditing Hardware Escrow Support and System Properties

Resume-on-Reboot relies on specific Android system properties to determine hardware provider types and network timeout windows. Query these parameters using getprop:

# Check RoR hardware provider implementation
adb shell getprop ro.boot.reboot_escrow

# Check if unattended update reboot is enabled by vendor
adb shell getprop ro.config.auto_reboot_after_update

If ro.boot.reboot_escrow returns a hardware address or provider identifier, the device utilizes dedicated hardware-backed Keymint escrow.

Testing Recovery and BCB Communication via ADB

Developers working on custom ROMs, enterprise kiosk devices, or automotive head units often need to test recovery commands and bootloader communication without manual hardware button combos.

To reboot the device directly into the stock recovery environment:

# Initiate standard recovery mode reboot
adb reboot recovery

To test bootloader control block (BCB) message passing or clear pending update flags from the recovery partition:

# Check bootloader communication commands
adb shell cmd recovery help

Security engineers audit dumpsys recovery following an OTA upgrade to confirm that escrow keys are wiped from RAM immediately upon CE storage unlock, preventing residual credential recovery attacks.

Leveraging dumpsys recovery provides comprehensive visibility into modern Android unattended update mechanics, hardware-backed credential escrow, and platform recovery reliability.