Demander une nouvelle rotation

Un respin est le processus de réémergence, de recompilation, de retest et de recertification d'un binaire après une version publique du noyau GKI.

Avant de demander une nouvelle rotation, veuillez noter les consignes suivantes.

Éligibilité et cycle de vie

  • Timing : vous ne pouvez demander de nouvelles compilations que sur les branches de version après le lancement d'une version publique initiale d'une compilation trimestrielle. Demandez des nouvelles versions pour les hooks de fournisseur ou d'autres fonctionnalités uniquement pour une branche de version donnée, pendant six mois maximum après la première version publique.
  • Sécurité et LTS : au bout de six mois, les branches ne peuvent faire l'objet d'une nouvelle version que pour les correctifs de sécurité mentionnés dans un bulletin de sécurité Android (ASB) ou les corrections de bugs critiques.
  • Obsolescence : lorsque les exigences LTS, définies par le bulletin de sécurité Android (ASB, Android Security Bulletin), entraînent la non-conformité de la branche, celle-ci est obsolète. Les demandes de nouvelle version 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 trimestrielles de GKI sous "Versions". Par exemple, la version de septembre 2025 est compatible avec les respins jusqu'en mars 2027. Cette date reflète la durée de vie de 18 mois de la version du noyau LTS 2.0 pour les versions publiées à partir de septembre 2025 (les versions antérieures à septembre 2025 avaient une durée de vie de 12 mois).
  • Champ d'application : ne demandez des respins que pour les corrections de bugs urgentes, les mises à jour de la liste des symboles ou pour appliquer un correctif à une fonctionnalité existante.

Normes d'envoi des correctifs

Pour respecter le délai de résolution standard attendu pour le traitement des demandes de réédition, tous les correctifs envoyés à une branche de version doivent respecter les règles techniques suivantes.

Source de référence et cherry-picks

  • Branche de développement en premier : tous les correctifs qui sont intégrés à la branche de version trimestrielle doivent déjà être fusionnés dans la branche de développement GKI principale. Par exemple, si un correctif est requis pour une nouvelle version de android15-6.6-2025-08, il doit déjà être fusionné dans android15-6.6.
  • Cherry-pick propre : vous devez cherry-picker les correctifs directement à partir de la branche de développement. Ne sélectionnez pas de commits dans d'autres branches de version (par exemple, ne sélectionnez pas de commits de 2025-08 à 2025-09), car cela peut entraîner des informations sur l'auteur ou le commit qui ne sont pas cohérentes avec la version de la branche de développement. Les correctifs dont les informations sont incohérentes ne seront pas acceptés.
  • Conserver les métadonnées : conservez les métadonnées de commit d'origine (par exemple, l'auteur et le code temporel d'origine). Utilisez git cherry-pick -x pour conserver les métadonnées.

Chaîne de commits

  • Chaîne séquentielle : si la demande de révision implique plusieurs correctifs, importez-les sous la forme d'une chaîne séquentielle unique de commits.
  • Placement des ABI et des KMI : si une nouvelle version multipatch inclut des mises à jour de l'interface du module du noyau (KMI) et de l'interface binaire d'application (ABI) (par exemple, des modifications de la liste des symboles ou des mises à jour des fichiers XML/STG), placez ces commits tout à la fin de la chaîne de commits.
  • Rebaser : si vous modifiez un commit parent dans la chaîne, vous devez rebaser tous les correctifs enfants sur la dernière révision de son correctif parent pour éviter les échecs de compilation.
  • Résolution des conflits : vérifiez qu'aucun marqueur de conflit n'est présent dans les correctifs.
  • Validation de la compilation : l'ensemble de la chaîne de commits doit être compilé avec succès.

Balises obligatoires

