Cette page décrit le schéma de gestion des versions pour les images de noyau génériques (GKI). A Image du noyau générique (GKI) a un identifiant unique appelé « version du noyau ». La version du noyau se compose de la version de l’interface de module du noyau (KMI) et du sous-niveau. Le noyau est spécifique à l'image qui est publiée, alors que la version KMI qui représente l'interface à partir de laquelle une version est compilée. Une version de KMI peut prendre en charge plusieurs versions du noyau. Une version de noyau est liée à une seule version de KMI. Dans l’éventualité peu probable où l’interface du module du noyau doit être modifiée, le KMI la génération est itérée pour refléter le changement de version du KMI.
Récapitulatif des conditions
Le tableau suivant récapitule les termes importants utilisés sur cette page et pour les mises à jour GKI.
| Nom | Symbole | Exemple | Description |
|---|---|---|---|
| Version du kernel | w.x.y-zzz-k-suffixe | 5.4.42-android12-0-foo | Identifiant unique d'une version GKI. Il s'agit de la valeur
renvoyé par uname. |
| Version du KMI | w.x-zzz-k | 5.4-android12-0 | Décrit l'interface de module de noyau (KMI) entre GKI et les modules de noyau chargeables dynamiquement (DLKM). |
| Sous-niveau | y | 42 | Décrit l'ordre de publication des versions du noyau dans le la même version de KMI. |
Le tableau suivant répertorie d'autres termes associés à titre de référence.
| Nom | Symbole | Exemple | Description |
|---|---|---|---|
| l.x.y | l.x.y | 5.4.42 |
Pour plus d'informations, consultez la section Linux Kernel Makefiles (recherchez "KERNELRelease"). w.x.y est utilisé directement tout au long de ce document. C'est aussi communément appelé numéro de version en trois parties. Le terme utilisé dans VINTF, version du noyau, peut prêter à confusion avec d'autres termes, en particulier w. Cette variable est appelée kernel_version_tuple dans libkver. Ce tuple ne doit pas être réduit par des mises à jour, y compris par OTA ou principal. |
| Branche du noyau | zzz-w.x | Android 12-5.4 | Ce terme est utilisé en . Types de branches de noyau courants. |
| Version | z | 5 | Ce terme n'est pas utilisé dans ce document. Cette variable est appelée version dans libkver. |
| Niveau de correctif | x | 4 | Ce terme n'est pas utilisé dans ce document. Cette variable est appelée patch_level dans libkver |
| Version d'Android | zzz | Android 12 |
Il s'agit du numéro de version Android (dessert) auquel le noyau est associé .
Lorsque vous comparez le champ Le nombre de versions d'Android ne doit pas être diminué par des mises à jour, y compris OTA ou principale. |
| Génération de KMI | k | 0 |
Il s'agit d'un chiffre supplémentaire ajouté pour traiter les cas improbables événements. Si une correction de bug de sécurité nécessite de modifier le KMI dans le même version Android, la génération de KMI est accrue. Le numéro de génération du KMI commence par 0. |
Conception de la gestion des versions
Version du kernel
Définition
Pour les appareils équipés de GKI, la version du noyau est définie comme suit:
KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w .x .y -zzz -k -something
Pour plus d'informations, consultez Déterminer la version du noyau à partir d'un appareil.
Voici un exemple de version de noyau.
5.4.42-android12-0-00544-ged21d463f856
Description
La version du noyau est l'identifiant unique d'une version GKI. Si deux binaires GKI ont la même version du noyau, ils doivent être identiques au niveau des octets.
Une version de noyau se compose d'une version KMI, d'un sous-niveau et d'un suffixe. Pour pour les besoins de ce document, le suffixe après la génération du KMI est ignoré.
Version du KMI
Définition
La version KMI est définie comme suit:
KmiVersion :=
Version.PatchLevel-AndroidRelease-KmiGeneration
w .x -zzz -k
Notez que le sous-niveau y ne fait pas partie de la version de KMI. Pour l'exemple
dans Kernel release, la version de KMI est la suivante:
5.4-android12-0
Description
La version KMI décrit l’interface de module du noyau (KMI) entre GKI et les modules de noyau chargeables dynamiquement (DLKM).
Si deux versions de noyau ont la même version de KMI, elles mettent en œuvre le même noyau de l'interface du module. Les DLKM qui en sont compatibles le sont également avec l'autre.
La version du KMI ne doit pas être réduite par une mise à jour OTA.
Sous-niveau
Le sous-niveau, y, décrit l'ordre de publication des versions du noyau dans le
la même version de KMI.
Pour deux versions de noyau ayant la même version de KMI, mais ayant un sous-niveau Y1 et Y2 respectivement:
- Si Y1 est inférieur ou égal à Y2, un appareil exécutant Y1 peut recevoir une passer à Y2.
- Si Y1 est supérieur à Y2, un appareil exécutant Y1 ne peut pas être mis à jour vers Y2.
Autrement dit, si la version du KMI ne change pas, le sous-niveau ne doit pas être réduit par une mise à jour OTA.
Déterminer la version du noyau à partir d'un appareil
Vous pouvez obtenir la version complète du noyau en exécutant uname -r, ou
uname(2)
à l'aide de l'extrait de code suivant:
std::string get_kernel_release() {
struct utsname buf;
return uname(&buf) == 0 ? buf.release : "";
}
Voici un exemple de résultat:
5.4.42-android12-0-00544-ged21d463f856
Pour les besoins de ce document, tout ce qui figure après la génération du KMI est ignoré.
lors de l'extraction des informations du noyau. Plus formellement, la sortie de uname -r est
analysés avec l'expression régulière suivante :
(en supposant que zzz commence toujours par "android"):
^(?P<w>\d+)[.](?P<x>\d+)[.](?P<y>\d+)-(?P<z>android\d+)-(?P<k>\d+).*$
Les informations ignorées peuvent inclure numéro de build ci.android.com, nombre de des correctifs au-dessus du noyau de référence et des hachages SHA du commit Git.
Libkver
La bibliothèque, libkver, fournit une interface C++ pour analyser la version du noyau ou
Chaîne de version KMI. Pour obtenir la liste des API exposées par libkver, consultez
packages/modules/Gki/libkver/include/kver
Vérifications VINTF
Pour Android 11 ou version antérieure, la partie Android de la version KMI est spécifiés manuellement dans le fichier manifeste de l'appareil par les fabricants. Pour en savoir plus, voir Règles de correspondance de noyau VINTF.
À partir d'Android S, la partie Android de la version KMI peut être extraite du noyau et injecté dans le fichier manifeste de l'appareil au moment de la compilation.
Comme les exigences de configuration du
noyau ne changent généralement pas,
vous devez encoder k dans la matrice de compatibilité. Cependant, dans le cas peu probable
dans le cas où l'exigence de configuration
du noyau doit être modifiée, assurez-vous
les éléments suivants:
- L'exigence correspondante de la matrice de compatibilité est supprimée.
- Des tests VTS supplémentaires sont ajoutés pour vérifier les nouvelles exigences. sur la génération de KMI.
Version de l'image de démarrage dans les métadonnées OTA
Même si l'image de démarrage est mise à jour via une mise à jour OTA, elle doit être
encapsulé dans le format de charge utile OTA, payload.bin. La charge utile OTA encode
version pour chaque partition. Lorsque update_engine gère une charge utile OTA,
il compare ce champ pour s'assurer que
la partition n'est pas rétrogradée.
Pour éviter toute confusion, le champ version de la partition de démarrage dans l'OTA
s'appelle boot image version.
Comme le ramdisk est toujours créé à partir de zéro, l'utilisation de la commande ramdisk code temporel est suffisant pour décrire l'ensemble de l'image de démarrage. Il n'est pas nécessaire encodez la version du noyau dans la version de l'image de démarrage, sauf si vous assemblez une ancienne version l'image de démarrage vers un nouveau binaire de noyau à l'avenir.
Avant une mise à jour OTA, le client OTA vérifie la version de l'image de démarrage. de la même manière que toute autre partition.