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

Cette page décrit comment GKI est publié, y compris les versions hebdomadaires, trimestrielles et d'urgence hors bande. L'objectif de ce document 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 du noyau Android 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 LTS du bulletin de sécurité 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 du noyau GKI (non certifié) est sélectionné après la date limite d'enregistrement, qui correspond généralement à la deuxième version hebdomadaire du mois. 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 cette période, seules les corrections de bugs entraînant l'échec des tests peuvent être effectuées. La version candidate est soumise à une assurance qualité, comme décrit dans la section Qualification GKI, pour s'assurer que les tests de conformité sont réussis sur la version GSI+GKI avec un appareil de référence ainsi que sur Cuttlefish.

Figure 1. Calendrier des versions GKI

Qualifications GKI

Où obtenir les artefacts de compilation

Vous pouvez obtenir les artefacts de 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 créer un binaire GKI basé sur un GKI déjà publié ?

Oui, c'est ce qu'on appelle un respin. Le processus de nouvelle version est pris en charge tant que le build GKI publié (sur lequel la nouvelle version est demandée) est conforme aux exigences LTS du bulletin de sécurité 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 de rotation d'urgence) a-t-il été créé sur la base de code la plus récente ?

Non. Les respins ne contiennent que des correctifs qui s'ajoutent aux noyaux certifiés trimestriels qui ont été choisis. Ces respins 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. 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 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 de blocage du 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 nouvelle version 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 "par OEM" n'est pas évolutif. Au lieu de cela, l'équipe GKI examine chaque modification apportée aux versions respin 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 s'assurer que le code ajouté par la modification ne s'exécute que sur l'appareil, le modèle ou le SKU concerné.

L'avantage principal des réponses unifiées est que chaque appareil utilisant la même base de version bénéficie des autres, en particulier si les bugs qu'ils découvrent 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 réédition tant que le problème n'aura pas été compris et que tous les détails n'auront pas été recueillis. Cela se voit 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.