사용자는 휴대전화에 크게 의존하며, 기기가 항상 작동 상태를 유지해야 합니다. 하지만 간혹 기기의 재부팅이 반복되어 사용자가 지원 티켓을 제출하거나 보증을 문의하는 원인이 될 수 있습니다. 이 과정은 사용자에게 답답함을 주고 기기 제조업체와 이동통신사에는 높은 비용을 초래합니다.
Android 8.0 (API 수준 26) 이상에는 비정상 종료 루프에서 중단된 핵심 시스템 구성요소를 감지할 때 복구 프로세스를 트리거하는 기능이 포함되어 있습니다. 이 신호가 수신되면 레스큐 파티 기능은 일련의 작업을 통해 에스컬레이션하여 기기를 복구합니다. 최후의 수단으로 레스큐 파티는 기기를 복구 모드로 재부팅한 다음 사용자에게 초기화를 실행하도록 안내합니다.
구현
레스큐 파티는 기본적으로 사용 설정되어 있으며 구현은 /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 1adb shell stopadb shell start중간 수준 SystemUI 충돌 루프를 트리거하려면 다음을 실행합니다.
adb shell setprop debug.crash_sysui 1
두 장애 루프가 모두 구조 논리를 시작합니다. 구조 파티는 향후 검사 및 디버깅을 위해 /data/system/uiderrors.txt에 저장되는 영구적인 PackageManager 로그에도 모든 구조 작업을 로깅합니다. 버그 신고에는 이러한 영구 로그가 패키지 경고 메시지 섹션에 포함되어 있습니다.