Kanonisches Boot-Ergebnis

Android 9 enthält die folgenden Änderungen an der Spezifikation für den Bootloader-Boot-Grund.

Gründe für den Start

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

Angaben zum Bootgrund

In früheren Android-Versionen wurde ein Boot-Grund-Format ohne Leerzeichen, in Kleinbuchstaben und mit wenigen Anforderungen (z. B. für die Meldung von kernel_panic, watchdog, cold/warm/hard) angegeben, das auch andere eindeutige Gründe zuließ. Diese lockere Spezifikation führte zur Verbreitung Hunderter von benutzerdefinierten (und manchmal sinnlosen) Strings für den Bootvorgang, was wiederum zu einer unübersichtlichen Situation führte. In der aktuellen Android-Version hat die schiere Menge an schwer zu parsenden oder sinnlosen Inhalten, die vom Bootloader eingereicht wurden, zu Compliance-Problemen für bootloader_boot_reason_prop geführt.

Mit der Veröffentlichung von Android 9 hat das Android-Team erkannt, dass das alte bootloader_boot_reason_prop eine erhebliche Dynamik hat und nicht zur Laufzeit neu geschrieben werden kann. Alle Verbesserungen der Spezifikation des Boot-Grundes müssen daher aus der Interaktion mit Bootloader-Entwicklern und Anpassungen des bestehenden Systems resultieren. Das Android-Team:

• Bootloader-Entwickler dazu anregen, Folgendes zu tun:
  • Geben Sie kanonische, analysierbare und nachvollziehbare Gründe für bootloader_boot_reason_prop an.
  • An der Liste system/core/bootstat/bootstat.cpp kBootReasonMap teilnehmen
• Eine kontrollierte und zur Laufzeit überschreibbare Quelle für system_boot_reason_prop (sys.boot.reason) hinzufügen. Eine begrenzte Anzahl von System-Apps (z. B. bootstat und init) kann diese Eigenschaft überschreiben, aber allen Apps können sepolicy-Rechte zum Lesen dieser Eigenschaft gewährt werden.
• Nutzer über den Startgrund informieren, damit sie warten, bis die Nutzerdaten gemountet sind, bevor sie dem Inhalt der Eigenschaft für den Systemstartgrund vertrauen.system_boot_reason_prop

Warum so spät? bootloader_boot_reason_prop ist zwar früh im Bootvorgang verfügbar, wird aber bei Bedarf durch die Android-Sicherheitsrichtlinie blockiert, da es ungenaue, nicht parsierbare und nicht kanonische Informationen enthält. In den meisten Fällen sollten nur Entwickler mit fundierten Kenntnissen des Boot-Systems auf diese Informationen zugreifen müssen. Eine verfeinerte, parsierbare und kanonische API für den Startgrund mit system_boot_reason_prop kann erst nach dem Mounten der Nutzerdaten zuverlässig und genau erfasst werden. Im Detail:

• Vor dem Einbinden von Nutzerdaten enthält system_boot_reason_prop den Wert aus bootloader_boot_reason_prop.
• Nachdem die Nutzerdaten eingebunden wurden, kann system_boot_reason_prop aktualisiert werden, um den Richtlinien zu entsprechen oder genauere Informationen zu liefern.

Aus diesem Grund wird in Android 9 der Zeitraum verlängert, bevor der Boot-Grund offiziell abgerufen werden kann. Er ist nicht mehr sofort beim Booten verfügbar (mit bootloader_boot_reason_prop), sondern erst, nachdem die Nutzerdaten gemountet wurden (mit system_boot_reason_prop).

Die Bootstat-Logik hängt von einem informativeren und konformen bootloader_boot_reason_prop ab. Wenn für diese Eigenschaft ein vorhersagbares Format verwendet wird, verbessert sich die Genauigkeit aller kontrollierten Neustart- und Herunterfahrszenarien. Das wiederum verbessert und erweitert die Genauigkeit und Bedeutung von system_boot_reason_prop.

Kanonisches Format für den Boot-Grund

Das kanonische Format für den Bootvorgangsgrund für bootloader_boot_reason_prop in Android 9 hat die folgende Syntax:

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

Formatierungsregeln:

• Kleinschreibung
• Keine Leerzeichen (Unterstrich verwenden)
• Alle druckbaren Zeichen
• Durch Kommas getrennte reason, subreason und eine oder mehrere detail-Instanzen.
  • Eine erforderliche reason, die 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 der Gründe für den Neustart oder das Herunterfahren des Geräts enthält (oder wer das Gerät neu gestartet oder heruntergefahren hat).
  • Mindestens ein optionaler detail-Wert. 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 in der Regel einer Hierarchie der Wichtigkeit folgen sollten. Es ist jedoch auch zulässig, mehrere detail-Werte von gleicher Wichtigkeit anzugeben.

