Kanonisches Boot-Ergebnis

Android 9 enthält die folgenden Änderungen an der Spezifikation des Bootloader-Startgrunds.

Startgründe

Ein Bootloader verwendet eindeutig verfügbare Hardware- und Arbeitsspeicherressourcen, um zu ermitteln, warum ein Gerät neu gestartet wurde. Anschließend teilt er diese Ermittlung mit, indem er der Android Kernel-Befehlszeile für den Start androidboot.bootreason=<reason> hinzufügt. init übersetzt diese Befehlszeile dann, um sie an die Android-Eigenschaft bootloader_boot_reason_prop (ro.boot.bootreason) weiterzugeben. Bei Geräten mit Android 12 oder höher und Kernel-Version 5.10 oder höher wird androidboot.bootreason=<reason> anstelle der Kernel-Befehlszeile zu bootconfig hinzugefügt.

Spezifikationen des Startgrunds

In früheren Versionen von Android wurde ein Startgrundformat ohne Leerzeichen verwendet, das nur Kleinbuchstaben enthielt und nur wenige Anforderungen umfasste (z. B. für die Meldung von kernel_panic, watchdog, cold/warm/hard). Außerdem wurden andere eindeutige Gründe berücksichtigt. Diese lockere Spezifikation führte zur Verbreitung von Hunderten von benutzerdefinierten (und manchmal bedeutungslosen) Startgrund strings, was wiederum zu einer unübersichtlichen Situation führte. In der aktuellen Android-Version haben die vielen schwer zu analysierenden oder bedeutungslosen Inhalte, die vom Bootloader gemeldet werden, zu Compliance-Problemen für bootloader_boot_reason_prop geführt.

Mit der Veröffentlichung von Android 9 hat das Android-Team erkannt, dass die alte bootloader_boot_reason_prop eine erhebliche Dynamik hat und zur Laufzeit nicht neu geschrieben werden kann. Alle Verbesserungen an der Spezifikation des Startgrunds müssen daher aus der Zusammenarbeit mit Bootloader-Entwicklern und Anpassungen am bestehenden System resultieren. Dazu unternimmt das Android-Team Folgendes:

• Zusammenarbeit mit Bootloader-Entwicklern, um sie zu ermutigen:
  • Kanonische, analysierbare und erkennbare Gründe für bootloader_boot_reason_prop anzugeben.
  • An der system/core/bootstat/bootstat.cpp kBootReasonMap Liste teilzunehmen.
• Hinzufügen einer kontrollierten und zur Laufzeit neu beschreibbaren Quelle für die system_boot_reason_prop (sys.boot.reason). Eine begrenzte Anzahl von System-Apps (z. B. bootstat und init) kann diese Eigenschaft neu schreiben, aber allen Apps können sepolicy-Rechte zum Lesen gewährt werden.
• Nutzer über den Startgrund informieren und sie bitten, zu warten, bis die Nutzerdaten eingebunden sind bevor sie den Inhalt der System-Startgrund-Eigenschaft system_boot_reason_prop verwenden.

Warum so spät? `bootloader_boot_reason_prop` ist zwar früh im Startprozess verfügbar, wird aber bei Bedarf von der Android-Sicherheitsrichtlinie blockiert, da sie ungenaue, nicht analysierbare und nicht kanonische Informationen enthält.bootloader_boot_reason_prop In den meisten Fällen sollten nur Entwickler mit fundierten Kenntnissen des Startsystems auf diese Informationen zugreifen müssen. Eine verfeinerte, analysierbare und kanonische API für den Startgrund mit system_boot_reason_prop kann erst nachdem die Nutzerdaten eingebunden wurden zuverlässig und genau erfasst werden. Im Detail:

• Bevor die Nutzerdaten eingebunden wurden, system_boot_reason_prop enthält den Wert von bootloader_boot_reason_prop.
• Nachdem die Nutzerdaten eingebunden wurden, system_boot_reason_prop kann aktualisiert werden, um die Compliance zu gewährleisten oder genauere Informationen zu liefern.

Aus diesem Grund verlängert Android 9 den Zeitraum, bevor der Startgrund offiziell erfasst werden kann. Er wird von sofortiger Genauigkeit beim Start (mit bootloader_boot_reason_prop) auf Verfügbarkeit erst nach dem Einbinden der Nutzerdaten (mit system_boot_reason_prop) umgestellt.

Die Bootstat-Logik hängt von einer informativeren und konformen bootloader_boot_reason_prop ab. Wenn diese Eigenschaft ein vorhersehbares Format verwendet, wird die Genauigkeit aller kontrollierten Neustart- und Herunterfahrszenarien verbessert, was wiederum die Genauigkeit und Bedeutung von system_boot_reason_prop verfeinert und erweitert.

Kanonisches Startgrundformat

Das kanonische Startgrundformat für bootloader_boot_reason_prop in Android 9 verwendet die folgende Syntax:

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

Formatierungsregeln:

• Kleinbuchstaben
• Keine Leerzeichen (Unterstrich verwenden)
• Alle druckbaren Zeichen
• Kommagetrennte reason, subreason und eine oder mehrere detail-Instanzen.
  • Ein erforderliches reason, das den Grund mit der höchsten Priorität dafür angibt, warum das Gerät neu gestartet oder heruntergefahren werden musste.
  • Ein optionales subreason, das eine kurze Zusammenfassung des Grunds dafür angibt, warum das Gerät neu gestartet oder heruntergefahren werden musste (oder wer das Gerät neu gestartet oder heruntergefahren hat).
  • Ein oder mehrere optionale detail-Werte. Ein detail kann auf ein Subsystem verweisen, um zu ermitteln, welches bestimmte System zum subreason geführt hat. Sie können mehrere detail Werte angeben, die im Allgemeinen einer Hierarchie der Wichtigkeit folgen sollten. Es ist aber auch akzeptabel, mehrere detail Werte mit gleicher Wichtigkeit zu melden.

