Kanoniczny powód uruchamiania

Android 9 zawiera poniższe zmiany w specyfikacji przyczyny uruchamiania programu rozruchowego.

Przyczyny uruchamiania

Program rozruchowy wykorzystuje wyłącznie dostępne zasoby sprzętowe i pamięć do określić przyczynę ponownego uruchomienia urządzenia, a następnie przekazać tę informację przez Dodaję aplikację androidboot.bootreason=<reason> do Androida wiersza poleceń jądra systemu operacyjnego. init potem tłumaczy wiersz poleceń do rozpowszechnienia we właściwości Androida bootloader_boot_reason_prop (ro.boot.bootreason). Na urządzeniach z Androidem 12 lub nowszym z jądrem w wersji 5.10 lub nowszej, androidboot.bootreason=<reason> jest dodawany do konfiguracji rozruchowej, a nie do wiersza poleceń jądra.

Specyfikacja przyczyny uruchamiania

Poprzednie wersje Androida określały format przyczyny uruchomienia, w którym nie było spacje; były zapisane małymi literami i obejmowały kilka wymagań (np. dotyczące raportowania kernel_panic, watchdog, cold/warm/hard), a to za sprawą kwoty promocyjne z innych unikatowych powodów. W rezultacie tej luźnej specyfikacji setki niestandardowych (i czasami bezsensownych) przyczyn rozruchu. co z kolei doprowadziło do sytuacji, której nie da się zarządzać. Na dzień Premiera Androida, coraz liczniejsze treści niemal nie do przeanalizowania lub bez znaczenia zgłoszone przez program rozruchowy, wywołały problemy ze zgodnością dla bootloader_boot_reason_prop

W wersji 9 zespół Androida rozpoznaje, że starsza wersja bootloader_boot_reason_prop i nie można go napisać od nowa w czasie działania aplikacji. Wszelkie ulepszenia specyfikacja przyczyny uruchamiania musi więc pochodzić z interakcji programu rozruchowego i wprowadzania poprawek w istniejącym systemie. Dlatego Zespół Androida to:

  • Współpraca z programistami rozruchowymi, aby zachęcić ich do:
    • Podaj kanoniczne, możliwe do przeanalizowania i rozpoznawalne powody bootloader_boot_reason_prop
    • Weź udział w: system/core/bootstat/bootstat.cpp Lista kBootReasonMap.
  • Dodanie kontrolowanego i możliwego do wielokrotnego zapisu źródła system_boot_reason_prop (sys.boot.reason). O ograniczony zestaw aplikacji systemowych (np. bootstat czy init) może zmodyfikować tę właściwość, ale wszystkie aplikacje mogą udzielono sepolicy prawa do jego odczytu.
  • Informowanie użytkowników o przyczynie rozruchu w oczekiwaniu na podłączenie danych użytkownika przed oznaczeniem treści jako zaufanych we właściwości przyczyny uruchomienia systemu system_boot_reason_prop

Dlaczego tak późno? Usługa bootloader_boot_reason_prop jest dostępna na wczesnym etapie podczas uruchamiania, w razie potrzeby jest blokowane przez zasady zabezpieczeń Androida. ponieważ przedstawia niedokładne, niemożliwe do przeanalizowania i niekanoniczne informacje. W większości przypadków tylko deweloperzy dysponujący dogłębną wiedzą na temat systemu rozruchowego powinien uzyskać dostęp do tych informacji. Dopracowana, możliwa do przeanalizowania i strona kanoniczna Interfejs API przyczyny uruchamiania z system_boot_reason_prop może być niezawodny i dokładnie odbierane dopiero po zamontowaniu danych użytkownika. Więcej szczegółów:

  • Przed podłączeniem danych system_boot_reason_prop będzie zawierać wartość z bootloader_boot_reason_prop
  • Po podłączeniu danych użytkowników system_boot_reason_prop można zaktualizować w celu zapewnienia zgodności z zasadami lub dostarczać dokładniejsze informacje.

Dlatego Android 9 wydłuża okres czas przed oficjalnym uzyskaniem przyczyny uruchamiania, przez co nie jest ona natychmiastowa dokładność podczas uruchamiania (z bootloader_boot_reason_prop) aby były dostępne dopiero po podłączeniu danych użytkownika (z system_boot_reason_prop).

Logika Bootstat opiera się na bardziej przejrzystym i zgodnym bootloader_boot_reason_prop Gdy usługa używa parametru i to w przewidywalnym formacie. Poprawia też dokładność kontrolowanego ponownego uruchamiania scenariuszy wyłączenia, które z kolei zawężają i zwiększają dokładność z system_boot_reason_prop.

Kanoniczny format przyczyny uruchamiania

Kanoniczny format przyczyny uruchamiania aplikacji bootloader_boot_reason_prop w Androidzie 9 używa tej składni: 

<reason>,<subreason>,<detail>…

Reguły formatowania:

  • Małe litery
  • Brak pustych pól (użyj podkreślenia)
  • Wszystkie znaki do wydrukowania
  • Rozdzielone przecinkami reason, subreason i jeden lub detail instancji.
    • Wymagany atrybut reason, który reprezentuje najwyższy priorytet dlaczego urządzenie musiało się zrestartować lub wyłączyć.
    • Opcjonalny obiekt subreason reprezentujący krótkie podsumowanie dlaczego urządzenie musi zostać zrestartowane lub wyłączone (albo kto zrestartował lub wyłączył urządzenia).
    • Co najmniej 1 opcjonalna wartość detail. detail może wskazywać podsystem pomagający w określeniu, zaowocowało subreason. Możesz podać wiele wartości, detail wartości, które powinny być zgodne z hierarchią znaczenie. Dopuszczalne jest jednak zgłoszenie wielu detail wartości o równym znaczeniu.

