Many users heavily depend on their phones and require a working device at all time. 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 includes a feature that sends out a "rescue party" when it notices core system components stuck in crash loops. Rescue Party then 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.
These rescue features are not required by the Android Compatibility Definition Document, but may still be useful to reduce support cases.
Implementation
Rescue Party is enabled by default in Android 8.0, 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 5 times in 5 minutes.
- A persistent system app crashes more than 5 times in 30 seconds.
When one of these situations is detected, Rescue Party 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.
No special hardware support is required to support Rescue Party. If implemented,
a device's recovery system must respond to the
--prompt_and_wipe_data command and devices must
surface 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 5 minutes before a device is operable again, device manufacturers should not 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
All rescue events are suppressed 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, you can trigger a system or UI crash loop.
To trigger a low-level system_server crash loop, run:
adb shell setprop debug.crash_system 1
To trigger a mid-level SystemUI crash loop, run:
adb shell setprop debug.crash_sysui 1
Both crash loops initiate the rescue logic. All rescue operations are also
logged to the persistent PackageManager logs stored at
/data/system/uiderrors.txt for later inspection and debugging.
These persistent logs are also included in every bug report under the "Package
warning messages" section.