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 de développement hebdomadaires

Les binaires GKI sont disponibles en libre-service sur Android CI à mesure que les modifications sont fusionnées. Les versions hebdomadaires ne seront pas certifiées, mais pourront servir de référence pour le développement et les tests. Les versions hebdomadaires ne peuvent pas être utilisées pour les versions d'appareils de production destinées aux utilisateurs finaux.

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 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 traité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

Processus de réinitialisation d'urgence

Un respin désigne le processus de réinstallation, de recompilation, de retest et de recertification d'un binaire après une version publique du noyau GKI. Vous pouvez demander une nouvelle rotation d'un binaire certifié dans les cas suivants :

• Pour mettre à jour une liste de symboles :
• Pour appliquer un correctif à un bug, y compris ceux détectés lors de l'approbation du laboratoire de l'opérateur.
• Pour ajouter un hook de fournisseur.
• Pour appliquer un correctif à une fonctionnalité existante.
• Pour appliquer un correctif de sécurité (après six mois).

Les correctifs de sécurité sont automatiquement fusionnés dans une branche de version pendant une durée maximale de six mois après la publication de la branche. Après le délai de six mois, vous devez demander une nouvelle version pour appliquer des correctifs de sécurité à une branche.

Consignes pour les demandes de réinterprétation

Avant de demander une nouvelle rotation, veuillez noter les consignes suivantes :

• Les nouvelles compilations ne sont autorisées que sur les branches de version après le lancement public initial d'une compilation trimestrielle.

• Les demandes de réédition ne sont acceptées que pour une branche de version donnée, pendant six mois maximum après la publication initiale. Au bout de six mois, les branches ne peuvent faire l'objet d'une nouvelle version que pour les correctifs de sécurité mentionnés dans un bulletin de sécurité Android.

• Lorsque les exigences LTS, définies par le bulletin de sécurité Android (ASB), entraînent la non-conformité de la branche, celle-ci est obsolète. Les demandes de nouvelle version pour les branches obsolètes ne sont pas acceptées. La date d'arrêt d'une branche de version GKI donnée est incluse dans les notes de version trimestrielles de GKI sous Versions. Pour la planification future, les exigences LTS sont mises à jour en mai et en novembre de chaque année. Par exemple, la branche android12-5.10-2023-07 (5.10.177) n'est pas acceptée pour les respins après le 1er mai 2024, car la branche android12-5.10-2023-07 (5.10.177) ne respecte pas les exigences LTS de ASB-2024-05.

• Les réponses ne s'appliquent qu'aux corrections de bugs urgentes, aux mises à jour de la liste des symboles ou à l'application d'un correctif pour résoudre un problème lié à une fonctionnalité existante.

• Tous les correctifs qui sont intégrés à la branche de publication trimestrielle doivent déjà avoir été fusionnés dans la branche de développement GKI principale. Par exemple, si un correctif est requis pour une nouvelle version de android12-5.10-2022-09, il doit déjà être fusionné dans android12-5.10.

• Vous devez sélectionner des correctifs à partir de la branche de développement GKI principale et les importer dans la branche de version trimestrielle.

• Dans la demande de renvoi, vous devez attribuer une priorité (urgence) à la demande. Cette priorité permet à l'équipe GKI de mieux aider les partenaires en temps voulu. Pour les demandes critiques ou urgentes, définissez la priorité sur P0. Pour les demandes de priorité P0 et P1, vous devez également justifier l'urgence. Le tableau suivant fournit une cartographie de la priorité des bugs et du délai de résolution (ESRT) :

  Priorité	ESRT
  P0	Deux jours ouvrés
  P1	5 jours ouvrés
  P2	10 jours ouvrés
  P3	15 jours ouvrables

• Vous devez envoyer une demande de réédition distincte pour chaque branche de version. Par exemple, si une nouvelle rotation est nécessaire pour android12-5.10-2022-08 et android12-5.10-2022-09, vous devez créer deux demandes de nouvelle rotation.

• Une fois qu'une version est fournie et qu'une demande de respin est marquée comme résolue, vous ne devez pas la rouvrir pour ajouter des CL supplémentaires. Vous devez envoyer une nouvelle demande de réexécution s'il existe des correctifs supplémentaires à fusionner.

• Pour chaque CL à examiner, ajoutez les balises suivantes.

  • Bug : l'ID du bug doit être ajouté au message de commit pour chaque CL.
  • Change-Id : doit être identique à l'ID de modification de la modification de la branche de base.

• Si une demande de réanalyse nécessite votre réponse et que vous ne répondez pas dans un délai de trois jours ouvrés, la priorité est abaissée d'un niveau (par exemple, P0 devient P1). Si vous ne répondez pas au bout de deux semaines, le bug est marqué comme Ne sera pas corrigé (obsolète).

Envoyer une demande de réanalyse

Le schéma suivant illustre le processus de réédition. Le processus commence lorsque le partenaire OEM (vous) envoie la demande de réédition.

Figure 2. Processus de réanalyse

Pour lancer le processus de nouvelle version :

1. Remplissez le formulaire de demande de réédition du noyau GKI et contactez immédiatement votre responsable de compte technique Google. Ce formulaire permet de créer un bug de demande de réédition GKI. Les bugs liés aux demandes de réexécution sont visibles par vous (le demandeur), l'équipe GKI et les personnes spécifiques que vous ajoutez à la liste de copie conforme du bug.
   • Si vous avez déjà une solution, la demande doit pointer vers l'envoi du correctif dans AOSP afin que Google puisse l'examiner. Si l'envoi du correctif n'est pas possible, il doit être joint à la demande sous forme de fichier texte.
   • Si vous n'avez pas de correctif, la demande doit contenir autant d'informations que possible, y compris le numéro de version du noyau et les journaux, afin que Google puisse vous aider à déboguer le problème.
2. L'équipe Google GKI examine la demande et l'approuve ou vous la renvoie si elle a besoin de plus d'informations.
3. Une fois la correction approuvée, l'équipe Google GKI procède à un examen du code (CR+2) de la modification. L'examen commence pendant la période ESRT. L'équipe GKI fusionne, compile, teste la régression et certifie la modification.
4. Le binaire est publié sur ci.android.com. Le délai ESRT se termine et l'équipe Google GKI marque la demande comme résolue et fait référence à la version respin. La version respin sera également publiée sur la page Generic Kernel Image (GKI) release builds.

Qualifications GKI

Où obtenir les artefacts de compilation

Les artefacts de toutes les versions peuvent être obtenus 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. 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 fichier 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 "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 majeur 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 respin 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.