我的第一篇博客就是在分析一个手机循环重启的问题，恰巧是system_server崩溃导致的循环重启，可惜的是系统版本是Android N，如果是Android O就会有很好的办法解决这个问题，连续的循环重启使的用户无法到达恢复出厂设置模式。现在Android O加入了救援程序来解决这种由于常驻进程崩溃导致的重启问题。救援程序会通过一系列操作来上报相关情况，以期恢复设备。最后的解决方法是，救援程序使设备重新启动并进入恢复模式，然后提示用户恢复出厂设置。
在 Android 8.0 中，救援程序默认处于启用状态，其实现位于 /services/core/java/com/android/server/RescueParty.java 中。 在出现以下情况时，救援程序会收到有关启动和崩溃事件的信息，然后即会启动：
- system_server 在 5 分钟内重启 5 次以上。
- 永久性系统应用在 30 秒内崩溃 5 次以上。
当检测到上述某种情况时，救援程序会将其上报给下一救援级别、处理与该级别相关联的任务，并让设备继续运行，看看能否恢复。清除或重置内容的程度随级别而增加。最高级别会提示用户将设备恢复出厂设置。
要支持救援程序，无需特别的硬件支持。实现后，设备的恢复系统必须响应 --prompt_and_wipe_data 命令，且设备必须先提供一种方法，让用户确认用户数据是否有任何损坏，然后再继续运行。此外，恢复系统还应为用户提供有关尝试再次启动设备的选项。
由于每个救援级别都会使设备再次变为可运行状态的时间延后（可能长达 5 分钟），因此设备制造商不应添加自定义救援级别。设备处于不可运行的状态的时间越长，用户发出支持请求或保修咨询，而不是自行恢复其设备的可能性就越大。
验证
当设备具有有效的 USB 数据连接时，系统会停止所有救援事件，因为这是一个较强的信号，表示有人正在调试设备。
要停止此类抑制行为，请运行：
adb shell setprop persist.sys.enable_rescue 1
在此处，您可以触发系统或界面崩溃循环。
要触发低级 system_server 崩溃循环，请运行：
adb shell setprop debug.crash_system 1
要触发中级 SystemUI 崩溃循环，请运行：
adb shell setprop debug.crash_sysui 1
这两个崩溃循环都会启动救援逻辑。所有的救援操作也都会记录到存储在 /data/system/uiderrors.txt 中的永久性的 PackageManager 日志中，以供日后进行检查和调试。 此外，“软件包警告消息”部分下的每个错误报告中也会包含这些永久性的日志。
我很有幸分析过一个常驻进程崩溃导致手机进入救援程序并提示用户选择恢复出厂设置的bug
进入救援程序的bug现象非常明显，手机黑屏弹出选项菜单，只能选择恢复出厂设置。
adb logcat -v threadtime | tee log1.txt | grep " events for UID"
以上命令就可以输出崩溃的进程uid,由此追查下去就能知道是哪里出现了崩溃，分析出Root cause。