Ce document décrit comment GKI est publié, y compris les versions d'urgence hebdomadaires, mensuelles et hors bande. L'objectif de ce document est de donner aux OEM une ligne directrice sur l'endroit où récupérer le GKI ainsi que le processus pour les correctifs d'urgence hors bande. Les OEM peuvent également utiliser le guide de développement GKI pour en savoir plus sur la façon dont ils peuvent travailler avec l'équipe du noyau Android pour optimiser le noyau GKI pour leurs produits.
Cadence de publication de GKI
GKI est publié sur une cadence mensuelle après le gel de KMI.
Version Android 13 et 14 GKI
Le tableau suivant s'applique uniquement à android13-5.10 , android13-5.15 et android14-6.1 .
| Versions mensuelles certifiées GKI | Date limite d'enregistrement | Date de préchargement GKI prêt | 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 |
| Peut | 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 | 12 décembre 2023 | 22 décembre 2023 | Oui |
Version Android 12 GKI
Après mai 2023, les versions android12-5.10 GKI sont sur une cadence de 2 mois et publiées au milieu du mois. Le tableau suivant s'applique uniquement à android12-5.10 .
| Versions mensuelles certifiées GKI | Date limite d'enregistrement | Date de préchargement GKI prêt | Confirmé? |
|---|---|---|---|
| Juillet | 3 juillet 2023 | 14 juillet 2023 | Oui |
| Septembre | 1er septembre 2023 | 15 septembre 2023 | Oui |
| Novembre | 3 novembre 2022 | 17 novembre 2022 | Oui |
| Janvier | 5 janvier 2024 | 19 janvier 2024 | Oui |
Validité de build GKI pour les OEM
Les OEM peuvent utiliser un GKI Android récemment publié. Les OEM peuvent se lancer avec des versions certifiées GKI tant qu'elles sont conformes aux exigences LTS du bulletin de sécurité Android (ASB).
Versions de développement hebdomadaires
Les rejets sont testés avec des seiches pour s'assurer qu'ils passent une barre de qualité minimale .Les fichiers binaires GKI sont disponibles en libre-service sur ci.android.com à mesure que les modifications sont fusionnées. Les versions hebdomadaires ne seront pas certifiées, mais peuvent être utilisées 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.
Publications mensuelles certifiées
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 ligne de base de code source connue.
Chaque mois, un candidat à la version mensuelle de GKI (non certifié) est sélectionné après la date limite d'enregistrement, qui correspond généralement à la deuxième version hebdomadaire de ce mois. Une fois la version candidate du mois sélectionnée, les nouvelles modifications ne seront pas acceptées dans la version de ce mois. Pendant la période de fenêtre fermée, seuls les correctifs pour les bogues qui provoquent l'échec du test peuvent être résolus. La version candidate est soumise à une assurance qualité, comme décrit dans la section de qualification GKI , pour s'assurer que les tests de conformité réussissent sur la version GSI + GKI avec un appareil de référence ainsi que sur la seiche.
Figure 1. Calendrier de publication de GKI
Processus de respin d'urgence
Un respin fait référence au processus de refusion, de reconstruction, de nouveau test et de recertification d'un binaire après une publication publique du noyau GKI . Vous pouvez demander un respin d'un binaire certifié dans l'une des circonstances suivantes :
- Pour mettre à jour une liste de symboles.
- Pour appliquer un correctif à un bogue, y compris les bogues trouvés lors de l'approbation du 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 6 mois).
Les correctifs de sécurité sont automatiquement fusionnés dans une branche de publication jusqu'à 6 mois après la publication de la branche. Après la date limite de 6 mois, vous devez demander un respin pour appliquer les correctifs de sécurité à une succursale.
Avant de demander un respin, notez les directives suivantes :
Les réponses ne sont autorisées que sur les branches de publication après le lancement d'une première version publique d'une version mensuelle .
Les demandes de respin ne sont acceptées que pour une branche de publication donnée pendant un maximum de six mois après la publication publique initiale. Après six mois, les succursales ne sont éligibles à la respin que pour les correctifs de sécurité cités dans un bulletin de sécurité Android .
Lorsque les exigences LTS rendent la branche non conforme, la branche est obsolète. Les demandes de respin pour les branches obsolètes ne sont pas acceptées. Par exemple, la branche
android12-5.10-2021-11(5.10.66) n'est pas prise en charge pour les respins après novembre 2022, car la brancheandroid12-5.10-2021-11(5.10.66) n'est pas conforme aux exigences LTS de l'ASB-2022-11.Les réponses ne s'appliquent qu'aux corrections de bogues urgentes, aux mises à jour de la liste des symboles ou à l'application d'un correctif pour corriger une fonctionnalité existante.
Tous les correctifs entrant dans 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 respin de
android12-5.10-2022-09, il doit déjà être fusionné dansandroid12-5.10.Vous devez sélectionner les correctifs de la branche de développement principale de GKI et télécharger le correctif dans la branche de publication mensuelle.
Dans la requête respin, vous devez attribuer une priorité (urgence) à la requête. Cette priorité aide l'équipe GKI à mieux assister les partenaires en temps opportun. Pour les demandes critiques ou urgentes, marquez la priorité comme P0 . Pour les demandes P0 et P1, vous devez également justifier l'urgence. Le tableau suivant fournit un mappage de la priorité des bogues et du délai de résolution (ESRT) :
Priorité ESRT P0 2 jours ouvrables P1 5 jours ouvrables P2 10 jours ouvrables P3 15 jours ouvrables
Vous devez soumettre une demande de respin distincte par branche de publication. 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 demandes de respin.Une fois qu'une version est fournie et qu'une demande de respin est marquée comme corrigée, vous ne devez pas rouvrir la demande de respin pour ajouter des CL supplémentaires. Vous devez soumettre une nouvelle demande de respin s'il y a des correctifs supplémentaires qui doivent être fusionnés.
Pour chaque CL à l'étude, ajoutez les balises suivantes. La progression de la requête respin est bloquée sans cette information.
-
Bug: l'identifiant du bug doit être ajouté au message de commit pour chaque CL. -
Change-Id: doit être identique au Change-Id du changement de branche de base.
-
Si une demande de réponse nécessite votre réponse et que vous ne répondez pas dans les trois jours ouvrables, la priorité est rétrogradée d'un niveau (par exemple, P0 est rétrogradé à P1 ). Si vous ne répondez pas pendant deux semaines, le bogue est marqué comme Won't Fix (Obsolete) .
Soumettre une demande de réponse
Le diagramme suivant montre le processus de respin. Le processus commence lorsque le partenaire OEM (vous) soumet la demande de réponse.
Figure 2. Le processus de respin
Pour entrer dans le processus de respin :
- Remplissez le formulaire de demande GKI Respin . et contactez immédiatement votre responsable de compte technique Google. Ce formulaire crée un bogue de demande de respin GKI. Les bogues de demande Respin sont visibles pour vous (le demandeur), l'équipe GKI et les personnes spécifiques que vous ajoutez à la liste CC du bogue.
- Si vous avez déjà un correctif, la demande doit pointer vers la soumission du correctif dans AOSP afin que Google puisse l'examiner. S'il n'est pas possible de soumettre le correctif, le correctif doit être joint sous forme de fichier texte à la demande.
- 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.
- L'équipe Google GKI examine la demande et l'approuve ou vous la renvoie si des informations supplémentaires sont nécessaires.
- Une fois qu'un correctif a été convenu, le code de l'équipe Google GKI examine (CR+2) le changement. L'examen commence le calendrier ESRT. L'équipe GKI fusionne, construit, 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 demande comme étant fixe et référence la version respin. La version de respin est également publiée sur la page des versions de version de l'image générique du noyau (GKI) .
Qualifications GKI
| Types de builds GKI | Application de la qualité | Remarques |
|---|---|---|
| Hebdomadaire | Test de seiche
|
|
| Mensuel (certifié) | Test de seiche
| |
| Respins (certifié) | Test de seiche
|
|
Où obtenir des artefacts de construction
Les artefacts pour toutes les versions peuvent être obtenus sur ci.android.com .
Vous pouvez trouver plus d'informations sur le CI, y compris les résultats des tests sur le tableau de bord d'intégration continue d'Android .
FAQ
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 la version GKI publiée (sur laquelle 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, référencez 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 votre copie d'artefact GKI à partir de out/.../dist .
Le binaire GKI (y compris le correctif d'urgence) a-t-il été construit sur la dernière base de code ?
Non. Les réponses ne contiennent que des correctifs qui se trouvent au-dessus des noyaux certifiés mensuels qui ont été choisis. Ces réponses contiennent tous les correctifs de bogues de blocage de lancement signalés jusqu'à un moment donné par les OEM utilisant la version mensuelle de base correspondante. Voir l'exemple suivant de la façon dont ce type de scénario se produit.
- OEM1 et OEM2 décident d'utiliser la version binaire GKI à partir de novembre 2021.
- OEM1 et OEM2 détectent les problèmes qui nécessitent des correctifs pour la prise en charge. Ces patchs peuvent être différents ou identiques.
- Les réponses au-dessus du binaire de novembre 2021 ont des correctifs de blocage de lancement signalés par OEM1 et OEM2 pendant la fenêtre de réponse, mais rien de plus.
- Les problèmes mentionnés au deuxième point sont également inclus dans les versions mensuelles ultérieures de GKI.
Le respin d'octobre contient tous les correctifs OEM soumis, 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 patch ?
Ce n'est pas possible. Un chemin de respin "par OEM" n'est actuellement 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/appareil/modèle, l'équipe GKI peut s'assurer que le code ajouté par la modification ne s'exécute que sur l'appareil/modèle/SKU concerné.
Le principal avantage des respins unifiés est que chaque appareil utilisant la même base de version bénéficie les uns des autres, en particulier si les bogues qu'ils découvrent sont génériques et applicables à tous les utilisateurs. Les bogues du noyau central trouvés dans les tests des opérateurs 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 les risques liés à la mise en œuvre 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é collectés. Ceci est vu dans le journal des modifications (message de validation). Google ne révèle pas quel appareil spécifique il affecte, mais les OEM peuvent toujours trouver la description du problème et la solution dans le journal des modifications.