Ein leerer Wert für bootloader_boot_reason_prop wird als illegal betrachtet, da andere Agents dadurch nachträglich einen Startgrund einschleusen können.

Anforderungen an den Grund

Der für reason angegebene Wert (erste Spanne, vor der Beendigung oder dem Komma) muss aus der folgenden Menge stammen, die in Kernel-, starke und stumpfe Gründe unterteilt ist:

• Kernel-Menge:
  • "watchdog"
  • "kernel_panic"
• Starke Menge:
  • "recovery"
  • "bootloader"
• Stumpfe Menge:
  • "cold". Gibt im Allgemeinen einen vollständigen Reset aller Geräte an, einschließlich des Arbeitsspeichers.
  • "hard". Gibt im Allgemeinen an, dass der Status der Hardware zurückgesetzt wurde und ramoops dauerhafte Inhalte beibehalten sollte.
  • "warm". Gibt im Allgemeinen an, dass der Arbeitsspeicher und die Geräte einen Teil des Status beibehalten und der ramoops (siehe pstore Treiber im Kernel) Sicherungsspeicher dauerhafte Inhalte enthält.
  • "shutdown"
  • "reboot". Bedeutet im Allgemeinen, dass der Status von ramoops unbekannt ist und der Hardwarestatus unbekannt ist. Dieser Wert ist ein Sammelwert, da die cold, hard und warm Werte Hinweise auf die Tiefe des Resets für das Gerät geben.

Bootloader müssen einen aus der Kernel- oder stumpfen Menge reason angeben. Es wird dringend empfohlen, einen subreason anzugeben, wenn er ermittelt werden kann. Ein langes Drücken der Ein/Aus-Taste, das möglicherweise ramoops Backup hat oder nicht, hätte beispielsweise den Startgrund "reboot,longkey".

Kein reason der ersten Spanne kann Teil eines subreason oder detail sein. Da Gründe aus der Kernel-Menge jedoch nicht vom Nutzerbereich erzeugt werden können, "watchdog" kann nach einem Grund aus der stumpfen Menge zusammen mit einem Detail der Quelle wiederverwendet werden (z. B. "reboot,watchdog,service_manager_unresponsive", oder "reboot,software,watchdog").

Startgründe sollten keine internen Fachkenntnisse erfordern, um sie zu entschlüsseln, und/oder für Menschen lesbar sein und einen intuitiven Bericht liefern. 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 Verwendung nicht überlastet werden sollten, aber im Einzelfall verwendet werden können, wenn die Kombination den zugehörigen Zustand genau widerspiegelt. Beispiele für reservierte Kombinationen:

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

Weitere Informationen finden Sie unter kBootReasonMap in system/core/bootstat/bootstat.cpp und im zugehörigen Git Änderungsprotokoll im Android-Quellcode-Repository.

Startgründe melden

Alle Startgründe, entweder vom Bootloader oder im kanonischen Start grund aufgezeichnet, müssen im kBootReasonMap Abschnitt von system/core/bootstat/bootstat.cpp aufgezeichnet werden. Die kBootReasonMap Liste enthält eine Mischung aus konformen und nicht konformen Gründen. Bootloader-Entwickler sollten hier nur neue konforme Gründe registrieren (und keine nicht konformen Gründe, es sei denn, das Produkt wurde bereits ausgeliefert und kann nicht mehr geändert werden).

Wir empfehlen dringend, vorhandene, konforme Einträge in system/core/bootstat/bootstat.cpp zu verwenden und mit der Verwendung eines nicht konformen Strings zurückhaltend zu sein. Als Richtlinie gilt:

• Es ist in Ordnung , "kernel_panic" vom Bootloader zu melden, da bootstat möglicherweise ramoops nach kernel_panic signatures durchsuchen kann, um die Untergründe in die kanonische system_boot_reason_prop zu verfeinern.
• Nicht in Ordnung , einen nicht konformen String in kBootReasonMap (z. B. "panic") vom Bootloader zu melden, da dadurch letztendlich die Möglichkeit zur Verfeinerung des reason verloren geht.

Wenn kBootReasonMap beispielsweise "wdog_bark" enthält, sollte ein Bootloader-Entwickler Folgendes tun:

• In "watchdog,bark" ändern und der Liste in kBootReasonMap hinzufügen.
• Überlegen, was "bark" für Personen bedeutet, die mit der Technologie nicht vertraut sind, und prüfen, ob ein aussagekräftigerer subreason verfügbar ist.

Compliance des Startgrunds überprüfen

Derzeit bietet Android keinen aktiven CTS-Test, der alle möglichen Startgründe, die ein Bootloader liefern könnte, genau auslösen oder prüfen kann; Partner können aber versuchen, einen passiven Test durchzuführen, um die Kompatibilität zu ermitteln.

Daher erfordert die Compliance des Bootloaders, dass sich Bootloader-Entwickler freiwillig an den Geist der oben beschriebenen Regeln und Richtlinien halten. Wir bitten diese Entwickler, zu AOSP beizutragen (insbesondere zu system/core/bootstat/bootstat.cpp) und diese Gelegenheit als Forum für Diskussionen über Probleme mit Startgründen zu nutzen.