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
ListakBootReasonMap
.
- Podaj kanoniczne, możliwe do przeanalizowania i rozpoznawalne powody
- 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
czyinit
) 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ść zbootloader_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 lubdetail
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łosubreason
. Możesz podać wiele wartości,detail
wartości, które powinny być zgodne z hierarchią znaczenie. Dopuszczalne jest jednak zgłoszenie wieludetail
wartości o równym znaczeniu.
- Wymagany atrybut
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 elementramoops
powinien zachowywać trwałe treści."warm"
Ogólnie oznacza pamięć i urządzenia zachowują określony stan, aramoops
(patrzpstore
sterownika w jądrze) zawiera trwałe treści."shutdown"
"reboot"
Ogólnie oznacza, że stanramoops
to nieznany, a stan sprzętu jest nieznany. Jest to uniwersalna wartość, ponieważ Wartościcold
,hard
iwarm
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"
(zthermald
)"shutdown,battery"
"shutdown,battery,thermal"
(zBatteryStatsService
)."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
nakernel_panic signatures
, aby ulepszyć podtekstów kanonicznychsystem_boot_reason_prop
. - Niezgodne, aby zgłosić niezgodny ciąg znaków w
kBootReasonMap
(np."panic")
z programu rozruchowego, ponieważ ostatecznie uniemożliwi to ulepszaniereason
.
Jeśli na przykład kBootReasonMap
zawiera "wdog_bark"
,
Program rozruchowy powinien:
- Zmień na
"watchdog,bark"
i dodaj do listy wkBootReasonMap
- Zastanów się, co
"bark"
oznacza dla osób, które nie znają i określić, czy bardziej przydatna opcjasubreason
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.