許多用戶嚴重依賴他們的手機,並且始終需要工作設備。但是,有時設備最終會進入重啟循環,這會導致用戶提交支持票或保修查詢。這個過程對用戶來說是令人沮喪的,對設備製造商和運營商來說是昂貴的。
Android 8.0 包含一個功能,當它發現核心系統組件陷入崩潰循環時,它會派出“救援隊”。救援方隨後通過一系列行動升級以恢復設備。作為最後的手段,救援方將設備重新啟動到恢復模式並提示用戶執行恢復出廠設置。
Android 兼容性定義文檔不需要這些救援功能,但可能仍有助於減少支持案例。
執行
Rescue Party 在 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
從那裡,您可以觸發系統或 UI 崩潰循環。
要觸發低級system_server
崩潰循環,請運行:
adb shell setprop debug.crash_system 1
要觸發中級 SystemUI 崩潰循環,請運行:
adb shell setprop debug.crash_sysui 1
兩個崩潰循環都會啟動救援邏輯。所有救援操作也會記錄到存儲在/data/system/uiderrors.txt
的持久 PackageManager 日誌中,以供以後檢查和調試。這些持久性日誌也包含在“包警告消息”部分下的每個錯誤報告中。