Processus de publication d'une image de noyau générique (GKI)

Cette page décrit comment GKI est publié, y compris les versions trimestrielles et les versions d'urgence hors bande. L'objectif de cette page est de fournir aux OEM des instructions sur l'endroit où récupérer le GKI, ainsi que sur la procédure à suivre pour les correctifs d'urgence hors bande. Les OEM peuvent également utiliser le développement GKI pour en savoir plus sur la façon dont ils peuvent collaborer avec l'équipe Android Kernel afin d'optimiser le noyau GKI pour leurs produits.

Cadence de publication de GKI

GKI est publié tous les trimestres après le gel de KMI.

Validité de la compilation GKI pour les OEM

Les OEM peuvent utiliser un GKI Android publié récemment. Les OEM peuvent lancer des versions certifiées GKI à condition qu'elles soient conformes aux exigences du noyau LTS (Long-Term Supported) du bulletin sur la sécurité d'Android (ASB).

Versions certifiées trimestrielles

Les versions trimestrielles de GKI contiennent un boot.img testé qui inclut un certificat inséré par Google pour attester que les binaires ont été créés à partir d'une base de code source connue.

Chaque trimestre, un candidat à la publication trimestrielle GKI (non certifié) est sélectionné après la date limite d'enregistrement. Une fois la version candidate trimestrielle sélectionnée, les nouvelles modifications ne seront pas acceptées dans la version de ce mois-là. Pendant la période de fermeture, seules les corrections de bugs entraînant l'échec des tests peuvent être traitées. La version candidate est soumise à une assurance qualité, comme décrit dans la section sur la qualification GKI, pour vérifier que les tests de conformité sont réussis sur une version GSI+GKI avec un appareil de référence ainsi que Cuttlefish.

Figure 1. Calendrier des versions GKI

Qualifications GKI

Où obtenir les artefacts de compilation

Les OEM peuvent obtenir des artefacts pour toutes les versions sur ci.android.com.

Pour en savoir plus sur l'IC, y compris sur les résultats des tests, consultez le tableau de bord Intégration continue Android.

Questions fréquentes

Voici quelques questions fréquentes sur le processus de publication du GKI.

Est-il possible de créer un binaire GKI basé sur un GKI déjà publié ?

Oui, c'est ce qu'on appelle un respin. Le processus de respin est pris en charge tant que le build GKI publié (sur lequel le respin est demandé) est conforme aux exigences LTS du bulletin sur la sécurité d'Android (ASB).

Est-il possible de reproduire les binaires GKI ?

Oui, voici un exemple :

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

Pour reproduire l'exemple, téléchargez manifest_$id.xml et exécutez la commande suivante :

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

Vous pouvez récupérer votre copie d'artefact GKI depuis out/.../dist.

Le binaire GKI (y compris le correctif d'urgence) a-t-il été créé sur la base de code la plus récente ?

Non. Les réponses ne contiennent que les correctifs qui se trouvent au-dessus des noyaux certifiés trimestriels qui ont été choisis. Ces nouvelles versions contiennent tous les correctifs de bugs bloquant le lancement signalés jusqu'à une date donnée par les OEM utilisant la version trimestrielle de base correspondante. Consultez l'exemple suivant pour comprendre comment ce type de scénario se produit.

• OEM1 et OEM2 décident d'utiliser la version binaire GKI de novembre 2021.
• OEM1 et OEM2 identifient des problèmes qui nécessitent des correctifs pour l'assistance. Ces correctifs peuvent être différents ou identiques.
• Les nouvelles versions du binaire de novembre 2021 contiennent des correctifs bloquant le lancement signalés par OEM1 et OEM2 pendant la période de nouvelle version, mais rien de plus.
• Les problèmes mentionnés dans le deuxième point sont également inclus dans les versions trimestrielles ultérieures de GKI.

La réédition d'octobre contient tous les correctifs envoyés par les OEM, mais d'autres correctifs OEM nous affectent, car ils n'ont pas été spécifiquement testés avec nos produits. Est-il possible d'inclure uniquement notre correctif ?

Ce n'est pas possible. Un chemin de réédition pour chaque OEM n'est pas évolutif. Au lieu de cela, l'équipe GKI examine chaque modification apportée aux versions de réédition et teste les modifications avec tout le matériel disponible avant de créer une nouvelle version. Si l'équipe GKI constate que le problème est spécifique à un OEM, à un appareil ou à un modèle, elle peut vérifier que le code ajouté par la modification ne s'exécute que sur l'appareil, le modèle ou le SKU concerné.

L'avantage majeur des respins unifiés est que chaque appareil utilisant la même base de version bénéficie des corrections apportées aux autres appareils, en particulier si les bugs découverts sont génériques et applicables à tous les utilisateurs. Les bugs du noyau principal détectés lors des tests de l'opérateur sont un exemple spécifique de ce concept.

Existe-t-il des situations dans lesquelles Google fournit des informations spécifiques sur les correctifs OEM et les scénarios de problèmes, afin que les OEM puissent évaluer l'impact et le risque de l'implémentation des correctifs avec leurs produits ?

Google n'ajoutera jamais de modification à une version de recompilation tant que l'équipe GKI n'aura pas compris le problème et recueilli tous les détails. Vous pouvez le voir dans le journal des modifications (message de commit). Google ne révèle pas l'appareil spécifique concerné, mais les OEM peuvent toujours trouver la description du problème et la solution dans le journal des modifications.