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
ListekBootReasonMap
.
- Indiquez des raisons canoniques, analysables et reconnaissables pour
- 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 (commebootstat
etinit
) 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 debootloader_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 instancesdetail
.- 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é lasubreason
. Vous pouvez spécifier plusieurs Les valeursdetail
, qui doivent généralement respecter une hiérarchie de l'importance. Toutefois, vous pouvez signaler plusieursdetail
valeurs d'importance égale.
- Un élément
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 etramoops
doit conserver un contenu persistant."warm"
Indique généralement la mémoire et les appareils conserver un état, et leramoops
(voirpstore
du pilote dans le noyau) contient du contenu persistant."shutdown"
"reboot"
Cela signifie généralement que l'étatramoops
est inconnu et l'état du matériel est inconnu. Cette valeur est un critère générique, Les valeurscold
,hard
etwarm
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 dethermald
)"shutdown,battery"
"shutdown,battery,thermal"
(à partir deBatteryStatsService
)."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é).
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, carbootstat
peut inspecterramoops
pourkernel_panic signatures
afin d'affiner le dans lesystem_boot_reason_prop
canonique. - Non autorisé pour signaler une chaîne non conforme dans
kBootReasonMap
(par exemple,"panic")
de car cela empêchait d'affinerreason
Par exemple, si kBootReasonMap
contient "wdog_bark"
,
le développeur d'un bootloader doit:
- Remplacer par
"watchdog,bark"
et ajouter à la liste danskBootReasonMap
- Réfléchissez à ce que
"bark"
signifie pour ceux qui ne connaissent pas et déterminer si unsubreason
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.