Grund für kanonischen Start

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 teilnehmen kBootReasonMap-Liste.
  • 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 und init) 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 aus bootloader_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 mehr detail 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. Ein detail auf ein Subsystem verweisen kann, um zu bestimmen, führten zu folgendem Ergebnis: subreason. Sie können mehrere detail-Werte, die in der Regel einer Hierarchie von Bedeutung. Es ist jedoch auch akzeptabel, mehrere detail Werte von gleicher Bedeutung.

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 und ramoops sollten persistente Inhalte beibehalten.
    • "warm" Gibt in der Regel den Arbeitsspeicher und die Geräte an einen Zustand beibehalten und das ramoops (siehe pstore) Treiber im Kernel) enthält.
    • "shutdown"
    • "reboot" Im Allgemeinen bedeutet das, dass der Status ramoops unbekannt und der Hardwarestatus ist unbekannt. Dieser Wert ist ein universeller Wert, da der Wert Die Werte cold, hard und warm 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" (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 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).

<ph type="x-smartling-placeholder">

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, da bootstat möglicherweise die Datei ramoops für kernel_panic signatures, um die Untergründe in die kanonische system_boot_reason_prop einfügen.
  • Nicht OK, um einen nicht konformen String in kBootReasonMap (z. B. "panic") aus der Bootloader, da dies die Optimierung der reason

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

  • In "watchdog,bark" ändern und der Liste hinzufügen in kBootReasonMap.
  • Überlegen Sie, was "bark" für diejenigen bedeutet, die noch nicht mit dem und ermitteln, ob eine aussagekräftigere subreason 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.