Wielu użytkowników jest mocno uzależnionych od telefonów i potrzebuje działającego urządzenia przez cały czas. Czasami jednak urządzenia wchodzą w pętlę ponownego uruchamiania, co powoduje, że użytkownicy przesyłają zgłoszenia do zespołu pomocy lub proszą o pomoc w ramach gwarancji. Ten proces jest uciążliwy dla użytkowników i drogi dla producentów urządzeń oraz operatorów.
Android 8.0 zawiera funkcję, która wysyła „zespół ratunkowy”, gdy zauważy, że główne komponenty systemu utkwiły w pętli awarii. Następnie Rescue Party wykonuje serię działań, aby odzyskać urządzenie. W ostateczności Rescue Party uruchamia urządzenie w trybie odzyskiwania i prosi użytkownika o przywrócenie urządzenia do ustawień fabrycznych.
Te funkcje ratunkowe nie są wymagane przez dokument definicji zgodności Androida, ale mogą być przydatne do zmniejszenia liczby zgłoszeń do zespołu pomocy.
Implementacja
Funkcja Rescue Party jest domyślnie włączona w Androidzie 8.0, a jej implementacja znajduje się w /services/core/java/com/android/server/RescueParty.java.
Rescue Party otrzymuje informacje o wydarzeniach rozruchu i awarii oraz uruchamia się, jeśli:
- System_server uruchamia się ponownie ponad 5 razy w ciągu 5 minut.
- trwała aplikacja systemowa ulega awarii ponad 5 razy w ciągu 30 sekund;
Gdy zostanie wykryty jeden z tych stanów, Rescue Party przejdzie do następnego poziomu ratowania, przetworzy zadanie powiązane z tym poziomem i pozwoli urządzeniu na kontynuowanie, aby sprawdzić, czy uda się je uruchomić. Każdy poziom jest coraz bardziej agresywny w tym, co czyści lub resetuje. Ostatni poziom spowoduje, że użytkownik będzie musiał przywrócić urządzenie do ustawień fabrycznych.
Aby korzystać z Rescue Party, nie trzeba mieć specjalnego sprzętu. Jeśli jest wdrożony, system odzyskiwania urządzenia musi reagować na polecenie --prompt_and_wipe_data, a urządzenia muszą udostępniać użytkownikom sposób na potwierdzenie zniszczenia danych przed dalszymi działaniami. System odzyskiwania powinien też dawać użytkownikowi możliwość ponownego uruchomienia urządzenia.
Ponieważ każdy poziom ratunkowy może wydłużyć czas ponownego uruchomienia urządzenia nawet o 5 minut, producenci urządzeń nie powinni dodawać niestandardowych poziomów ratunkowych. Dłuższy czas nieużywania urządzenia zwiększa prawdopodobieństwo, że użytkownik skontaktuje się z zespołem pomocy lub zgłosi reklamację z tytułu gwarancji, zamiast samodzielnie próbować naprawić urządzenie.
Weryfikacja
Wszystkie zdarzenia ratunkowe są tłumione, gdy urządzenie ma aktywne połączenie danych USB, ponieważ jest to wyraźny sygnał, że ktoś debuguje urządzenie.
Aby zastąpić to wyłączenie, wpisz:
adb shell setprop persist.sys.enable_rescue 1
Możesz wtedy wywołać pętlę awarii systemu lub interfejsu użytkownika.
Aby wywołać pętlę awarii system_server na niskim poziomie, uruchom:
adb shell setprop debug.crash_system 1
Aby wywołać pętlę awarii SystemUI na średnim poziomie, uruchom:
adb shell setprop debug.crash_sysui 1
Oba pętle awarii inicjują logikę ratowania. Wszystkie operacje ratunkowe są również rejestrowane w trwałych dziennikach PackageManager przechowywanych w /data/system/uiderrors.txt na potrzeby późniejszej inspekcji i debugowania.
Te trwałe dzienniki są też uwzględniane w każdym raporcie o błędzie w sekcji „Wiadomości z ostrzeżeniem”.