다수의 사용자가 휴대전화에 크게 의존하며, 기기가 항상 작동 상태를 유지해야 합니다. 하지만 간혹 기기의 재부팅이 반복되어 사용자가 지원 티켓을 제출하거나 보증을 문의하는 원인이 될 수 있습니다. 이러한 과정은 사용자가 답답하게 느낄 수 있으며 기기 제조업체와 이동통신사에는 높은 비용을 초래합니다.
Android 8.0에는 핵심 시스템 구성요소가 반복적인 충돌을 경험할 때 이를 확인하여 '레스큐 파티'를 전송하는 기능이 포함됩니다. 그러면 레스큐 파티는 기기 복구를 위한 일련의 작업을 통해 에스컬레이션됩니다. 최후의 수단으로 레스큐 파티는 기기를 복구 모드로 재부팅한 다음 사용자에게 초기화를 실행하도록 안내합니다.
이러한 구조 기능은 Android 호환성 정의 문서의 요구사항이 아니지만 지원 기록을 줄이는 데 도움이 될 수 있습니다.
구현
레스큐 파티는 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 로그에도 로깅됩니다.
이러한 영구 로그는 '패키지 경고 메시지' 섹션의 모든 버그 신고에도 포함됩니다.