Viele Nutzer sind stark auf ihr Smartphone angewiesen und benötigen jederzeit ein funktionierendes Gerät. Manchmal kommt es jedoch zu Neustartschleifen, die dazu führen, dass Nutzer Supportanfragen oder Garantieanfragen stellen. Dieser Prozess ist frustrierend für Nutzer und teuer für Gerätehersteller und Mobilfunkanbieter.
Android 8.0 enthält eine Funktion, die eine „Rettungsmannschaft“ sendet, wenn es feststellt, dass Kernsystemkomponenten in Abstürzen stecken. Rescue Party führt dann eine Reihe von Aktionen aus, um das Gerät wiederherzustellen. Als letzte Möglichkeit startet Rescue Party das Gerät im Wiederherstellungsmodus neu und fordert den Nutzer auf, es auf die Werkseinstellungen zurückzusetzen.
Diese Rettungsfunktionen sind nicht im Android Compatibility Definition Document (CDD) erforderlich, können aber dennoch nützlich sein, um Supportanfragen zu reduzieren.
Implementierung
Rescue Party ist in Android 8.0 standardmäßig aktiviert und die Implementierung befindet sich unter /services/core/java/com/android/server/RescueParty.java.
Rescue Party erhält Informationen zu Boot- und Absturzereignissen und wird gestartet, wenn:
- Der system_server wird innerhalb von 5 Minuten mehr als 5 Mal neu gestartet.
- Eine persistente System-App stürzt innerhalb von 30 Sekunden mehr als fünfmal ab.
Wenn eine dieser Situationen erkannt wird, eskaliert Rescue Party die Anfrage an die nächste Rettungsebene, verarbeitet die mit dieser Ebene verknüpfte Aufgabe und lässt das Gerät weiterarbeiten, um zu sehen, ob es wiederhergestellt werden kann. Mit jeder Stufe werden mehr Daten gelöscht oder zurückgesetzt. Auf der letzten Stufe wird der Nutzer aufgefordert, das Gerät auf die Werkseinstellungen zurückzusetzen.
Für Rescue Party ist keine spezielle Hardware erforderlich. Wenn das Wiederherstellungssystem eines Geräts implementiert ist, muss es auf den Befehl --prompt_and_wipe_data reagieren. Außerdem muss es Nutzern die Möglichkeit bieten, die Zerstörung von Nutzerdaten zu bestätigen, bevor sie fortfahren. Das Wiederherstellungssystem sollte dem Nutzer auch die Möglichkeit geben, sein Gerät noch einmal zu starten.
Da jede Rettungsebene bis zu 5 Minuten dauern kann, bis ein Gerät wieder einsatzbereit ist, sollten Gerätehersteller keine benutzerdefinierten Rettungsebenen hinzufügen. Je länger ein Gerät nicht funktioniert, desto eher wenden sich Nutzer an den Support oder stellen eine Garantieanfrage, anstatt das Gerät selbst zu reparieren.
Zertifizierungsstufe
Alle Rettungsereignisse werden unterdrückt, wenn das Gerät eine aktive USB-Datenverbindung hat, da dies ein starkes Signal dafür ist, dass jemand das Gerät debuggt.
Wenn Sie diese Unterdrückung überschreiben möchten, führen Sie Folgendes aus:
adb shell setprop persist.sys.enable_rescue 1
Dort können Sie einen System- oder UI-Absturz-Loop auslösen.
So lösen Sie einen Low-Level-system_server-Absturz-Loop aus:
adb shell setprop debug.crash_system 1
So lösen Sie einen SystemUI-Absturz-Loop auf mittlerer Ebene aus:
adb shell setprop debug.crash_sysui 1
Beide Crash-Schleifen initiieren die Rettungslogik. Alle Rettungsaktionen werden auch in den persistenten PackageManager-Protokollen unter /data/system/uiderrors.txt protokolliert, die zur späteren Prüfung und Fehlerbehebung verwendet werden.
Diese persistenten Protokolle sind auch in jedem Fehlerbericht im Abschnitt „Paketwarnungen“ enthalten.