Unter Android 9 wurden die folgenden Änderungen an der Spezifikation des Bootloader-Bootgrunds vorgenommen.
Startgründe
Ein Bootloader nutzt speziell verfügbare Hardware- und Arbeitsspeicherressourcen,
warum ein Gerät neu gestartet wurde.
androidboot.bootreason=<reason>
wird zu Android hinzugefügt
für den Start der Kernel-Befehlszeile. Anschließend wird dies von init
übersetzt
Befehlszeile zur Weitergabe an die Android-Property
bootloader_boot_reason_prop
(ro.boot.bootreason
)
Bei Geräten mit Android 12 oder höher
mit Kernel-Version 5.10 oder höher, androidboot.bootreason=<reason>
wird bootconfig anstelle der Kernel-Befehlszeile hinzugefügt.
Spezifikationen für Bootgründe
In früheren Android-Versionen wurde ein Format für den Startgrund angegeben, bei dem keine
Leerzeichen, die alle aus Kleinbuchstaben bestehen, erfüllten wenige Anforderungen (z. B. für die Berichterstellung).
kernel_panic
, watchdog
,
cold
/warm
/hard
) und welche
Zuschüsse aus anderen besonderen Gründen. Diese lockere Spezifikation führte dazu, dass
Hunderte von benutzerdefinierten (und manchmal bedeutungslosen) Startgründen
was wiederum zu einer unüberschaubaren Situation führte. Ab der aktuellen
Android-Version, die schiere Dynamik von fast nicht parsbaren oder bedeutungslosen Inhalten
die vom Bootloader protokolliert wurden, Compliance-Probleme verursacht für
bootloader_boot_reason_prop
Mit der Veröffentlichung von Android 9
erkennt, dass die alte bootloader_boot_reason_prop
und können während der Laufzeit
nicht neu geschrieben werden. Jegliche Verbesserungen der
Der Startgrund muss daher aus Interaktionen mit
Bootloader-Entwickler und
Änderungen am vorhandenen System. Zu diesem Zweck
Das Android-Team ist:
- Interaktionen mit Bootloader-Entwicklern, um sie zu Folgendem zu ermutigen:
<ph type="x-smartling-placeholder">
- </ph>
- Geben Sie kanonische, parsbare und erkennbare Gründe an,
bootloader_boot_reason_prop
- Am
system/core/bootstat/bootstat.cpp
teilnehmenkBootReasonMap
-Liste.
- Geben Sie kanonische, parsbare und erkennbare Gründe an,
- Das Hinzufügen einer kontrollierten und laufzeitüberschreibbaren Quelle des
system_boot_reason_prop
(sys.boot.reason
) A eine begrenzte Anzahl von System-Apps (z. B.bootstat
undinit
) kann dieses Attribut umschreiben, aber alle Apps können sepolicy Leserechte erteilt. - Nutzer über den Startgrund informieren, dass sie warten sollen, nachdem die Nutzerdaten bereitgestellt wurden
bevor der Inhalt in der Eigenschaft für den Startgrund des Systems als vertrauenswürdig eingestuft wird.
system_boot_reason_prop
Warum so spät? bootloader_boot_reason_prop
ist zwar früher verfügbar
wird sie nach Bedarf durch die Android-Sicherheitsrichtlinie blockiert.
da sie ungenaue, nicht analysierbare und nicht kanonische Informationen darstellt.
In den meisten Fällen benötigen nur Entwickler,
die das Bootsystem gut kennen,
auf diese Informationen zugreifen müssen. Eine optimierte, parsbare und kanonische
Die API für den Boot-Grund mit system_boot_reason_prop
kann zuverlässig sein
und erst nach der Bereitstellung der Nutzerdaten korrekt erfasst werden.
Im Detail:
- Bevor Nutzerdaten bereitgestellt wurden,
system_boot_reason_prop
enthält den Wert ausbootloader_boot_reason_prop
. - Nachdem die Nutzerdaten bereitgestellt wurden,
system_boot_reason_prop
wird möglicherweise aktualisiert, um die Richtlinie zu erfüllen oder erhalten genauere Informationen.
Aus diesem Grund verlängert Android 9 den Zeitraum
bevor der Startgrund offiziell abgerufen werden kann.
Sofort genau beim Booten (mit bootloader_boot_reason_prop
)
erst nach der Bereitstellung von Nutzerdaten (mit
system_boot_reason_prop
).
Bootstat-Logik hängt von einer informativeren und
bootloader_boot_reason_prop
Wenn diese Eigenschaft eine
vorhersehbares Format, verbessert es die Genauigkeit
aller kontrollierten Neustarts und
das die Genauigkeit und Bedeutung
verfeinert und erweitert.
von system_boot_reason_prop
.
Format des kanonischen Startgrunds
Das Format des kanonischen Startgrunds für bootloader_boot_reason_prop
in Android 9 verwendet die folgende Syntax:
<reason>,<subreason>,<detail>…
Formatierungsregeln:
- Kleinschreibung
- Keine Leerzeichen (unterstrichen)
- Alle druckbaren Zeichen
- Durch Kommas getrennte
reason
,subreason
und eine oder mehrdetail
Instanzen.- Ein erforderlicher
reason
, der die höchste Priorität darstellt warum das Gerät neu gestartet oder heruntergefahren werden musste. - Ein optionales
subreason
, das eine kurze Zusammenfassung der warum das Gerät neu gestartet oder heruntergefahren werden musste (oder wer das Gerät neu gestartet oder Gerät). - Ein oder mehrere optionale
detail
-Werte. Eindetail
auf ein Subsystem verweisen kann, um zu bestimmen, führten zu folgendem Ergebnis:subreason
. Sie können mehreredetail
-Werte, die in der Regel einer Hierarchie von Bedeutung. Es ist jedoch auch akzeptabel, mehreredetail
Werte von gleicher Bedeutung.
- Ein erforderlicher
Ein leerer Wert für bootloader_boot_reason_prop
wird berücksichtigt
illegal (da dadurch andere Agenten nachträglich einen Startgrund einfügen können).
Anforderungen an den Grund
Der Wert für reason
(erster Span vor der Beendigung oder
Komma) muss dem folgenden Satz entsprechen, unterteilt in Kernel, strong und blunt
Gründe:
- Kernel-Satz:
<ph type="x-smartling-placeholder">
- </ph>
- "
watchdog"
"kernel_panic"
- "
- Starker Satz:
<ph type="x-smartling-placeholder">
- </ph>
"recovery"
"bootloader"
- stumpfes Set:
<ph type="x-smartling-placeholder">
- </ph>
"cold"
Im Allgemeinen bedeutet das, dass alle Geräte vollständig zurückgesetzt werden, auch aus dem Gedächtnis."hard"
Gibt im Allgemeinen an, dass die Hardware ihren Status hat Zurücksetzen undramoops
sollten persistente Inhalte beibehalten."warm"
Gibt in der Regel den Arbeitsspeicher und die Geräte an einen Zustand beibehalten und dasramoops
(siehepstore
) Treiber im Kernel) enthält."shutdown"
"reboot"
Im Allgemeinen bedeutet das, dass der Statusramoops
unbekannt und der Hardwarestatus ist unbekannt. Dieser Wert ist ein universeller Wert, da der Wert Die Wertecold
,hard
undwarm
stellen Folgendes bereit: Hinweise auf den Umfang des Zurücksetzens des Geräts.
Bootloader müssen einen Kernel- oder Blunt-Set reason
bereitstellen.
wird dringend empfohlen, nach Möglichkeit eine subreason
anzugeben.
bestimmt. Wenn Sie z. B. lange auf die Ein/Aus-Taste drücken,
ramoops
Sicherung hätte den Startgrund
"reboot,longkey"
.
Kein reason
des ersten Spans darf Teil eines subreason
- oder
detail
Da die Gründe für Kernel-Sets jedoch nicht
kann "watchdog"
nach einem stumpfen Set-Grund wiederverwendet werden,
zusammen mit einer Beschreibung der Quelle (z. B.
"reboot,watchdog,service_manager_unresponsive"
oder
"reboot,software,watchdog"
.
Bootgründe sollten kein internes Expertenwissen erfordern, um sie zu entschlüsseln und/oder
sollten mit einem intuitiven Bericht menschenlesbar sein. Beispiele:
"shutdown,vbxd"
(schlecht), "shutdown,uv"
(besser),
"shutdown,undervoltage"
(bevorzugt).
Kombinationen aus Grund und Untergrund
Android reserviert eine Reihe von reason
-subreason
Kombinationen, die bei normaler Nutzung nicht überlastet werden sollten,
von Fall zu Fall entscheiden, wenn die Kombination die
. Beispiele für reservierte Kombinationen:
"reboot,userrequested"
"shutdown,userrequested"
"shutdown,thermal"
(vonthermald
)"shutdown,battery"
"shutdown,battery,thermal"
(vonBatteryStatsService
)"reboot,adb"
"reboot,shell"
"reboot,bootloader"
"reboot,recovery"
Weitere Informationen finden Sie unter kBootReasonMap
in
system/core/bootstat/bootstat.cpp
und das zugehörige Git
Änderungsprotokollverlauf im Android-Quell-Repository.
Startgründe melden
Alle Bootgründe, entweder über den Bootloader oder aufgezeichnet im kanonischen Bootmodus
Grund, muss im kBootReasonMap
-Abschnitt der
system/core/bootstat/bootstat.cpp
. Die
Die Liste „kBootReasonMap
“ enthält eine Mischung aus konformen und Legacy-Versionen
Gründe für die Nicht-Compliance. Bootloader-Entwickler sollten nur neue
(und sollten keine Gründe angeben, die nicht konform sind, es sei denn,
das Produkt bereits versendet wurde und nicht mehr geändert werden kann).
Wir empfehlen dringend, vorhandene, konforme Einträge in
system/core/bootstat/bootstat.cpp
und bringe dich zurück, bevor
nicht konformen String verwendet. Als Richtlinie gilt:
- OK, um
"kernel_panic"
über die Bootloader, dabootstat
möglicherweise die Dateiramoops
fürkernel_panic signatures
, um die Untergründe in die kanonischesystem_boot_reason_prop
einfügen. - Nicht OK, um einen nicht konformen String in
kBootReasonMap
(z. B."panic")
aus der Bootloader, da dies die Optimierung derreason
Wenn beispielsweise kBootReasonMap
"wdog_bark"
enthält,
sollte ein Bootloader-Entwickler:
- In
"watchdog,bark"
ändern und der Liste hinzufügen inkBootReasonMap
. - Überlegen Sie, was
"bark"
für diejenigen bedeutet, die noch nicht mit dem und ermitteln, ob eine aussagekräftigeresubreason
verfügbar.
Compliance des Bootgrunds prüfen
Derzeit bietet Android keinen aktiven CTS-Test, mit dem alle möglichen Startgründe, die ein Bootloader angeben könnte, auslösen oder prüfen; können Partner trotzdem versuchen, einen passiven Test durchzuführen, um die Kompatibilität zu ermitteln.
Daher müssen Bootloader-Entwickler aufgrund der Bootloader-Compliance
sich freiwillig im Sinne der oben beschriebenen Regeln und Richtlinien halten.
Wir fordern diese Entwickler dringend dazu auf, zum AOSP (insbesondere
system/core/bootstat/bootstat.cpp
) und nutzen Sie diese Empfehlung als
Forum für Diskussionen über Probleme beim Booten.