多くのユーザーはスマートフォンに大きく依存しており、デバイスが恒常的に動作することを求めています。しかし、デバイスが再起動ループに陥り、ユーザーがサポート チケットを送信したり、保証について問い合わせたりする原因になることがあります。このプロセスはユーザーにとってはわずらわしく、デバイス メーカーや携帯通信会社にとっては負担になります。
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
中レベルのシステム UI クラッシュ ループをトリガーするには、次のコマンドを実行します。
adb shell setprop debug.crash_sysui 1
どちらのクラッシュ ループでも、レスキュー ロジックが開始されます。また、すべてのレスキュー オペレーションは、後で調査とデバッグを行うために、/data/system/uiderrors.txt に保存される永続的な PackageManager ログに記録されます。これらの永続ログは、すべてのバグレポートの [Package warning messages] セクションにも含まれています。