Raison canonique du démarrage

Android 9 inclut les modifications suivantes dans la spécification du motif de démarrage du chargeur de démarrage.

Raisons de démarrage

Un chargeur de démarrage utilise des ressources matérielles et mémoire disponibles de manière unique pour déterminer pourquoi un périphérique a redémarré, puis communique cette détermination en ajoutant androidboot.bootreason=<reason> à la ligne de commande du noyau Android pour son lancement. init traduit ensuite cette ligne de commande pour la 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 ultérieure du noyau, androidboot.bootreason=<reason> est ajouté à bootconfig au lieu 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 raison de démarrage qui n'utilisait aucun espace, était entièrement en minuscules, incluait quelques exigences (telles que pour signaler kernel_panic , watchdog , cold / warm / hard ) et prenait en compte d'autres raisons uniques. Cette spécification vague a entraîné la prolifération de centaines de chaînes de raisons de démarrage personnalisées (et parfois dénuées de sens), ce qui a conduit à une situation ingérable. Depuis la version actuelle d'Android, l'élan du contenu presque impossible à analyser ou dénué de sens déposé par le chargeur de démarrage a créé des problèmes de conformité pour bootloader_boot_reason_prop .

Avec la version Android 9, l'équipe Android reconnaît que l'ancien bootloader_boot_reason_prop a un élan considérable et ne peut pas être réécrit au moment de l'exécution. Toute amélioration de la spécification du motif de démarrage doit donc provenir d'interactions avec les développeurs du chargeur de démarrage et d'ajustements du système existant. À cette fin, l'équipe Android est :

• S'engager auprès des développeurs de chargeurs de démarrage pour les encourager à :
  • Fournissez des raisons canoniques, analysables et reconnaissables à bootloader_boot_reason_prop .
  • Participez à la liste system/core/bootstat/bootstat.cpp kBootReasonMap .
• Ajout d'une source contrôlée et réinscriptible à l'exécution de system_boot_reason_prop ( sys.boot.reason ). Un ensemble limité d'applications système (telles que bootstat et init ) peuvent réécrire cette propriété, mais toutes les applications peuvent se voir accorder des droits de sécurité pour la lire.
• Informer les utilisateurs de la raison de démarrage à attendre après le montage des données utilisateur avant de faire confiance au contenu de la propriété de raison de démarrage du système system_boot_reason_prop .

Pourquoi si tard? Bien que bootloader_boot_reason_prop soit disponible dès le démarrage, il est bloqué par la politique de sécurité Android en fonction des besoins, car il représente des informations inexactes, impossibles à analyser et non canoniques. Dans la plupart des situations, seuls les développeurs ayant une connaissance approfondie du système de démarrage devraient avoir besoin d'accéder à ces informations. Une API raffinée, analysable et canonique pour la raison de démarrage via system_boot_reason_prop ne peut être récupérée de manière fiable et précise qu'après le montage des données utilisateur. Spécifiquement:

• Avant le montage des données utilisateur, system_boot_reason_prop contiendra la valeur de bootloader_boot_reason_prop .
• Une fois les données utilisateur montées, system_boot_reason_prop peut être mis à jour pour être conforme ou pour signaler des informations plus précises.

Pour cette raison, Android 9 prolonge le délai avant que la raison de démarrage puisse être officiellement acquise, la faisant passer d'une précision immédiate au démarrage (avec bootloader_boot_reason_prop ) à une disponibilité uniquement après le montage des données utilisateur (avec system_boot_reason_prop ).

La logique de démarrage dépend d'un bootloader_boot_reason_prop plus informatif et conforme. Lorsque cette propriété utilise un format prévisible, elle améliore la précision de tous les scénarios de redémarrage et d'arrêt contrôlés, ce qui à son tour affine et étend la précision et la signification de system_boot_reason_prop .

Format canonique du motif de démarrage

Le format canonique de motif de démarrage pour bootloader_boot_reason_prop dans Android 9 utilise la syntaxe suivante :

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

Règles de formatage :

• Minuscules
• Pas de blancs (utilisez le soulignement)
• Tous les caractères imprimables
• Raison, subreason - reason et un ou plusieurs detail séparés par des virgules.
  • reason obligatoire qui représente la raison la plus prioritaire pour laquelle le périphérique a dû redémarrer ou s'arrêter.
  • subreason facultative qui représente un bref résumé de la raison pour laquelle le périphérique a dû redémarrer ou s'arrêter (ou qui a redémarré ou arrêté le périphérique).
  • Une ou plusieurs valeurs detail facultatives. Un detail peut pointer vers un sous-système pour aider à déterminer quel système spécifique a abouti à la subreason . Vous pouvez spécifier plusieurs valeurs detail , qui doivent généralement suivre une hiérarchie d'importance. Cependant, il est également acceptable de déclarer plusieurs valeurs detail d’égale importance.

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

