Motif du démarrage canonique

Android 9 inclut les modifications suivantes apportées à la spécification du motif de démarrage du bootloader.

Motifs de démarrage

Un bootloader utilise des ressources matérielles et de mémoire à disponibilité unique pour déterminer pourquoi un appareil a redémarré, puis communique cette détermination en en ajoutant androidboot.bootreason=<reason> à Android du noyau pour son lancement. init traduira ensuite ceci pour se propager à la propriété Android bootloader_boot_reason_prop (ro.boot.bootreason). Pour les appareils lancés avec Android 12 ou version ultérieure, utilisant la version 5.10 ou une version ultérieure du noyau, androidboot.bootreason=<reason> est ajouté à bootconfig à la place de la ligne de commande du noyau.

Spécifications du motif de démarrage

Les versions précédentes d'Android spécifiaient un format de motif de démarrage qui n'utilisait et d'espaces, était en minuscules et incluait peu d'exigences kernel_panic, watchdog cold/warm/hard), et qui a généré des quotas pour d'autres raisons uniques. Cette spécification globale a entraîné Prolifération de centaines de modèles de démarrage personnalisés (et parfois insignifiants) de chaînes, ce qui conduisait à une situation ingérable. À compter du Android, l'essor des contenus qui ne peuvent pas être analysés ou qui n'ont pas de sens déposée par le bootloader a créé des problèmes de conformité pour bootloader_boot_reason_prop

Avec le lancement d'Android 9, l'équipe Android reconnaît que l'ancienne bootloader_boot_reason_prop comporte ne peuvent pas être réécrites au moment de l'exécution. Toute amélioration apportée à la spécification du motif de démarrage doit donc provenir d'interactions avec développeurs de bootloaders et des ajustements du système existant. C'est pourquoi L'équipe Android est:

• Interagir avec les développeurs de bootloaders pour les encourager à: <ph type="x-smartling-placeholder">
  </ph>
  • Indiquez des raisons canoniques, analysables et reconnaissables pour bootloader_boot_reason_prop
  • Participer au system/core/bootstat/bootstat.cpp Liste kBootReasonMap.
• Ajout d'une source contrôlée et réinscriptible pendant l'exécution de la system_boot_reason_prop (sys.boot.reason). A ensemble limité d'applications système (comme bootstat et init) peut réécrire cette propriété, mais toutes les applications peuvent l'être a reçu le droit sepolicy de le lire.
• Informer les utilisateurs du motif d'attente avant l'installation des données utilisateur avant de faire confiance au contenu de la propriété du motif de démarrage du système. system_boot_reason_prop

Pourquoi si tard ? Bien que bootloader_boot_reason_prop soit disponible en avance activé au démarrage, il est bloqué par la stratégie de sécurité Android au besoin. car elles représentent des informations inexactes, impossibles à analyser et non canoniques. Dans la plupart des cas, seuls les développeurs ayant une connaissance approfondie du système de démarrage devraient avoir besoin d'accéder à ces informations. Une interface affinée, analysable et canonique L'API pour le démarrage avec system_boot_reason_prop peut être fiable et ne sont collectées avec précision qu'après l'installation des données utilisateur. Plus spécifiquement :

• Avant l'installation des données utilisateur, system_boot_reason_prop contiendra la valeur de bootloader_boot_reason_prop
• Après l'installation des données utilisateur, system_boot_reason_prop peut être mis à jour pour être conforme ou pour signaler des informations plus précises.

C'est pourquoi Android 9 prolonge la période avant que le motif de démarrage puisse être officiellement acquis, précise immédiatement au démarrage (avec bootloader_boot_reason_prop) de sorte qu'elles ne soient disponibles qu'après l'installation de userdata (avec system_boot_reason_prop).

La logique de Bootstat repose sur une approche plus informative et conforme bootloader_boot_reason_prop Lorsque cette propriété utilise un format prévisible, améliore la précision de tous les redémarrages contrôlés et ce qui permet d'affiner et d'améliorer la précision sur system_boot_reason_prop.

Format du motif de démarrage canonique

Format du motif de démarrage canonique pour bootloader_boot_reason_prop sous Android 9 utilise la syntaxe suivante:

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

Règles de mise en forme:

• Tout en minuscules
• Pas de blancs (trait de soulignement)
• Tous les caractères imprimables
• Séparés par des virgules reason, subreason et un ou autres instances detail.
  • Un élément reason obligatoire représentant la priorité la plus élevée la raison pour laquelle l’appareil a dû redémarrer ou s’éteindre.
  • Un élément subreason facultatif qui représente un bref résumé pourquoi l'appareil a dû redémarrer ou s'éteindre (ou qui a redémarré ou arrêté appareil).
  • Une ou plusieurs valeurs detail facultatives. detail peuvent pointer vers un sous-système pour aider à déterminer quel système spécifique a généré la subreason. Vous pouvez spécifier plusieurs Les valeurs detail, qui doivent généralement respecter une hiérarchie de l'importance. Toutefois, vous pouvez signaler plusieurs detail valeurs d'importance égale.

