Użytkownicy polegają na swoich telefonach i potrzebują działającego urządzenia przez cały czas. Czasami jednak urządzenia wpadają w pętlę ponownego uruchamiania, co powoduje, że użytkownicy zgłaszają problemy do pomocy lub wysyłają zapytania dotyczące gwarancji. Ten proces jest frustrujący dla użytkowników i kosztowny dla producentów urządzeń oraz operatorów.
Android 8.0 (poziom interfejsu API 26) i nowsze wersje zawierają funkcję, która uruchamia proces ratunkowy, gdy wykryje, że podstawowe komponenty systemu utknęły w pętli awarii. Po otrzymaniu tego sygnału funkcja Rescue Party wykonuje serię działań, aby przywrócić urządzenie do działania. W ostateczności Rescue Party uruchamia urządzenie ponownie w trybie przywracania (Recovery Mode) i wyświetla użytkownikowi prośbę o przywrócenie ustawień fabrycznych.
Implementacja
Funkcja Rescue Party jest domyślnie włączona, a jej implementacja znajduje się w pliku /services/core/java/com/android/server/RescueParty.java. Rescue Party otrzymuje informacje o zdarzeniach uruchamiania i awarii i uruchamia się, gdy:
- proces
system_serverzostanie ponownie uruchomiony więcej niż 5 razy w ciągu 5 minut; - trwale działająca aplikacja systemowa ulegnie awarii więcej niż 5 razy w ciągu 30 sekund.
Gdy Rescue Party wykryje jedną z tych sytuacji, przechodzi do następnego poziomu ratunkowego, przetwarza zadanie powiązane z tym poziomem i pozwala urządzeniu kontynuować działanie, aby sprawdzić, czy się zregeneruje. Każdy poziom jest coraz bardziej agresywny w zakresie czyszczenia lub resetowania. Ostatni poziom wyświetla użytkownikowi prośbę o przywrócenie ustawień fabrycznych urządzenia.
Rescue Party nie wymaga specjalnej obsługi sprzętowej. Jeśli funkcja jest zaimplementowana, system przywracania urządzenia musi odpowiadać na polecenie --prompt_and_wipe_data, a urządzenia muszą umożliwiać użytkownikom potwierdzenie usunięcia danych użytkownika przed kontynuowaniem. System przywracania powinien też dawać użytkownikowi możliwość ponownego uruchomienia urządzenia.
Ponieważ każdy poziom ratunkowy może dodać do 5 minut, zanim urządzenie będzie ponownie działać, producenci urządzeń nie powinni dodawać niestandardowych poziomów ratunkowych. Dłuższy czas, w którym urządzenie nie działa, zwiększa prawdopodobieństwo, że użytkownicy zamiast samodzielnie przywracać urządzenie, zgłoszą problem do pomocy lub wyślą zapytanie dotyczące gwarancji.
Weryfikacja
Rescue Party pomija wszystkie zdarzenia ratunkowe, gdy urządzenie ma aktywne połączenie danych USB, ponieważ jest to silny sygnał, że ktoś debuguje urządzenie.
Aby zastąpić to pomijanie, uruchom:
adb shell setprop persist.sys.enable_rescue 1Następnie wywołaj pętlę awarii systemu lub interfejsu:
Aby wywołać pętlę awarii
system_serverna niskim poziomie, uruchom:adb shell setprop debug.crash_system 1adb shell stopadb shell startAby wywołać pętlę awarii SystemUI na średnim poziomie, uruchom:
adb shell setprop debug.crash_sysui 1
Obie pętle awarii inicjują logikę ratunkową. Rescue Party rejestruje też wszystkie operacje ratunkowe w trwałych logach PackageManager przechowywanych w lokalizacji /data/system/uiderrors.txt na potrzeby późniejszego sprawdzenia i debugowania. Raporty o błędach zawierają też te trwałe logi w sekcji Komunikaty ostrzegawcze pakietu.