La progression de la demande de réédition est bloquée si les tags suivants ne figurent pas dans le message de commit :

  • Change-Id : doit être identique au Change-Id de la modification de la branche de développement.
    • Exception : Si le correctif a été fusionné dans la branche de développement dans le cadre d'une mise à jour LTS, il doit s'agir d'un cherry-pick de la version LTS et être mis en forme en tant que correctif UPSTREAM. Consultez Envoyer des correctifs aux noyaux communs Android.
  • Bug (existant) : les tags Bug: XYZ existants du commit de branche de développement d'origine ne doivent pas être supprimés.
  • Bug (nouvelle version) : vous devez ajouter une balise Bug: XYZ, où XYZ correspond à l'ID de bug associé à la demande de nouvelle version actuelle.
  • Mettez à jour le tag de commit UPSTREAM si nécessaire : lorsque vous sélectionnez une CL de la branche de développement pour la branche de version, et que la CL est taguée comme UPSTREAM, tenez compte des scénarios suivants :
    • Si le CL s'applique correctement à la branche de version, aucune action supplémentaire n'est requise de votre part.
    • Si la CL ne s'applique pas correctement, corrigez les conflits, mettez à jour le tag sur BACKPORT et documentez ce qui a été fait dans le cadre de la résolution des conflits. Consultez Exigences pour les rétroportages à partir du noyau Linux.

Priorité et ESRT

Attribuez une priorité (urgence) à la demande de réédition pour aider l'équipe GKI à la hiérarchiser. Cette priorité aide l'équipe GKI à mieux aider les partenaires en temps voulu.

  • Pour les demandes critiques ou urgentes, définissez la priorité sur P0.
  • Pour les demandes P0 et P1, vous devez également justifier l'urgence.

Le tableau suivant fournit une correspondance entre la priorité des bugs et le délai de résolution (ESRT) :

PrioritéESRT
P0Deux jours ouvrés
P15 jours ouvrés
P210 jours ouvrés
P315 jours ouvrables

Règles du SLA

  • Envoyez une demande de réédition distincte pour chaque branche de version.
  • Si vous souhaitez modifier une demande de réexécution marquée comme résolue, envoyez-en une nouvelle. Ne rouvrez pas la demande pour ajouter d'autres listes de modifications.
  • Si une demande de réanalyse 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 devient P1).
  • Si vous ne répondez pas au bout de deux semaines, le bug est marqué comme Non résolu (obsolète).

Envoyer une demande de réanalyse

Le schéma suivant illustre le processus de réédition. Le processus commence lorsque le partenaire OEM (vous) envoie la demande de réédition.

Processus de réinitialisation d'urgence Figure 1 : Procédure de nouvelle version d'urgence.

Pour envoyer une demande de réinitialisation :

  1. Remplissez le formulaire de demande de réédition du noyau GKI et contactez immédiatement votre point de contact Google.

    • Ce formulaire permet de créer un bug de demande de réédition GKI.

  2. Préparez vos patchs :

    • Vérifiez que le correctif est fusionné dans la branche de développement GKI.
    • Appliquez le correctif à la branche de version GKI appropriée.
    • Modifiez le correctif sélectionné pour inclure un tag Bug: XYZ citant l'ID de la demande de réédition.

    Exemple : Pour sélectionner une CL de android16-6.12 à android16-6.12-2025-12 :

    # 1. Checkout the target release branch
git checkout android16-6.12-2025-12

# 2. Fetch the upstream development branch (Source of Truth)
git fetch aosp android16-6.12

# 3. Cherry-pick the commit (Preserving metadata)
git cherry-pick -x <commit_hash>

# 4. Update the commit message to include the Respin Bug ID
# (Do not remove existing Bug IDs or change the Change-Id)

  3. Envoyez le bug. Voici ce qui se passe une fois que vous avez envoyé la demande :

    • Procédure d'examen après l'envoi d'une demande :

      • L'équipe Google GKI examine la demande et l'approuve ou vous la renvoie si elle a besoin de plus d'informations.
      • Une fois la correction approuvée, l'équipe Google GKI examine le code de la modification. Le minuteur ESRT est actif pendant cet examen. Toutefois, si le correctif est refusé ou nécessite une retouche, le minuteur ESRT est réinitialisé.
      • L'équipe GKI fusionne, compile, teste la régression et certifie la modification.

    • Version :

      • Le binaire est publié sur ci.android.com.
      • Le délai de l'ESRT se termine, et l'équipe Google GKI marque la demande comme résolue et fait référence à la version respin.
      • La version respin est également publiée sur la page des versions de Generic Kernel Image (GKI).