Bierzemy pod uwagę pustą wartość pola bootloader_boot_reason_prop nielegalny (ponieważ pozwala to innym agentom wstrzyknąć przyczynę rozruchu po fakcie).

Wymagania dotyczące powodów

Wartość podana dla reason (pierwszy zakres, przed zakończeniem lub przecinek) musi należeć do poniższego zestawu, podzielonego na: jądro, silne i tępy. przyczyny:

  • zestaw jądra:
    • „watchdog"”
    • "kernel_panic"
  • mocny zestaw:
    • "recovery"
    • "bootloader"
  • blunt set:
    • "cold" Ogólnie oznacza pełny reset wszystkich urządzeń, łącznie z pamięcią.
    • "hard" Ogólnie oznacza, że sprzęt ma określony stan , a element ramoops powinien zachowywać trwałe treści.
    • "warm" Ogólnie oznacza pamięć i urządzenia zachowują określony stan, a ramoops (patrz pstore sterownika w jądrze) zawiera trwałe treści.
    • "shutdown"
    • "reboot" Ogólnie oznacza, że stan ramoops to nieznany, a stan sprzętu jest nieznany. Jest to uniwersalna wartość, ponieważ Wartości cold, hard i warm zawierają co oznacza głębokość resetowania urządzenia.

Programy rozruchowe muszą udostępniać zestaw jądra lub tępy (reason) oraz zalecamy podanie subreason, jeśli można określonych. Na przykład przytrzymanie przycisku zasilania, który może, ale nie musi, powodować Kopia zapasowa ramoops zawiera powód uruchamiania "reboot,longkey"

Pierwszy element reason nie może być częścią żadnej wartości typu subreason ani detail Ponieważ jednak przyczyny zestawu jądra nie mogą zostać wygenerowane przez użytkownika, można używać obiektu "watchdog" ponownie po sprecyzowaniu tej kwestii, wraz ze szczegółami dotyczącymi źródła (np. "reboot,watchdog,service_manager_unresponsive" lub "reboot,software,watchdog").

Powody rozruchu nie powinny wymagać specjalistycznej wiedzy wewnętrznej do rozszyfrowania ani powinny być zrozumiałe dla człowieka i z intuicyjnym raportem. Przykłady: "shutdown,vbxd" (zła), "shutdown,uv" (lepiej), "shutdown,undervoltage" (preferowane).

Kombinacje przyczyny i podprzyczyna

Android rezerwuje pakiet reason–subreason kombinacje, które nie powinny być przeciążone przy normalnym użytkowaniu, ale mogą być stosowane za każdym razem, jeśli połączenie dokładnie odzwierciedla powiązane . Przykłady zarezerwowanych kombinacji:

  • "reboot,userrequested"
  • "shutdown,userrequested"
  • "shutdown,thermal" (z thermald)
  • "shutdown,battery"
  • "shutdown,battery,thermal" (z BatteryStatsService).
  • "reboot,adb"
  • "reboot,shell"
  • "reboot,bootloader"
  • "reboot,recovery"

Więcej informacji znajdziesz tutaj: kBootReasonMap system/core/bootstat/bootstat.cpp i powiązany git historię zmian w repozytorium źródłowym Androida.

Zgłoś przyczyny uruchamiania

Wszystkie przyczyny uruchamiania – pochodzące z programu rozruchowego lub zarejestrowane podczas rozruchu kanonicznego Powód, musi zostać odnotowany w sekcji kBootReasonMap system/core/bootstat/bootstat.cpp kBootReasonMap lista to połączenie list zgodnych i starszych z powodów niezgodności z zasadami. Programiści rozruchowy powinni rejestrować tylko nowe zgodne z zasadami (i nie powinien rejestrować przyczyn niezgodności z zasadami, chyba produkt został już wysłany i nie można go zmienić).

Zdecydowanie zalecamy używanie istniejących, zgodnych wpisów w system/core/bootstat/bootstat.cpp i ćwiczenie powstrzymania przed za pomocą niezgodnego ciągu znaków. Oto co należy zrobić:

  • OK, aby zgłosić "kernel_panic" z programu rozruchowego, ponieważ bootstat może sprawdzić ramoops na kernel_panic signatures, aby ulepszyć podtekstów kanonicznych system_boot_reason_prop.
  • Niezgodne, aby zgłosić niezgodny ciąg znaków w kBootReasonMap (np. "panic") z programu rozruchowego, ponieważ ostatecznie uniemożliwi to ulepszanie reason.

Jeśli na przykład kBootReasonMap zawiera "wdog_bark", Program rozruchowy powinien:

  • Zmień na "watchdog,bark" i dodaj do listy w kBootReasonMap
  • Zastanów się, co "bark" oznacza dla osób, które nie znają i określić, czy bardziej przydatna opcja subreason i dostępności informacji.

Sprawdzanie zgodności przyczyny uruchamiania

Android nie udostępnia obecnie aktywnego testu CTS, który mógłby dokładnie uruchamiać lub sprawdzać wszystkie możliwe przyczyny rozruchu, jakie może podać program rozruchowy; partnerzy mogą nadal próbować przeprowadzić test pasywny, aby sprawdzić zgodność.

W związku z tym zgodność programu rozruchowego wymaga od programistów programów rozruchowych dobrowolnie przestrzegać zasad i wytycznych opisanych powyżej. Zachęcamy deweloperów, aby wspierali AOSP (w szczególności system/core/bootstat/bootstat.cpp) i wykorzystaj tę możliwość jako do dyskusji na temat problemów z uruchamianiem.