許多使用者非常依賴手機，並且完全需要實用的裝置 讓應用程式從可以最快做出回應的位置 回應使用者要求然而，裝置有時會反覆不斷地重新啟動，導致使用者 提交支援單或保固問題。這項程序相當困擾 對裝置製造商和電信業者來說 費用十分高昂
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
這兩個當機迴圈都會啟動救援邏輯。所有救援行動
會記錄到儲存位置的永久 PackageManager 記錄檔
/data/system/uiderrors.txt，用於後續的檢查及偵錯。
這些持續性記錄也會包含在「套件」下的每份錯誤報告中
警告訊息」專區。