Ein leerer Wert für bootloader_boot_reason_prop gilt als unzulässig, da andere Agents dadurch nachträglich einen Boot-Grund einfügen können.

Anforderungen an den Grund

Der für reason (erster Zeitraum vor Beendigung oder Komma) angegebene Wert muss aus der folgenden Menge stammen, die in die Kategorien „Kern“, „Stark“ und „Schwach“ unterteilt ist:

• kernel set:
  • "watchdog"
  • "kernel_panic"
• Starkes Set:
  • "recovery"
  • "bootloader"
• Blunt-Set:
  • "cold": Weist in der Regel auf ein vollständiges Zurücksetzen aller Geräte hin, einschließlich des Speichers.
  • "hard": Gibt in der Regel an, dass der Zustand der Hardware zurückgesetzt wurde und ramoops dauerhafte Inhalte beibehalten sollte.
  • "warm": Im Allgemeinen bedeutet das, dass der Speicher und die Geräte einen bestimmten Status beibehalten und der ramoops-Sicherungsspeicher (siehe pstore-Treiber im Kernel) dauerhafte Inhalte enthält.
  • "shutdown"
  • "reboot": Das bedeutet in der Regel, dass der ramoops-Status und der Hardwarestatus unbekannt sind. Dieser Wert ist ein Sammelbegriff, da die Werte cold, hard und warm Hinweise auf die Tiefe des Zurücksetzens für das Gerät geben.

Bootloader müssen einen Kernel-Satz oder einen stumpfen Satz reason bereitstellen und es wird dringend empfohlen, einen subreason bereitzustellen, wenn er bestimmt werden kann. Wenn beispielsweise die Ein/Aus-Taste lange gedrückt wird, was möglicherweise ramoops-Backups zur Folge hat, ist der Boot-Grund "reboot,longkey".

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

Die Gründe für den Bootvorgang sollten nicht nur für interne Experten verständlich sein und/oder sollten in einem intuitiven Bericht menschenlesbar sein. Beispiele: "shutdown,vbxd" (schlecht), "shutdown,uv" (besser), "shutdown,undervoltage" (bevorzugt).

Kombinationen aus Grund und untergeordnetem Grund

Android reserviert eine Reihe von reason-subreason-Kombinationen, die bei normaler Verwendung nicht überladen 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-Changelog-Verlauf im Android-Quell-Repository.

Gründe für den Start melden

Alle Boot-Gründe, entweder vom Bootloader oder im kanonischen Boot-Grund aufgezeichnet, müssen im Abschnitt kBootReasonMap von system/core/bootstat/bootstat.cpp aufgezeichnet werden. Die Liste kBootReasonMap enthält sowohl konforme als auch nicht konforme Gründe aus der alten Richtlinie. 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, richtlinienkonforme Einträge in system/core/bootstat/bootstat.cpp zu verwenden und mit der Verwendung eines nicht richtlinienkonformen Strings zurückhaltend zu sein. Als Richtlinie gilt:

• OK, um "kernel_panic" über den Bootloader zu melden, da bootstat möglicherweise ramoops auf kernel_panic signatures prüfen kann, um die untergeordneten Gründe in den kanonischen system_boot_reason_prop zu verfeinern.
• Nicht in Ordnung, um einen nicht konformen String in kBootReasonMap zu melden (z. B. "panic") aus dem Bootloader), da dies letztendlich die Möglichkeit beeinträchtigt, die reason zu optimieren.

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

• Ändern Sie den Wert in "watchdog,bark" und fügen Sie ihn der Liste in kBootReasonMap hinzu.
• Überlegen Sie, was "bark" für Personen bedeutet, die mit der Technologie nicht vertraut sind, und prüfen Sie, ob eine aussagekräftigere subreason verfügbar ist.

Boot-Grund auf Einhaltung prüfen

Derzeit gibt es in Android keinen aktiven CTS-Test, mit dem alle möglichen Boot-Gründe, die ein Bootloader liefern könnte, genau ausgelöst oder geprüft werden können. Partner können jedoch versuchen, einen passiven Test durchzuführen, um die Kompatibilität zu ermitteln.

Daher müssen Bootloader-Entwickler freiwillig die oben beschriebenen Regeln und Richtlinien einhalten, um die Bootloader-Konformität zu gewährleisten. Wir bitten solche Entwickler, zu AOSP beizutragen (insbesondere zu system/core/bootstat/bootstat.cpp) und dieses Forum für Diskussionen über Probleme mit dem Boot-Grund zu nutzen.