許多用戶嚴重依賴手機，並且需要始終有一個可用的設備。然而，有時設備最終會重新啟動循環，這會導致用戶提交支援請求或保固查詢。這個過程對於使用者來說是令人沮喪的，對於設備製造商和營運商來說也是昂貴的。
Android 8.0 包含一項功能，當它注意到核心系統組件陷入崩潰循環時，它會派出「救援隊」。然後救援隊透過一系列行動逐步升級以恢復設備。作為最後的手段，救援隊會將設備重新啟動到恢復模式，並提示使用者執行恢復出廠設定。
Android 相容性定義文件並不要求這些救援功能，但仍可能有助於減少支援案例。
執行
Android 8.0 預設啟用 Rescue Party，其實作位於/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
從那裡，您可以觸發系統或 UI 崩潰循環。
若要觸發低階system_server崩潰循環，請執行：
adb shell setprop debug.crash_system 1
若要觸發中階 SystemUI 崩潰循環，請執行：
adb shell setprop debug.crash_sysui 1
兩個崩潰循環都會啟動救援邏輯。所有救援操作也會記錄到儲存在/data/system/uiderrors.txt的持久性 PackageManager 日誌中，以便日後檢查和偵錯。這些持久性日誌也包含在「包警告訊息」部分下的每個錯誤報告中。