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

Cette page explique comment le GKI est publié, y compris les versions hebdomadaires, mensuelles et exceptionnelles. L'objectif de ce document est de fournir aux OEM des consignes sur l'endroit 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 découvrir comment collaborer avec l'équipe du kernel Android afin d'optimiser le kernel GKI pour leurs produits.

Cadence des lancements GKI

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

Version GKI d'Android 13, 14 et 15

Le tableau suivant ne s'applique qu'à android13-5.10, android13-5.15 et android14-5.15.

Le tableau suivant ne s'applique qu'à android14-6.1 et android15-6.6.

Version GKI d'Android 12

Après mai 2024, les versions GKI android12-5.10 sont publiées tous les trimestres, à la mi-mois. Le tableau suivant ne s'applique qu'à android12-5.10.

Validité des builds GKI pour les OEM

Les OEM peuvent utiliser une GKI Android récemment publiée. Les OEM peuvent lancer des builds certifiés GKI à condition qu'ils respectent les exigences LTS du bulletin de sécurité Android (ASB).

Versions de développement hebdomadaires

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

Versions certifiées mensuelles

Les versions mensuelles 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 mois, une version candidate mensuelle de GKI (non certifiée) est sélectionnée après la date limite d'intégration, qui correspond généralement au deuxième build hebdomadaire de ce mois. Une fois la version mensuelle candidate sélectionnée, les nouvelles modifications ne sont pas acceptées dans la version du mois en cours. Pendant la période de fermeture, seuls les correctifs des bugs qui entraînent un échec du test peuvent être appliqués. La version candidate est soumise à un contrôle qualité, comme décrit dans la section Qualification des GKI, afin de s'assurer que les tests de conformité sont réussis sur le build GSI+GKI avec un appareil de référence et avec cuttlefish.

Figure 1 : Calendrier des versions GKI

Processus de renvoi d'urgence

Un respin est un processus de refusion, de recompilation, de nouveau test et de recertification d'un binaire après une version publique du noyau GKI. Vous pouvez demander un nouveau build d'un binaire certifié dans les cas suivants:

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

Les correctifs de sécurité sont automatiquement fusionnés dans une branche de publication jusqu'à six mois après la publication de la branche. Passé ce délai, vous devez demander une nouvelle instance pour appliquer les correctifs de sécurité à une branche.

Consignes concernant les demandes de re-spin

Avant de demander un nouvel examen, tenez compte des consignes suivantes:

• Les respins ne sont autorisés que sur les branches de publication après le lancement d'une version publique initiale d'un build mensuel.

• Les requêtes de respin ne sont acceptées que pour une branche de publication donnée pendant une durée maximale de six mois après la version publique initiale. Après six mois, les branches ne peuvent faire l'objet d'une nouvelle analyse que pour les correctifs de sécurité cités dans un bulletin sur la sécurité d'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 devient obsolète. Les requêtes de redressement pour les branches obsolètes ne sont pas acceptées. La date d'abandon d'une branche de version GKI donnée est incluse dans les notes de version mensuelles de GKI sous Versions. Pour la planification future, les exigences LTS sont mises à jour en mai et en novembre chaque année. Par exemple, la branche android12-5.10-2023-07 (5.10.177) n'est plus compatible avec 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ésolutions ne s'appliquent qu'aux corrections de bugs urgentes, aux mises à jour de la liste des symboles ou à l'application d'un correctif pour corriger une fonctionnalité existante.

• Tous les correctifs intégrés à la branche de publication mensuelle doivent déjà être fusionnés dans la branche de développement principale de GKI. Par exemple, si un correctif est requis pour un nouveau spin de android12-5.10-2022-09, il doit déjà être fusionné dans android12-5.10.

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

• Dans la requête de renvoi, vous devez lui attribuer un niveau de priorité (urgence). Cette priorité permet à l'équipe GKI de mieux aider les partenaires en temps opportun. Pour les demandes critiques ou urgentes, indiquez la priorité P0. Pour les requêtes P0 et P1, vous devez également justifier l'urgence. Le tableau suivant fournit un mappage de la priorité de bug 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 nouvelle évaluation distincte pour chaque branche de version. Par exemple, si un nouveau refus est nécessaire pour android12-5.10-2022-08 et android12-5.10-2022-09, vous devez créer deux demandes de nouveau refus.

