Cette page explique comment le GKI est publié, y compris les versions hebdomadaires, mensuelles et exceptionnelles. Ce document vise à fournir aux OEM la procédure à suivre pour récupérer le GKI, solutions d'urgence. Les OEM peuvent également utiliser les GKI développement pour en savoir plus sur la façon dont ils peuvent collaborer avec l'équipe du noyau Android pour 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'aux
android13-5.10
android13-5.15,
et
android14-5.15
Pour connaître les dates de sortie en septembre 2024, consultez cette annonce.
| Builds certifiés GKI mensuels | Date limite d'arrivée | Date de préchargement GKI | C'est bien cela ? |
|---|---|---|---|
| Novembre | 11 novembre 2024 | 27 novembre 2024 | Oui |
| Janvier | 17 janvier 2025 | 31 janvier 2025 | Oui |
| Février | 14 février 2025 | 28 février 2025 | Oui |
Le tableau suivant ne s'applique qu'aux
android14-6.1
et
android15-6.6
Pour connaître les dates de sortie en septembre 2024, consultez cette annonce.
| Builds certifiés GKI mensuels | Date limite d'arrivée | Date de préchargement GKI | Confirmé ? |
|---|---|---|---|
| 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 de android12-5.10 seront publiées tous les trimestres et
publiées en milieu de mois.
Le tableau suivant ne s'applique qu'aux
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 les builds certifiés GKI, à condition qu'ils soient conformes aux exigences LTS du Bulletin de sécurité Android (ASB)
Versions de développement hebdomadaires
Les versions sont testées avec Cuttlefish pour vous assurer qu'elles répondent à un seuil 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 sont pas certifiés, mais peuvent être utilisés une référence pour le développement et les tests. Les builds hebdomadaires ne peuvent pas être utilisés pour les builds d'appareil de production pour les utilisateurs finaux.
Versions certifiées mensuelles
Les versions mensuelles de GKI contiennent un fichier boot.img testé qui inclut un objet
inséré un certificat pour attester que les binaires ont été créés à partir d'une source connue
du code de référence.
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 à la deuxième compilation hebdomadaire de ce mois-là. Une fois la version mensuelle candidate sélectionnée, les nouveaux les modifications ne seront pas acceptées dans la version du mois en cours. Pendant la fenêtre de fermeture uniquement pour les bugs qui provoquent l'échec du test. 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 de lancement de GKI
Processus de renvoi d'urgence
Un respin désigne le processus de fusion, de recompilation, de nouveau test et de nouvelle certification d'un binaire après une version publique du kernel GKI. Vous pouvez demander la résolution d'un binaire certifié pour l'un des éléments suivants : circonstances:
- 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 jusqu'à six mois après la publication de la branche. Passé ce délai, vous devez : demander un renvoi pour appliquer des correctifs de sécurité à une branche.
Consignes concernant les demandes de renvoi
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 une version publique initiale d'une compilation mensuelle a été lancé.
Les demandes de relance ne sont acceptées que pour une branche de publication donnée pour un maximum six mois après la sortie publique initiale. Après six mois, 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éfini par le bulletin de sécurité Android (ASB) entraîner la non-conformité de la branche, celle-ci est obsolète. Renvoyer les requêtes ne sont pas acceptés pour les branches obsolètes. La date d'abandon d'un GKI donné la branche de publication 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 une fois par an. Par exemple,
android12-5.10-2023-07(5.10.177) n'est plus compatible avec les respins après le 1er mai 2024, carandroid12-5.10-2023-07branche (5.10.177) n'est pas conforme aux exigences LTS de l'ASB-2024-05.Les résolutions ne s'appliquent qu'aux corrections de bugs urgentes, aux mises à jour de la liste des symboles ou afin d'appliquer un correctif pour corriger une caractéristique existante.
Tous les correctifs destinés à la branche de version mensuelle doivent déjà être fusionnés dans la branche principale du développement GKI. Par exemple, si un correctif est nécessaire pour une retour de
android12-5.10-2022-09, il doit déjà être fusionné avecandroid12-5.10Vous devez sélectionner les correctifs de la branche principale de développement GKI et importez le correctif 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 requêtes P0 et P1, vous devez également justifier l'urgence. Le tableau suivant fournit une Mappage de la priorité du 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 pour chaque branche de release. Par exemple, si un respin est nécessaire pour
android12-5.10-2022-08etandroid12-5.10-2022-09, vous devez créer deux requêtes de respins.Une fois qu'un build est fourni et qu'une requête de relance est marquée comme corrigée, vous ne doit pas rouvrir la requête de relance pour ajouter des CL supplémentaires. Vous devez envoyer un nouveau renvoyer la requête si des correctifs supplémentaires doivent être fusionnés.
Pour chaque CL prise en compte, ajoutez les balises suivantes.
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 demande de respin nécessite votre réponse et que vous ne répondez pas dans les trois jours ouvrés, la priorité est rétrogradée d'un niveau (par exemple, P0 revient à P1). Si vous ne répondez pas pendant deux semaines, le bug est marqué comme Won't Fix (Obsolete) (Ne sera pas corrigé (Obsolète)).
Envoyer une demande de renvoi
Le schéma suivant illustre le processus de respinage. Le processus commence lorsque Le partenaire OEM (vous) envoie la demande de renvoi.
Figure 2 : Le processus de respin
Pour lancer 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 GKI respin. 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 vous n'envoyez pas le correctif doit être joint sous forme de fichier texte à la requête.
- 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 commence le délai ESRT. L'équipe GKI fusionne, compile et teste contre la régression et certifie la modification.
- Le binaire est libéré pour ci.android.com. La Le délai ESRT se termine, et l'équipe Google GKI marque la demande comme étant corrigée. référencer la compilation respin. Le build respin est également publié sur le 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
<ph type="x-smartling-placeholder">
|
|
| Respins (certifiés) | Tests de seiches
<ph type="x-smartling-placeholder">
|
|
Emplacement d'obtention des artefacts de compilation
Les artefacts de toutes les versions peuvent être récupérés à partir de ci.android.com.
Pour en savoir plus sur la CI, y compris sur le test dans l'intégration continue Android tableau de bord.
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 le build GKI publié (sur lequel le respin est demandé) est conforme à la version LTS. dans le bulletin de sécurité Android (ASB).
Est-il possible de reproduire des 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 :
commande:
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 rotation d'urgence) a-t-il été créé sur la dernière version du codebase ?
Non. Les résolutions ne contiennent que des correctifs qui s'ajoutent aux correctifs mensuels les noyaux qui ont été 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 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érentes ou identiques.
- Les retours au-dessus du binaire de novembre 2021 ont un blocage lors du lancement. correctifs signalés à la fois par OEM1 et OEM2 pendant la fenêtre de relance, mais plus encore.
- Les problèmes mentionnés dans le deuxième point sont également inclus dans les GKI suivants des versions mensuelles.
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. Une métrique "par OEM" de respin n'est pas évolutif. Au lieu de cela, l'équipe GKI examine chaque changement qui revient à compilation et teste les modifications sur tout le matériel disponible avant de créer une nouvelle créer. Si l'équipe GKI constate que le problème est spécifique à un OEM, à un appareil l'équipe GKI peut s'assurer que le code ajouté par la modification ne s'exécute 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. Bugs principaux du noyau détectés dans les tests auprès des opérateurs est un exemple spécifique de ce concept.
Y a-t-il des situations 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 ont été collectés. Cela se voit 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.