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 donner aux OEM des lignes directrices 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 guide de développement GKI pour en savoir plus sur la manière dont ils peuvent travailler avec l'équipe du noyau Android afin d'optimiser le noyau GKI pour leurs produits.
Cadence de publication de GKI
GKI est publié à 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 .
| Constructions certifiées mensuelles GKI | Date limite d'enregistrement | Date de préparation du 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 |
| 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 | 7 décembre 2023 | 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 |
| Peut | 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 d' android14-5.15 conformément à la cadence mensuelle spécifiée indiquée dans le tableau ci-dessous.
| Constructions certifiées mensuelles GKI | Date limite d'enregistrement | Date de préparation du 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 | 1 avril 2024 | 17 avril 2024 | Oui |
| Peut | 1 mai 2024 | 17 mai 2024 | Oui |
| Juin | 3 juin 2024 | 17 juin 2024 | Oui |
| Juillet | 1 juillet 2024 | 15 juillet 2024 | Oui |
| Août | 1 août 2024 | 16 août 2024 | Oui |
| Septembre | 2 septembre 2024 | 16 septembre 2024 | Oui |
| Octobre | 1 octobre 2024 | 14 octobre 2024 | Oui |
| Novembre | 1 novembre 2024 | 15 novembre 2024 | Oui |
| Décembre | 2 décembre 2024 | 16 décembre 2024 | Oui |
Sortie d'Android 12 GKI
Après mai 2023, les versions android12-5.10 GKI sont publiées tous les deux mois et publiées au milieu du mois. Le tableau suivant s'applique uniquement à android12-5.10 .
| Constructions certifiées mensuelles GKI | Date limite d'enregistrement | Date de préparation du 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 |
| Peut | 1 mai 2024 | 17 mai 2024 | Oui |
Validité de build GKI pour les OEM
Les OEM peuvent utiliser une GKI Android récemment publiée. Les OEM peuvent lancer des versions certifiées GKI à condition qu'elles soient conformes aux exigences LTS du Bulletin de sécurité Android (ASB).
Sorties de développement hebdomadaires
Les rejets sont testés avec des seiches pour garantir qu'elles satisfont à une barre de qualité minimale .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ées, mais pourront être utilisées comme base de référence pour le développement et les tests. Les builds hebdomadaires ne peuvent pas être utilisées pour les builds d’appareils de production pour les utilisateurs finaux.
Sorties 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é construits à partir d'une base 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'enregistrement, qui correspond généralement à la deuxième version hebdomadaire de ce mois. Une fois la version candidate mensuelle sélectionnée, les nouvelles modifications ne seront pas acceptées dans la version de ce mois. Pendant la période de fermeture, seuls les correctifs pour les bogues provoquant l'échec des tests peuvent être résolus. La version candidate est soumise à une assurance qualité, comme décrit dans la section Qualification GKI , pour garantir la réussite des tests de conformité sur la version GSI+GKI avec un appareil de référence ainsi que sur la seiche.
Figure 1. Chronologie de la publication de GKI
Processus de relance d'urgence
Un respin fait référence au processus de réémergence, de reconstruction, de nouveau test et de recertification d'un binaire après une version publique du noyau GKI . Vous pouvez demander une réactivation d'un binaire certifié dans l'une des circonstances suivantes :
- Pour mettre à jour une liste de symboles.
- Pour appliquer un correctif à un bug, y compris les bugs 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 patch de sécurité (au bout de 6 mois).
Les correctifs de sécurité sont automatiquement fusionnés dans une branche de version jusqu'à 6 mois après la sortie de la branche. Après le délai de 6 mois, vous devez demander une nouvelle rotation pour appliquer les correctifs de sécurité à une succursale.
Avant de demander une nouvelle rotation, notez les directives suivantes :
Les respins ne sont autorisés que sur les branches de version après le lancement d'une première version publique d'une version mensuelle .
Les demandes de réponse ne sont acceptées que pour une branche de version donnée pendant un maximum de six mois après la version publique initiale. Après six mois, les succursales ne sont éligibles au respin que pour les correctifs de sécurité cités dans un bulletin de sécurité Android .
Lorsque les exigences LTS , définies par l' Android Security Bulletin (ASB), rendent la branche non conforme, la branche est obsolète. Les demandes de réactivation pour les branches obsolètes ne sont pas acceptées. La date de dépréciation pour 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 chaque année en mai et novembre. Par exemple, la branche
android12-5.10-2023-07(5.10.177) n'est pas prise en charge pour les relances après le 1er mai 2024, car la brancheandroid12-5.10-2023-07(5.10.177) n'est pas conforme aux Exigences LTS de l’ASB-2024-05.Les Respins ne sont applicables que pour les corrections de bogues urgentes, les mises à jour de la liste de symboles ou pour appliquer un correctif pour corriger une fonctionnalité existante.
Tous les correctifs entrant dans la branche des versions mensuelles doivent déjà être fusionnés dans la branche principale de développement de GKI. Par exemple, si un correctif est requis pour une réactivation de
android12-5.10-2022-09, il doit déjà être fusionné dansandroid12-5.10.Vous devez sélectionner les correctifs dans la branche de développement principale de GKI et télécharger le correctif dans la branche des versions mensuelles.
Dans la demande de réponse, vous devez attribuer une priorité (urgence) à la demande. Cette priorité aide l'équipe GKI à mieux aider 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 de 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 ouvrés P1 5 jours ouvrés P2 10 jours ouvrables P3 15 jours ouvrables
Vous devez soumettre une demande de réponse distincte par branche de version. Par exemple, si une relance est nécessaire pour
android12-5.10-2022-08etandroid12-5.10-2022-09, vous devez créer deux demandes de relance.Une fois qu'une version est fournie et qu'une demande de réponse est marquée comme corrigée, vous ne devez pas rouvrir la demande de réponse pour ajouter des CL supplémentaires. Vous devez soumettre une nouvelle demande de réactivation si des correctifs supplémentaires doivent être fusionnés.
Pour chaque CL considéré, ajoutez les balises suivantes. La progression de la demande de réponse est bloquée sans cette information.
-
Bug: l'ID 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 bug est marqué comme Won't Fix (Obsolete) .
Soumettre une demande de réponse
Le diagramme suivant montre le processus de relance. Le processus commence lorsque le partenaire OEM (vous) soumet la demande de réponse.
Figure 2. Le processus de relance
Pour entrer dans le processus de relance :
- Remplissez le formulaire de demande GKI Respin . et contactez immédiatement votre responsable de compte technique Google. Ce formulaire crée un bug de demande de réponse GKI. Les bogues de demande de réponse sont visibles par vous (le demandeur), l'équipe GKI et les personnes spécifiques que vous ajoutez à la liste CC du bogue.
- Si vous disposez déjà d'un correctif, la demande doit pointer vers la soumission du correctif dans AOSP afin que Google puisse l'examiner. Si la soumission du correctif n'est pas possible, le correctif doit être joint sous forme de fichier texte à la demande.
- Si vous ne disposez 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 est convenu, le code de l'équipe Google GKI examine (CR+2) la modification. L’examen commence la période 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 prend fin et l'équipe Google GKI marque la demande comme corrigée et fait référence à la version respin. La version respin est également publiée sur la page des versions de version Generic Kernel Image (GKI) .
Qualifications GKI
| Types de versions GKI | Application de la qualité | Remarques |
|---|---|---|
| Hebdomadaire | Test de seiche
|
|
| Mensuel (certifié) | Test de seiche
| |
| Respins (certifiés) | Test de seiche
|
|
Où obtenir des artefacts de construction
Les artefacts de 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 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 relance est pris en charge tant que la version GKI publiée (sur laquelle la relance est demandée) est conforme aux exigences LTS du Bulletin de sécurité Android (ASB).
Est-il possible de reproduire les binaires GKI ?
Oui, faites référence à 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 depuis 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 Respins ne contiennent que des correctifs qui s'ajoutent aux noyaux certifiés mensuels qui ont été choisis. Ces réponses contiennent toutes les corrections de bogues bloquant le lancement signalées jusqu'à un moment donné par les OEM utilisant la version mensuelle de base correspondante. Consultez l’exemple suivant pour voir comment 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 des problèmes qui nécessitent des correctifs pour la prise en charge. Ces correctifs peuvent être différents ou identiques.
- Les relances 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 relance, mais rien de plus.
- Les problèmes mentionnés dans le deuxième point sont également inclus dans les versions mensuelles ultérieures de GKI.
La réponse d'octobre contient tous les correctifs soumis 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 patch ?
Ce n'est pas possible. Un chemin de réponse « 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 garantir que le code ajouté par la modification ne s'exécute que sur l'appareil/modèle/SKU concerné.
Le principal avantage des réponses unifiées est que chaque appareil utilisant la même base de versions bénéficie les uns des autres, surtout si les bogues découverts sont génériques et applicables à tous les utilisateurs. Les bogues du noyau trouvés lors des 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'est pas compris et que tous les détails n'ont pas été collectés. Ceci est visible dans le journal des modifications (message de validation). Google ne révèle pas quel appareil spécifique cela affecte, mais les OEM peuvent toujours trouver la description du problème et la solution dans le journal des modifications.