Canonical Boot-Grund

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

Boot-Gründe

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

Spezifikationen für den Startgrund

Frühere Android-Versionen spezifizierten ein Startgrundformat, das keine Leerzeichen verwendete, nur in Kleinbuchstaben geschrieben war, nur wenige Anforderungen enthielt (z. B. für die Meldung von kernel_panic , watchdog , cold / warm / hard ) und andere einzigartige Gründe berücksichtigte. Diese lockere Spezifikation führte zur Verbreitung von Hunderten benutzerdefinierter (und manchmal bedeutungsloser) Startursachenzeichenfolgen, was wiederum zu einer unüberschaubaren Situation führte. Seit der aktuellen Android-Version hat die schiere Dynamik der vom Bootloader eingereichten, nahezu nicht analysierbaren oder bedeutungslosen Inhalte zu Compliance-Problemen für bootloader_boot_reason_prop geführt.

Mit der Veröffentlichung von Android 9 erkennt das Android-Team, dass das alte bootloader_boot_reason_prop eine erhebliche Dynamik aufweist und zur Laufzeit nicht neu geschrieben werden kann. Jegliche Verbesserungen der Boot-Grundspezifikation müssen daher durch Interaktionen mit Bootloader-Entwicklern und Optimierungen am vorhandenen System erfolgen. Zu diesem Zweck besteht das Android-Team aus:

• Zusammenarbeit mit Bootloader-Entwicklern, um sie zu Folgendem zu ermutigen:
  • Geben Sie kanonische, analysierbare und erkennbare Gründe für bootloader_boot_reason_prop an.
  • Nehmen Sie an der kBootReasonMap Liste system/core/bootstat/bootstat.cpp teil.
• Hinzufügen einer kontrollierten und zur Laufzeit wiederbeschreibbaren Quelle von system_boot_reason_prop ( sys.boot.reason ). Eine begrenzte Anzahl von Systemanwendungen (z. B. bootstat und init ) kann diese Eigenschaft umschreiben, aber allen Anwendungen können separate Leserechte gewährt werden.
• Informieren Sie Benutzer über den Startgrund und warten Sie, bis die Benutzerdaten gemountet sind, bevor Sie dem Inhalt in der Systemstartgrundeigenschaft system_boot_reason_prop vertrauen.

Warum so spät? Während bootloader_boot_reason_prop zu Beginn des Bootvorgangs verfügbar ist, wird es von der Android-Sicherheitsrichtlinie bei Bedarf blockiert, da es ungenaue, nicht analysierbare und nicht kanonische Informationen darstellt. In den meisten Situationen sollten nur Entwickler mit umfassenden Kenntnissen des Bootsystems auf diese Informationen zugreifen müssen. Eine verfeinerte, analysierbare und kanonische API für den Startvorgang über system_boot_reason_prop kann erst zuverlässig und genau erfasst werden , nachdem die Benutzerdaten bereitgestellt wurden. Speziell:

• Bevor die Benutzerdaten gemountet wurden, enthält system_boot_reason_prop den Wert von bootloader_boot_reason_prop .
• Nachdem die Benutzerdaten gemountet wurden, kann system_boot_reason_prop aktualisiert werden, um konform zu sein oder genauere Informationen zu melden.

Aus diesem Grund verlängert Android 9 den Zeitraum, bevor der Startgrund offiziell ermittelt werden kann, und ändert ihn von der sofortigen Genauigkeit beim Start (mit bootloader_boot_reason_prop ) auf die Verfügbarkeit erst, nachdem die Benutzerdaten gemountet wurden (mit system_boot_reason_prop ).

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

Kanonisches Format für den Startgrund

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

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

Formatierungsregeln:

