Ce document décrit la manière dont GKI est publié, y compris les versions d'urgence hebdomadaires, mensuelles et hors bande. L'objectif de ce document est de fournir aux OEM des consignes quant à l'endroit où récupérer le GKI, ainsi que la procédure à suivre pour résoudre les problèmes d'urgence hors bande. Les OEM peuvent également consulter le guide de développement GKI pour découvrir comment collaborer avec l'équipe du noyau Android afin d'optimiser le noyau GKI pour leurs produits.
Cadence des lancements GKI
GKI est publié à un rythme mensuel après le blocage 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-6.1.
| Builds certifiés GKI mensuels | Date limite d'arrivée | Date de préchargement GKI | Confirmé ? |
|---|---|---|---|
| Octobre | 14 octobre 2022 | 31 octobre 2022 | Oui |
| Novembre | 14 novembre 2022 | 30 novembre 2022 | Oui |
| Décembre | 9 décembre 2022 | 21 décembre 2022 | Oui |
| Janvier | 17 janvier 2023 | 31 janvier 2023 | Oui |
| Février | 15 février 2023 | 28 février 2023 | Oui |
| Mars | 15 mars 2023 | 31 mars 2023 | Oui |
| Avril | 13 avril 2023 | 28 avril 2023 | Oui |
| Mai | 17 mai 2023 | 31 mai 2023 | Oui |
| Juin | 15 juin 2023 | 30 juin 2023 | Oui |
| Juillet | 18 juillet 2023 | 31 juillet 2023 | Oui |
| Août | 16 août 2023 | 31 août 2023 | Oui |
| Septembre | 14 septembre 2023 | 29 septembre 2023 | Oui |
| Octobre | 18 octobre 2023 | 31 octobre 2023 | Oui |
| Novembre | 10 novembre 2023 | 30 novembre 2023 | Oui |
| Décembre | 7 décembre 2022 | 22 décembre 2023 | Oui |
| Janvier | 16 janvier 2024 | 31 janvier 2024 | Oui |
| Février | 13 février 2024 | 29 février 2024 | Oui |
| Mars | 13 mars 2024 | 29 mars 2024 | Oui |
| Avril | 16 avril 2024 | 30 avril 2024 | Oui |
| Mai | 14 mai 2024 | 31 mai 2024 | Oui |
| Juin | 12 juin 2024 | 28 juin 2024 | Oui |
| Juillet | 16 juillet 2024 | 31 juillet 2024 | Oui |
| Août | 15 août 2024 | 30 août 2024 | Oui |
| Septembre | 17 septembre 2024 | 30 septembre 2024 | Oui |
| Octobre | 15 octobre 2024 | 31 octobre 2024 | Oui |
| Novembre | 11 novembre 2024 | 27 novembre 2024 | Oui |
| Décembre | 6 décembre 2024 | 23 décembre 2024 | Oui |
À partir de janvier 2024, nous reprendrons les versions mensuelles de android14-5.15 conformément à la cadence mensuelle spécifiée dans le tableau ci-dessous.
android15-6.6 suivra la même cadence de publication à partir de juillet 2024.
| Builds certifiés GKI mensuels | Date limite d'arrivée | Date de préchargement GKI | Confirmé ? |
|---|---|---|---|
| Janvier | 16 janvier 2024 | 31 janvier 2024 | Oui |
| Février | 13 février 2024 | 29 février 2024 | Oui |
| Mars | 4 mars 2024 | 15 mars 2024 | Oui |
| Avril | 1er avril 2024 | 17 avril 2024 | Oui |
| Mai | 1er mai 2024 | 17 mai 2024 | Oui |
| Juin | 3 juin 2024 | 17 juin 2024 | Oui |
| Juillet | 1er juillet 2024 | 15 juillet 2024 | Oui |
| Août | 1er août 2024 | 16 août 2024 | Oui |
| Septembre | 2 septembre 2024 | 16 septembre 2024 | Oui |
| Octobre | 1er octobre 2024 | 14 octobre 2024 | Oui |
| Novembre | 1er novembre 2024 | 15 novembre 2024 | Oui |
| Décembre | 2 décembre 2024 | 16 décembre 2024 | Oui |
Version GKI d'Android 12
Après mai 2024, les versions GKI de android12-5.10 sont publiées tous les trimestres et sont publiées en milieu de mois.
Le tableau suivant ne s'applique qu'à android12-5.10.
| Builds certifiés GKI mensuels | Date limite d'arrivée | Date de préchargement GKI | Confirmé ? |
|---|---|---|---|
| Juillet | 3 juillet 2023 | 14 juillet 2023 | Oui |
| Septembre | 1er septembre 2023 | 15 septembre 2023 | Oui |
| Novembre | 3 novembre 2023 | 17 novembre 2023 | Oui |
| Janvier | 5 janvier 2024 | 19 janvier 2024 | Oui |
| Mars | 4 mars 2024 | 15 mars 2024 | Oui |
| Mai | 1er mai 2024 | 17 mai 2024 | Oui |
| Août | 1er août 2024 | 16 août 2024 | Oui |
| Novembre | 1er novembre 2024 | 15 novembre 2024 | Oui |
| Février | 3 février 2025 | 17 février 2025 | Oui |
Validité du build GKI pour les OEM
Les OEM peuvent utiliser une version GKI récente d'Android. 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 versions sont testées avec des seiches pour vérifier qu'elles répondent à un seuil de qualité minimal.Les binaires GKI sont disponibles en libre-service sur ci.android.com à mesure que les modifications sont fusionnées. Les builds hebdomadaires ne seront pas certifiés, mais ils 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 pour les utilisateurs finaux.
Versions certifiées mensuelles
Les versions mensuelles de GKI contiennent un fichier boot.img testé qui inclut un certificat Google inséré pour attester que les binaires ont été créés à partir d'une référence de code source connue.
Chaque mois, une version GKI mensuelle (non certifiée) est sélectionnée après la date limite d'arrivée, 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 pour la version du mois en cours. Pendant la période de fermeture, seuls les corrections des bugs qui provoquent l'échec des tests peuvent être résolus. La version finale est soumise à un contrôle qualité, comme décrit dans la section Qualification GKI, afin de s'assurer que les tests de conformité réussissent sur le build GSI + GKI avec un appareil de référence ainsi qu'avec la seiche.
Figure 1. Calendrier de lancement de 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 la résolution d'un binaire certifié dans l'une des situations suivantes:
- Pour mettre à jour une liste de symboles.
- Pour appliquer un correctif à un bug, y compris pour les bugs détectés lors de l'approbation de l'atelier du transporteur.
- Pour ajouter une accroche de fournisseur, procédez comme suit :
- 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 publication pendant une durée maximale de 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.
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 Releases. 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 brancheandroid12-5.10-2023-07(5.10.177) ne respecte pas les exigences LTS d'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 envoyés à la branche de publication mensuelle doivent déjà être fusionnés dans la branche de développement GKI principale. Par exemple, si un correctif est requis pour une résolution de
android12-5.10-2022-09, il doit déjà être fusionné avecandroid12-5.10.Vous devez sélectionner les correctifs de la branche de développement GKI principale et les importer dans la branche de publication 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 requêtes critiques ou urgentes, définissez la priorité sur P0. Pour les demandes P0 et P1, vous devez également justifier le caractère urgent. Le tableau suivant fournit un mappage de la priorité de bug et du délai de résolution (ESRT):
Priorité TR 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 respin distincte par branche de release. Par exemple, si un respin est nécessaire à la fois pour
android12-5.10-2022-08etandroid12-5.10-2022-09, vous devez créer deux requêtes de respins.Une fois qu'une compilation est fournie et qu'une requête de respin a été marquée comme corrigée, vous ne devez pas rouvrir la requête de respin pour ajouter d'autres CL. Vous devez envoyer une nouvelle requête de relance si des correctifs supplémentaires doivent être fusionnés.
Pour chaque CL prise en compte, ajoutez les balises suivantes. Sans ces informations, la progression de la requête de relance est bloquée.
Bug: l'ID de bug doit être ajouté au message de commit pour chaque CL.Change-Id: doit être identique à l'ID de modification de la modification de branche de base.
Si une requête de respin nécessite votre réponse et que vous ne répondez pas dans un délai de trois jours ouvrés, la priorité est rétrogradée d'un niveau (par exemple, P0 passe à P1). Si vous ne répondez pas pendant deux semaines, le bug est marqué comme Won't Fix (Obsolete) (Ne pas corriger (Obsolète)).
Envoyer une demande de réexamen
Le schéma suivant illustre le processus de respinage. Le processus commence lorsque le partenaire OEM (vous) envoie la demande de relance.
Figure 2 : Le processus de respin
Pour lancer le processus de relance:
- Remplissez le formulaire de demande GKI Respin, puis 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 par vous (le demandeur).
- 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 requête sous forme de fichier texte.
- Si vous ne disposez pas d'un correctif, la requête doit contenir autant d'informations que possible, y compris le numéro de version et les journaux du noyau, afin que Google puisse vous aider à déboguer le problème.
- L'équipe Google GKI examine la demande et l'approuve ou vous la réattribue si des informations supplémentaires sont nécessaires.
- 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, crée, teste la régression et certifie le changement.
- Le binaire est publié sur ci.android.com. Le délai ESRT se termine, et l'équipe Google GKI marque la requête comme fixe et référence le build respin. Le build respin est également publié sur la page des builds GKI (Generic Kernel Image).
Qualification GKI
| Types de builds GKI | Application des critères de qualité | Notes |
|---|---|---|
| Toutes les semaines | Tests de seiches
|
|
| Mensuel (certifié) | Tests de seiches
|
|
| Respins (certifiés) | Tests de seiches
|
|
Emplacement d'obtention des artefacts de compilation
Les artefacts de toutes les versions peuvent être obtenus 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
Est-il possible de créer 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 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 des binaires GKI ?
Oui. Reportez-vous à l'exemple ci-dessous.
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/manifestmv manifest_7364300.xml .repo/manifestsrepo init -m manifest_7364300.xml --depth=1repo sync # build the GKI images # You may want to use LTO=thin to build faster for developmentBUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh # (optional) build virtual platform modulesBUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh
Vous pouvez récupérer la copie de votre artefact GKI à partir de out/.../dist.
Le binaire GKI (y compris le correctif de rotation d'urgence) a-t-il été créé sur la dernière version du codebase ?
Non. Les résolutions ne contiennent que des correctifs en plus des noyaux certifiés mensuels qui ont été 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 découvrir comment ce type de scénario se produit.
- Les OEM1 et OEM2 décident d'utiliser la version binaire GKI à partir de novembre 2021.
- Les OEM1 et OEM2 identifient les problèmes qui nécessitent des correctifs pour l'assistance. Ces correctifs peuvent être différents ou identiques.
- Les résolutions au-dessus du binaire de novembre 2021 comportent des correctifs de blocage du lancement signalés par les OEM1 et OEM2 pendant la fenêtre de relance, mais rien de plus.
- Les problèmes mentionnés dans le deuxième point sont également inclus dans les versions mensuelles GKI ultérieures.
Le rapport d'octobre présente tous les correctifs envoyés par les OEM, mais d'autres correctifs OEM nous concernent, 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 retour "par OEM" n'est actuellement 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é.
Le principal avantage des retours unifiés est que chaque appareil utilisant la même base de publication bénéficie les uns des autres, en particulier si les bugs qu'ils découvrent sont génériques et applicables à tous les utilisateurs. Les principaux bugs du noyau détectés lors des tests opérateur sont un exemple spécifique de ce concept.
Existe-t-il des cas où 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 les risques liés à l'implémentation des correctifs avec leurs produits ?
Google n'apportera aucune modification à un build respin tant que le problème n'aura pas été compris et que tous les détails n'auront pas été collectés. Cela est visible 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.