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 de publication des GKI
Le GKI est publié tous les mois après le gel du 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.
| Builds certifiés mensuels de GKI | Date limite d'arrivée | Date de disponibilité du préchargement GKI | C'est bien cela ? |
|---|---|---|---|
| Novembre | 11 novembre 2024 | 27 novembre 2024 | Oui |
| Janvier | 14 janvier 2025 | 31 janvier 2025 | Oui |
| Mars | 14 mars 2025 | 31 mars 2025 | Oui |
Le tableau suivant ne s'applique qu'à android14-6.1 et android15-6.6.
| Builds certifiés mensuels de GKI | Date limite d'arrivée | Date de disponibilité du préchargement GKI | C'est bien cela ? |
|---|---|---|---|
| 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 |
| Janvier | 6 janvier 2025 | 22 janvier 2025 | Oui |
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.
| Builds certifiés mensuels de GKI | Date limite d'arrivée | Date de disponibilité du préchargement GKI | C'est bien cela ? |
|---|---|---|---|
| Novembre | 1er novembre 2024 | 15 novembre 2024 | Oui |
| Février | 3 février 2025 | 17 février 2025 | Oui |
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 tant qu'ils respectent les exigences de LTS dans le bulletin de sécurité Android (ASB).
Versions de développement hebdomadaires
Les versions sont testées avec Cuttlefish pour s'assurer qu'elles atteignent un niveau de qualité minimal.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'enregistrement, qui correspond généralement au deuxième build hebdomadaire de ce mois. Une fois la version candidate mensuelle sélectionnée, les nouvelles modifications ne seront plus acceptées dans la version du mois. 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, pour 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 respin d'urgence
Un respin désigne le processus de fusion, de recompilation, de nouveau test et de nouvelle certification d'un binaire après la publication publique du kernel 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 de six mois, vous devez demander un nouveau build 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 demandes de respin ne sont acceptées que pour une branche de version donnée pendant un maximum de six mois après la publication initiale. Après six mois, les branches ne peuvent être renvoyées 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), rendent la branche non conforme, elle est abandonnée. Les demandes de respin 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 concernant les versions 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 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 de LTS de l'avis ASB-2024-05.Les respins ne sont applicables qu'aux corrections de bugs urgentes, aux mises à jour de la liste des symboles ou pour appliquer un correctif afin de 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é dansandroid12-5.10.Vous devez sélectionner des correctifs dans la branche de développement principale de GKI et les importer dans la branche de publication mensuelle.
Dans la requête de refus, vous devez attribuer une priorité (urgence) à la requête. Cette priorité permet à l'équipe GKI de mieux aider les partenaires dans les meilleurs délais. 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 met en correspondance la priorité des bugs et le 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-08etandroid12-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 sous 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 nouvelle évaluation.
Figure 2 : Processus de nouvelle demande
Pour lancer le processus de respin:
- 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 refus GKI. Les bugs de requête de respin sont visibles par vous (demandeur), l'équipe GKI et des personnes spécifiques que vous ajoutez à la liste de copie de la bug.
- Si vous avez déjà un correctif, la demande doit faire référence à 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 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.
- L'équipe Google GKI examine la demande et l'approuve ou vous la renvoie si des informations supplémentaires sont nécessaires.
- Une fois un correctif convenu, l'équipe Google GKI examine le code (CR+2) de la modification. L'examen marque le début de la période d'évaluation de la sécurité des données. L'équipe GKI fusionne, compile, teste pour la régression et certifie la modification.
- 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).
Critères de sélection des GKI
| Types de builds GKI | Application des critères de qualité | Notes |
|---|---|---|
| Toutes les semaines | Tests Cuttlefish
|
|
| Mensuel (certifié) | Tests Cuttlefish
|
|
| Respin (certifié) | Tests Cuttlefish
|
|
Où obtenir des artefacts de compilation
Les artefacts de toutes les versions sont disponibles sur ci.android.com.
Pour en savoir plus sur l'intégration continue, y compris les résultats des tests, consultez le tableau de bord 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 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 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/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 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 les correctifs qui se trouvent au-dessus des noyaux certifiés mensuels choisis. Ces respins contiennent toutes les corrections de bugs bloquant le lancement 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 respin et teste les modifications avec tout le matériel disponible avant de créer un nouveau 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 utilisant 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.