• Kleinbuchstaben
• Keine Leerzeichen (Unterstreichung verwenden)
• Alle druckbaren Zeichen
• Durch Kommas getrennter reason , subreason und ein oder mehrere detail .
  • Ein erforderlicher reason , der den Grund mit der höchsten Priorität darstellt, warum das Gerät neu gestartet oder heruntergefahren werden musste.
  • Ein optionaler subreason , der eine kurze Zusammenfassung darüber darstellt, 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 . Ein detail kann auf ein Subsystem verweisen, um bei der Bestimmung zu helfen, welches spezifische System zu dem subreason geführt hat. Sie können mehrere detail angeben, die im Allgemeinen einer Wichtigkeitshierarchie folgen sollten. Es ist jedoch auch akzeptabel, mehrere detail gleicher Bedeutung zu melden.

Ein leerer Wert für bootloader_boot_reason_prop wird als illegal angesehen (da dies es anderen Agenten ermöglicht, nachträglich einen Startgrund einzufügen).

Grundanforderungen

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

• Kernel-Set:
  • „ watchdog"
  • "kernel_panic"
• starker Satz:
  • "recovery"
  • "bootloader"
• stumpfes Set:
  • "cold" . Zeigt im Allgemeinen einen vollständigen Reset aller Geräte an, einschließlich des Speichers.
  • "hard" . Zeigt im Allgemeinen an, dass der Status der Hardware zurückgesetzt wurde und ramoops persistente Inhalte behalten sollten.
  • "warm" . Zeigt im Allgemeinen an, dass der Speicher und die Geräte einen gewissen Zustand behalten und der ramoops Backup-Speicher (siehe pstore Treiber im Kernel) persistenten Inhalt enthält.
  • "shutdown"
  • "reboot" . Im Allgemeinen bedeutet dies, dass der ramoops Status unbekannt ist und der Hardware-Status unbekannt ist. Dieser Wert ist ein Sammelbegriff, da die Werte cold “, hard “ und warm “ Hinweise auf die Tiefe des Zurücksetzens des Geräts geben.

Bootloader müssen einen Kernel-Set- oder Blunt-Set- reason angeben und es wird dringend empfohlen, einen subreason anzugeben, wenn dieser ermittelt werden kann. Beispielsweise hätte ein langes Drücken der Ein-/Aus-Taste, das möglicherweise über ramoops Sicherung verfügt oder nicht, den Startgrund "reboot,longkey" .

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

Boot-Gründe sollten zur Entschlüsselung kein internes Expertenwissen erfordern und/oder mit einem intuitiven Bericht für Menschen lesbar sein. Beispiele: "shutdown,vbxd" (schlecht), "shutdown,uv" (besser), "shutdown,undervoltage" (bevorzugt).

Grund-Untergrund-Kombinationen

Android behält sich eine Reihe von Kombinationen aus reason und subreason vor, die bei normaler Verwendung nicht überlastet sein sollten, aber von Fall zu Fall verwendet werden können, wenn die Kombination die zugehörige Bedingung genau widerspiegelt. Beispiele für reservierte Kombinationen sind:

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

Weitere Einzelheiten finden Sie unter kBootReasonMap in system/core/bootstat/bootstat.cpp und im zugehörigen Git-Changelog-Verlauf im Android-Quell-Repository.

Startgründe melden

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

Wir empfehlen dringend, vorhandene, konforme Einträge in system/core/bootstat/bootstat.cpp zu verwenden und Zurückhaltung zu üben, bevor Sie eine nicht konforme Zeichenfolge verwenden. Als Richtwert gilt:

• OK, um "kernel_panic" vom Bootloader zu melden, da bootstat möglicherweise ramoops auf kernel_panic signatures untersuchen kann, um die Untergründe in das kanonische system_boot_reason_prop zu verfeinern.
• Es ist nicht in Ordnung , eine nicht konforme Zeichenfolge in kBootReasonMap (z. B. "panic") vom Bootloader zu melden, da dies letztendlich die Möglichkeit zur Verfeinerung des reason beeinträchtigt.

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

• Wechseln Sie zu "watchdog,bark" und fügen Sie es der Liste in kBootReasonMap hinzu.
• Überlegen Sie, was "bark" für diejenigen bedeutet, die mit der Technologie nicht vertraut sind, und stellen Sie fest, ob ein aussagekräftigerer subreason verfügbar ist.

Überprüfen der Einhaltung der Startgründe

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

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