Une valeur vide pour bootloader_boot_reason_prop est considérée comme illégal (car cela permet à d'autres agents d'injecter un motif de démarrage après coup).

Exigences concernant les motifs

La valeur donnée pour reason (premier segment, avant la fin ou virgule) doit être de l'un des ensembles suivants, divisé en noyau, fort et émoussé raisons:

• noyau défini: <ph type="x-smartling-placeholder">
  </ph>
  • "watchdog"
  • "kernel_panic"
• ensemble fort: <ph type="x-smartling-placeholder">
  </ph>
  • "recovery"
  • "bootloader"
• émoussée: <ph type="x-smartling-placeholder">
  </ph>
  • "cold" Indique généralement une réinitialisation complète de tous les appareils, dont la mémoire.
  • "hard" Indique généralement que le matériel a son état réinitialisés et ramoops doit conserver un contenu persistant.
  • "warm" Indique généralement la mémoire et les appareils conserver un état, et le ramoops (voir pstore du pilote dans le noyau) contient du contenu persistant.
  • "shutdown"
  • "reboot" Cela signifie généralement que l'état ramoops est inconnu et l'état du matériel est inconnu. Cette valeur est un critère générique, Les valeurs cold, hard et warm fournissent des indices quant à la profondeur de la réinitialisation de l'appareil.

Les bootloaders doivent fournir un ensemble de noyau ou un reason d'ensemble arrondi ; et nous vous recommandons vivement de fournir un subreason s'il peut être déterminé. Par exemple, un appui prolongé sur le bouton Marche/Arrêt peut avoir Le motif de démarrage de la sauvegarde ramoops serait "reboot,longkey"

Aucun élément reason de premier segment ne peut faire partie d'un élément subreason ou detail Cependant, comme les motifs de définition du noyau ne peuvent pas être produits par espace utilisateur, "watchdog" peut être réutilisé après un imprécision, ainsi qu'un détail sur la source (par exemple, "reboot,watchdog,service_manager_unresponsive" ou "reboot,software,watchdog").

Les motifs de démarrage ne doivent pas nécessiter de connaissances internes spécialisées pour déchiffrer et/ou doivent être lisibles par l'humain et générer un rapport intuitif. Exemples: "shutdown,vbxd" (mauvais), "shutdown,uv" (mieux), "shutdown,undervoltage" (recommandé)

Combinaisons motif/sous-motif

Android réserve un ensemble de reason à subreason qui ne doivent pas être surchargées dans le cadre d'une utilisation normale, mais qui peuvent être utilisées au cas par cas si la combinaison reflète avec précision . Exemples de combinaisons réservées:

• "reboot,userrequested"
• "shutdown,userrequested"
• "shutdown,thermal" (à partir de thermald)
• "shutdown,battery"
• "shutdown,battery,thermal" (à partir de BatteryStatsService).
• "reboot,adb"
• "reboot,shell"
• "reboot,bootloader"
• "reboot,recovery"

Pour en savoir plus, consultez kBootReasonMap dans system/core/bootstat/bootstat.cpp et l'instance Git associée dans le dépôt source Android.

Signaler les motifs de démarrage

Tous les motifs de démarrage, à partir du bootloader ou enregistrés dans le démarrage canonique motif, doit être enregistré dans la section kBootReasonMap de system/core/bootstat/bootstat.cpp La La liste kBootReasonMap inclut à la fois des éléments conformes et anciens motifs de non-conformité. Les développeurs de bootloaders ne doivent enregistrer que de conformité (et nous ne devrions pas enregistrer les motifs de non-conformité le produit a déjà été expédié et ne peut pas être modifié).

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

Nous vous recommandons vivement d'utiliser des entrées existantes conformes dans system/core/bootstat/bootstat.cpp et entraînement de la contrainte avant à l'aide d'une chaîne non conforme. À titre indicatif:

• OK pour signaler "kernel_panic" à partir du le bootloader, car bootstat peut inspecter ramoops pour kernel_panic signatures afin d'affiner le dans le system_boot_reason_prop canonique.
• Non autorisé pour signaler une chaîne non conforme dans kBootReasonMap (par exemple, "panic") de car cela empêchait d'affiner reason

Par exemple, si kBootReasonMap contient "wdog_bark", le développeur d'un bootloader doit:

• Remplacer par "watchdog,bark" et ajouter à la liste dans kBootReasonMap
• Réfléchissez à ce que "bark" signifie pour ceux qui ne connaissent pas et déterminer si un subreason plus pertinent est disponibles.

Vérifier la conformité du motif de démarrage

À l'heure actuelle, Android ne fournit pas de test CTS actif capable de détecter avec précision déclencher ou inspecter toutes les raisons possibles du démarrage qu’un bootloader pourrait fournir ; les partenaires peuvent toujours essayer d'exécuter un test passif pour déterminer la compatibilité.

Par conséquent, la conformité des bootloaders exige que les développeurs de bootloaders doivent respecter volontairement l'esprit des règles et des directives décrites ci-dessus. Nous encourageons vivement ces développeurs à contribuer à AOSP (en particulier system/core/bootstat/bootstat.cpp) et profitez de cette opportunité pour discuter des problèmes liés au démarrage.