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

Cette page décrit comment GKI est publié, y compris les versions d'urgence trimestrielles et hors bande. L'objectif de cette page est de fournir aux OEM des instructions sur l'emplacement où récupérer le GKI, ainsi que sur le processus de correction 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 du noyau Android afin d'optimiser le noyau GKI pour leurs produits.

Cadence de lancement de GKI

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

Validité des builds GKI pour les OEM

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

Versions de GKI 16 ko

L'équipe chargée des versions GKI gère les versions GKI de 16 Ko en utilisant la même cadence de publication trimestrielle, les mêmes tests de qualification et le même processus de réédition que pour les versions GKI de 4 Ko :

• Branches compatibles :
  • android15-6.6 (à partir de janvier 2026)
  • android16-6.12 (à partir de mars 2026)
  • android17-6.18 (à partir de juin 2026)
• Parité et certification des builds : les binaires GKI de 16 Ko utilisent le même tag source et le même ID de build de noyau que la version GKI de 4 Ko correspondante. Jusqu'en 2027, l'onglet Build de version 16 Ko des pages de build de version android15-6.6, android16-6.12 et android17-6.18 fournit des binaires de version GKI 16 Ko non certifiés. Vous n'avez pas besoin de mettre à jour les kernels de 4 ko et de 16 ko en même temps, même si nous vous le recommandons.
• Nouvelles versions à la demande : demandez de nouvelles versions de GKI 16 ko en utilisant le même processus et le même formulaire de demande de nouvelle version que pour les builds 4 ko.

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 référence de code source connue.

Chaque trimestre, un candidat à la publication trimestrielle du noyau 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 un build GSI+GKI avec un appareil de référence ainsi que Cuttlefish.

Figure 1. Chronologie 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'intégration continue, y compris sur les résultats des tests, consultez le tableau de bord Android Continuous Integration.

Questions fréquentes

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

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

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

Est-il possible de reproduire des 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 à partir de out/.../dist.

Le binaire GKI (y compris le correctif d'urgence) a-t-il été compilé sur la dernière codebase ?

Non. Les respins ne contiennent que les correctifs qui se trouvent au-dessus des noyaux certifiés trimestriels qui ont été choisis. Ces respins contiennent toutes les corrections de bugs bloquant le lancement signalées jusqu'à un moment donné par les OEM utilisant la version trimestrielle de base correspondante. Voici un exemple de ce type de scénario.

• OEM1 et OEM2 décident d'utiliser la version binaire GKI de novembre 2021.
• OEM1 et OEM2 détectent 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 comportent 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 les OEM individuels n'est pas évolutif. À la place, l'équipe GKI examine chaque modification apportée aux builds de réédition et teste les modifications avec tout le matériel disponible avant de créer un build. 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é.

Le principal avantage des respins unifiés est que tous les appareils utilisant la même base de version bénéficient les uns des autres, en particulier si les bugs qu'ils découvrent sont génériques et applicables à tous les utilisateurs. Les bugs du noyau de base 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 compilation de respin tant que l'équipe GKI n'aura pas compris le problème et collecté 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.