• Une fois qu'une compilation est fournie et qu'une demande de nouvelle analyse est marquée comme résolue, vous ne devez pas rouvrir la demande de nouvelle analyse pour ajouter des CL supplémentaires. Vous devez envoyer une nouvelle demande de respin si des correctifs supplémentaires doivent être fusionnés.

• 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 branche de base.

• Si une demande de nouvelle réponse 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 est abaissée à P1). Si vous ne répondez pas dans un délai de deux semaines, le bug est marqué comme Non corrigé (obsolète).

Envoyer une demande de refus

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

Figure 2 : Processus de nouvelle demande

Pour lancer le processus de respin:

1. Remplissez le formulaire de demande de nouvelle réponse à une question Google et contactez immédiatement votre responsable de compte technique Google. Ce formulaire crée un bug de requête de respin GKI. Vous (le demandeur), l'équipe GKI et les personnes spécifiques que vous ajoutez à la liste des destinataires en copie du bug sont visibles.
   • Si vous disposez déjà d'une correction, la requête doit pointer vers l'envoi des correctifs dans AOSP afin que Google puisse l'examiner. Si l'envoi du correctif n'est pas possible, il doit être joint à la demande en tant que fichier texte.
   • Si vous ne disposez pas d'une solution, la demande doit contenir autant d'informations que possible, y compris le numéro de version du kernel 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 des informations supplémentaires sont nécessaires.
3. Une fois qu'un correctif est convenu, l'équipe Google GKI examine le code (RS + 2) la modification. L'examen commence le délai ESRT. L'équipe GKI fusionne, compile, teste pour la régression et certifie la modification.
4. Le binaire est publié sur ci.android.com. Le délai de l'ESRT prend fin, et l'équipe GKI de Google marque la demande comme résolue et fait référence au build de respin. La version de respin est également publiée sur la page des builds de version de l'image de kernel générique (GKI).

Qualification GKI

Où obtenir des artefacts de compilation

Les artefacts de toutes les versions sont disponibles sur ci.android.com.

Vous trouverez plus d'informations sur la CI, y compris les résultats des tests, dans le tableau de bord Android Continuous Integration (Intégration continue Android).

Questions fréquentes

Vous trouverez ci-dessous des questions fréquentes sur le processus de publication des données GKI.

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

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 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 de l'artefact GKI à partir de out/.../dist.

Le binaire GKI (y compris le correctif de démarrage d'urgence) a-t-il été compilé sur le dernier codebase ?

Non. Les respins ne contiennent que des correctifs en plus des noyaux certifiés mensuels choisis. Ces résolutions contiennent toutes les corrections de bugs bloquant les lancements signalées jusqu'à un moment donné par les OEM utilisant la version mensuelle 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 de GKI à partir de novembre 2021.
• OEM1 et OEM2 détectent des problèmes qui nécessitent des correctifs pour être résolus. Ces correctifs peuvent être différents ou identiques.
• Les respins au-dessus du binaire de novembre 2021 comportent des correctifs de blocage du lancement signalés par OEM1 et OEM2 pendant la période de respin, mais rien d'autre.
• Les problèmes mentionnés dans le deuxième point sont également inclus dans les versions mensuelles ultérieures du 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é testés spécifiquement avec nos produits. Est-il possible d'inclure uniquement notre correctif ?

Ce n'est pas possible. Un chemin de respin "par OEM" n'est pas évolutif. Au lieu de cela, l'équipe GKI examine chaque modification apportée aux builds de relance et teste ces modifications sur 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 s'assurer que le code ajouté par la modification ne s'exécute que sur l'appareil, le modèle ou le SKU concernés.

L'avantage principal des respins unifiés est que chaque appareil qui utilise la même base de version en profite, en particulier si les bugs qu'il découvre sont génériques et s'appliquent à tous les utilisateurs. Les bugs de noyau de base détectés lors des tests du transporteur sont un exemple spécifique de ce concept.

Google fournit-il 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 d'implémenter les correctifs avec leurs produits ?

Google n'ajoutera jamais de modification à un build de nouvelle version tant que le problème n'aura pas été compris et que tous les détails n'auront pas été collectés. Cela apparaît 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 et la solution du problème dans le journal des modifications.