Rescue Party

Nutzer sind auf ihre Smartphones angewiesen und benötigen jederzeit ein funktionierendes Gerät. Manchmal kommt es jedoch zu Neustartschleifen, die dazu führen, dass Nutzer Supportanfragen oder Garantieanträge stellen. Dieser Prozess ist für Nutzer frustrierend und für Gerätehersteller und Mobilfunkanbieter teuer.

In Android 8.0 (API-Ebene 26) und höher ist eine Funktion enthalten, die einen Rettungsprozess auslöst, wenn erkannt wird, dass wichtige Systemkomponenten in Absturzschleifen hängen bleiben. Bei diesem Signal eskaliert die Rescue Party-Funktion durch eine Reihe von Aktionen, um das Gerät wiederherzustellen. Als letzten Ausweg startet Rescue Party das Gerät im Wiederherstellungsmodus neu und fordert den Nutzer auf, das Gerät auf die Werkseinstellungen zurückzusetzen.

Implementierung

„Rescue Party“ ist standardmäßig aktiviert und die Implementierung befindet sich in /services/core/java/com/android/server/RescueParty.java. Rescue Party erhält Informationen zu Boot- und Absturzereignissen und wird gestartet, wenn:

  • Das system_server wird innerhalb von fünf Minuten mehr als fünfmal neu gestartet.
  • Eine dauerhaft aktive System-App stürzt innerhalb von 30 Sekunden mehr als fünfmal ab.

Wenn Rescue Party eine dieser Situationen erkennt, wird die nächste Rettungsebene erreicht, die mit dieser Ebene verknüpfte Aufgabe wird ausgeführt und das Gerät kann fortfahren, um zu sehen, ob es sich erholt. Jede Stufe ist aggressiver in Bezug darauf, was gelöscht oder zurückgesetzt wird. Auf der letzten Stufe wird der Nutzer aufgefordert, das Gerät auf die Werkseinstellungen zurückzusetzen.

Für Rescue Party ist keine spezielle Hardwareunterstützung erforderlich. Wenn das Wiederherstellungssystem eines Geräts implementiert ist, muss es auf den Befehl --prompt_and_wipe_data reagieren. Außerdem müssen Geräte Nutzern die Möglichkeit bieten, die Vernichtung von Nutzerdaten zu bestätigen, bevor sie fortfahren. Das Wiederherstellungssystem sollte dem Nutzer auch die Möglichkeit bieten, das Gerät noch einmal zu starten.

Da jede Rettungsebene bis zu fünf Minuten dauern kann, bis ein Gerät wieder betriebsbereit ist, sollten Gerätehersteller keine benutzerdefinierten Rettungsebenen hinzufügen. Wenn ein Gerät länger nicht funktioniert, ist es wahrscheinlicher, dass Nutzer eine Support- oder Garantieanfrage stellen, anstatt das Problem selbst zu beheben.

Validierung

Rescue Party unterdrückt alle Rescue-Ereignisse, wenn das Gerät eine aktive USB-Datenverbindung hat, da dies ein starkes Signal dafür ist, dass jemand das Gerät debuggt.

Führen Sie folgenden Befehl aus, um diese Unterdrückung zu überschreiben:

adb shell setprop persist.sys.enable_rescue 1

Lösen Sie dann eine System- oder UI-Absturzschleife aus:

  • Führen Sie Folgendes aus, um einen system_server-Absturzloop auf niedriger Ebene auszulösen:

    adb shell setprop debug.crash_system 1
adb shell stop
adb shell start

  • So lösen Sie eine SystemUI-Absturzschleife auf mittlerer Ebene aus:

    adb shell setprop debug.crash_sysui 1

Beide Absturzschleifen lösen die Rettungslogik aus. Rescue Party protokolliert außerdem alle Rettungsvorgänge in den persistenten PackageManager-Logs, die unter /data/system/uiderrors.txt gespeichert werden, damit sie später geprüft und Fehler behoben werden können. Fehlerberichte enthalten diese persistenten Logs auch im Abschnitt Paketwarnmeldungen.