Exigences de motif

La valeur donnée pour reason (première étendue, avant la terminaison ou la virgule) doit appartenir à l'ensemble suivant, divisé en raisons fondamentales, fortes et brutales :

• ensemble de noyau :
  • " watchdog"
  • "kernel_panic"
• ensemble fort :
  • "recovery"
  • "bootloader"
• ensemble émoussé :
  • "cold" . Indique généralement une réinitialisation complète de tous les appareils, y compris la mémoire.
  • "hard" . Indique généralement que l'état du matériel est réinitialisé et ramoops doivent conserver le contenu persistant.
  • "warm" . Indique généralement que la mémoire et les périphériques conservent un certain état et que le magasin de sauvegarde ramoops (voir le pilote pstore dans le noyau) contient du contenu persistant.
  • "shutdown"
  • "reboot" . Cela signifie généralement que l'état ramoops est inconnu et que l'état du matériel est inconnu. Cette valeur est fourre-tout, car les valeurs cold , hard et warm fournissent des indices sur la profondeur de la réinitialisation de l'appareil.

Les chargeurs de démarrage doivent fournir un ensemble de noyau ou une reason simple, et sont fortement encouragés à fournir une subreason si elle peut être déterminée. Par exemple, un appui long sur la touche d'alimentation qui peut ou non avoir une sauvegarde ramoops aurait la raison de démarrage "reboot,longkey" .

Aucune reason de première tranche ne peut faire partie d'une subreason ou detail . Cependant, comme les raisons définies par le noyau ne peuvent pas être produites par l'espace utilisateur, "watchdog" peut être réutilisé après une raison définie brutalement, avec un détail de la source (par exemple "reboot,watchdog,service_manager_unresponsive" ou "reboot,software,watchdog" ).

Les raisons de démarrage ne doivent pas nécessiter de connaissances internes expertes pour être déchiffrées et/ou doivent être lisibles par un humain avec un rapport intuitif. Exemples : "shutdown,vbxd" (mauvais), "shutdown,uv" (meilleur), "shutdown,undervoltage" (préféré).

Combinaisons raison-sous-raison

Android réserve un ensemble de combinaisons reason et subreason -raison 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 la condition associée. Voici des exemples de combinaisons réservées :

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

Pour plus de détails, reportez-vous à kBootReasonMap dans system/core/bootstat/bootstat.cpp et à l'historique du journal des modifications git associé dans le référentiel source Android.

Signalement des raisons de démarrage

Toutes les raisons de démarrage, qu'elles proviennent du chargeur de démarrage ou enregistrées dans la raison de démarrage canonique, doivent être enregistrées dans la section kBootReasonMap de system/core/bootstat/bootstat.cpp . La liste kBootReasonMap est un mélange de raisons conformes et non conformes. Les développeurs de chargeurs de démarrage doivent enregistrer ici uniquement les nouvelles raisons de conformité (et ne doivent pas enregistrer les raisons de non-conformité, sauf si le produit a déjà été expédié et ne peut pas être modifié).

Nous vous recommandons fortement d'utiliser des entrées conformes existantes dans system/core/bootstat/bootstat.cpp et de faire preuve de retenue avant d'utiliser une chaîne non conforme. A titre indicatif, il s'agit de :

• OK pour signaler "kernel_panic" à partir du chargeur de démarrage, car bootstat peut être en mesure d'inspecter ramoops pour kernel_panic signatures afin d'affiner les sous-raisons dans le système canonique system_boot_reason_prop .
• Ce n'est pas OK de signaler une chaîne non conforme dans kBootReasonMap (telle que "panic") à partir du chargeur de démarrage, car cela finira par interrompre la possibilité d'affiner la reason .

Par exemple, si kBootReasonMap contient "wdog_bark" , un développeur de chargeur de démarrage doit :

• Remplacez par "watchdog,bark" et ajoutez-le à la liste dans kBootReasonMap .
• Réfléchissez à ce que "bark" signifie pour ceux qui ne connaissent pas la technologie et déterminez si une subreason plus significative est disponible.

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

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

En conséquence, la conformité du chargeur de démarrage exige que les développeurs de chargeurs de démarrage adhèrent volontairement à l'esprit des règles et directives décrites ci-dessus. Nous exhortons ces développeurs à contribuer à l'AOSP (en particulier à system/core/bootstat/bootstat.cpp ) et à utiliser cette opportunité comme forum pour discuter des problèmes de raison de démarrage.