Wielu użytkowników w dużym stopniu polega na swoich telefonach i potrzebuje działającego urządzenia przez cały czas. Czasami jednak urządzenia wpadają w pętle ponownego uruchamiania, co powoduje, że użytkownicy wysyłają zgłoszenia do pomocy technicznej lub zapytania gwarancyjne. Ten proces jest frustrujący dla użytkowników i kosztowny dla producentów urządzeń i operatorów.
Android 8.0 zawiera funkcję wysyłającą „grupę ratunkową”, gdy wykryje, że podstawowe komponenty systemu utknęły w pętli awarii. Następnie zespół Rescue Party podejmuje szereg działań mających na celu odzyskanie urządzenia. W ostateczności Rescue Party ponownie uruchomi urządzenie w trybie odzyskiwania i poprosi użytkownika o przywrócenie ustawień fabrycznych.
Te funkcje ratunkowe nie są wymagane w dokumencie definicji zgodności systemu Android , ale nadal mogą być przydatne w celu ograniczenia liczby zgłoszeń do pomocy technicznej.
Realizacja
Rescue Party jest domyślnie włączone w systemie Android 8.0, a implementacja znajduje się w /services/core/java/com/android/server/RescueParty.java . Rescue Party otrzymuje informacje o zdarzeniach związanych z uruchomieniem i awarią i uruchamia się, jeśli:
- Serwer_systemowy uruchamia się ponownie więcej niż 5 razy w ciągu 5 minut.
- Trwała aplikacja systemowa ulega awarii więcej niż 5 razy w ciągu 30 sekund.
Po wykryciu jednej z tych sytuacji moduł Rescue Party przechodzi do następnego poziomu ratunkowego, przetwarza zadanie powiązane z tym poziomem i pozwala urządzeniu kontynuować działanie, aby sprawdzić, czy udało się odzyskać siły. Każdy poziom jest coraz bardziej agresywny w tym, co czyści lub resetuje. Ostatni poziom monituje użytkownika o przywrócenie ustawień fabrycznych urządzenia.
Do obsługi Rescue Party nie jest wymagane żadne specjalne wsparcie sprzętowe. Jeśli zostanie wdrożony, system odzyskiwania urządzenia musi odpowiedzieć na polecenie --prompt_and_wipe_data , a urządzenia muszą umożliwiać użytkownikom potwierdzenie zniszczenia danych użytkownika przed kontynuowaniem. System odzyskiwania powinien także umożliwiać użytkownikowi podjęcie ponownej próby uruchomienia urządzenia.
Ponieważ na każdy poziom ratunkowy może minąć maksymalnie 5 minut, zanim urządzenie będzie ponownie gotowe do działania, producenci urządzeń nie powinni dodawać niestandardowych poziomów ratunkowych. Wydłużony czas niesprawności urządzenia zwiększa prawdopodobieństwo, że użytkownicy zwrócą się o pomoc techniczną lub gwarancję, zamiast samodzielnie naprawiać swoje urządzenie.
Walidacja
Wszystkie zdarzenia ratunkowe są pomijane, gdy urządzenie ma aktywne połączenie danych USB, ponieważ jest to silny sygnał, że ktoś debuguje urządzenie.
Aby zastąpić to wyłączenie, uruchom:
adb shell setprop persist.sys.enable_rescue 1
Stamtąd możesz uruchomić pętlę awarii systemu lub interfejsu użytkownika.
Aby wywołać pętlę awarii system_server niskiego poziomu, uruchom:
adb shell setprop debug.crash_system 1
Aby wywołać pętlę awarii SystemUI średniego poziomu, uruchom:
adb shell setprop debug.crash_sysui 1
Obie pętle awarii inicjują logikę ratunkową. Wszystkie operacje ratunkowe są również rejestrowane w trwałych dziennikach PackageManager przechowywanych w /data/system/uiderrors.txt w celu późniejszej kontroli i debugowania. Te trwałe dzienniki są także uwzględniane w każdym raporcie o błędach w sekcji „Komunikaty ostrzegawcze pakietu”.