Rescue Party

Users depend on their phones and require a working device at all times. However, sometimes devices end up in reboot loops, which cause users to file support tickets or warranty inquiries. This process is frustrating for users and expensive for device manufacturers and carriers.

Android 8.0 (API level 26) and higher includes a feature that triggers a rescue process when it detects core system components stuck in crash loops. At this signal, the Rescue Party feature escalates through a series of actions to recover the device. As a last resort, Rescue Party reboots the device into recovery mode and prompts the user to perform a factory reset.

Implementation

Rescue Party is enabled by default and the implementation lives in /services/core/java/com/android/server/RescueParty.java. Rescue Party receives information about boot and crash events and starts if:

• The system_server restarts more than five times in five minutes.
• A persistent system app crashes more than five times in 30 seconds.

When Rescue Party detects one of these situations, it escalates to the next rescue level, processes the task associated with that level, and lets the device proceed to see if it recovers. Each level is progressively more aggressive in what it clears or resets. The final level prompts the user to factory reset the device.

Rescue Party doesn't require special hardware support. If implemented, a device's recovery system must respond to the --prompt_and_wipe_data command and devices must provide a way for users to confirm any destruction of user data before proceeding. The recovery system should also give the user the option of attempting to boot their device again.

Because each rescue level can add up to five minutes before a device is operable again, device manufacturers shouldn't add custom rescue levels. Increased time with an inoperable device makes users more likely to initiate a support or warranty inquiry instead of self-recovering their device.

Validation

Rescue Party suppresses all rescue events when the device has an active USB data connection because that's a strong signal that someone is debugging the device.

To override this suppression, run:

adb shell setprop persist.sys.enable_rescue 1

From there, trigger a system or UI crash loop:

• To trigger a low-level system_server crash loop, run:

  adb shell setprop debug.crash_system 1
  adb shell stop
  adb shell start

• To trigger a mid-level SystemUI crash loop, run:

  adb shell setprop debug.crash_sysui 1

Both crash loops initiate the rescue logic. Rescue Party also logs all rescue operations to the persistent PackageManager logs stored at /data/system/uiderrors.txt for later inspection and debugging. Bug reports also include these persistent logs under the Package warning messages section.