Demander une nouvelle rotation

Un respin est le processus de fusion, de reconstruction, de test et de recertification d'un binaire après une publication publique du noyau GKI.

Avant de demander un respin, tenez compte des consignes suivantes.

Éligibilité et cycle de vie

• Timing : vous ne pouvez demander des respins que sur les branches de publication après le lancement d'une première publication publique d'une version trimestrielle. Ne demandez des respins pour les hooks de fournisseur ou d'autres fonctionnalités que pour une branche de publication donnée pendant six mois maximum après la publication publique initiale.
• Sécurité et LTS : au bout de six mois, les branches ne sont éligibles à un respin que pour les correctifs de sécurité mentionnés dans un bulletin sur la sécurité d'Android (ASB) ou les corrections de bugs critiques.
• Obsolescence : lorsque les exigences LTS, définies par le bulletin sur la sécurité d'Android (ASB), entraînent la non-conformité de la branche, celle-ci est obsolète. Les demandes de respin pour les branches obsolètes ne sont pas acceptées.
  • La date d'obsolescence d'une branche de publication 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 de noyau LTS 2.0 pour les versions à 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 afin de corriger une fonctionnalité existante.
• Versions GKI de 16 Ko : les respins à la demande pour les branches GKI de 16 Ko compatibles (android15-6.6, android16-6.12, et android17-6.18) suivent le même formulaire de demande de respin, les mêmes normes d'envoi de correctifs et le même processus de qualification que les builds de 4 Ko. Vous n'avez pas besoin de mettre à jour les noyaux de 4 Ko et de 16 Ko en même temps, bien que nous vous le recommandons.

Normes d'envoi de correctifs

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

Source de référence et cherry-picks

• Branche de développement d'abord : tous les correctifs qui entrent dans la branche de publication trimestrielle doivent déjà être fusionnés dans la branche de développement GKI principale. Par exemple, si un correctif est requis pour un respin de android15-6.6-2025-08, il doit déjà être fusionné dans android15-6.6.
• Cherry-pick propre : vous devez sélectionner les correctifs directement à partir de la branche de développement. Ne sélectionnez pas de correctifs à partir d'autres branches de publication (par exemple, ne sélectionnez pas de correctifs de 2025-08 à 2025-09), car cela peut entraîner des informations d'auteur ou de commit incohérentes avec la version de la branche de développement. Les correctifs contenant des informations 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 l'horodatage d'origine). Utilisez git cherry-pick -x pour conserver les métadonnées.

Chaîne de commit

• Chaîne séquentielle : si la demande de respin implique plusieurs correctifs, importez-les sous la forme d'une chaîne séquentielle unique de commits.
• Placement ABI et KMI : si un respin à plusieurs correctifs inclut des mises à jour de l'interface du module de noyau (KMI) et de l'interface binaire d'application (ABI) (par exemple, des modifications de la liste des symboles ou des mises à jour de fichiers XML/STG), placez ces commits tout à la fin de la chaîne de commit.
• Rebasage : 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 build.
• Résolution des conflits : vérifiez qu'aucun marqueur de conflit n'est présent dans un correctif.
• Vérification du build : l'ensemble de la chaîne de commit doit être compilé avec succès.

Tags obligatoires

La progression de la demande de respin est bloquée sans les tags suivants 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'une sélection 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 la branche de développement d'origine ne doivent pas être supprimés.
• Bug (respin) : vous devez ajouter un nouveau tag Bug: XYZ, où XYZ correspond à l'ID de bug associé à la demande de respin actuelle.
• Mettez à jour le tag de commit UPSTREAM si nécessaire : lorsque vous sélectionnez un CL de la branche de développement vers la branche de publication et que le CL est tagué comme UPSTREAM, tenez compte des scénarios suivants :
  • Si le CL s'applique correctement à la branche de publication, aucune action supplémentaire n'est requise de votre part.
  • Si le CL ne s'applique pas correctement, corrigez les conflits, remplacez le tag par BACKPORT, et documentez ce qui a été fait dans le cadre de la résolution des conflits. Consultez Exigences pour les backports à partir de Linux mainline.

Priorité et ESRT

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

• 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 une mise en correspondance de la priorité des bugs et du 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

Règles du SLA

• Envoyez une demande de respin distincte pour chaque branche de publication.
• Si vous avez apporté des modifications à une demande de respin marquée comme corrigée, envoyez une nouvelle demande de respin. Ne rouvrez pas la demande pour ajouter des listes de modifications supplémentaires (CL).
• Si une demande de respin nécessite une réponse de votre part et que vous ne répondez pas dans les trois jours ouvrés, la priorité est abaissée d'un niveau. Par exemple, P0 est abaissé à P1.
• Si vous ne répondez pas pendant deux semaines, le bug est marqué comme Ne sera pas corrigé (obsolète).

Envoyer une demande de respin

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

Figure 1 : Procédure de respin d'urgence

Pour envoyer une demande de respin :

1. Remplissez le formulaire de demande de respin GKI et contactez votre interlocuteur Google immédiatement.

   • Ce formulaire crée un bug de demande de respin GKI.

2. Préparez vos correctifs :

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

   Exemple : Pour sélectionner un CL de android16-6.12 vers 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. Les événements suivants se produisent après l'envoi de la demande :

   • Processus d'examen après l'envoi :

     • 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, l'équipe Google GKI procède à la revue de code de la modification. Le minuteur ESRT est actif pendant cet examen. Toutefois, si le correctif est rejeté ou nécessite une modification, le minuteur ESRT est réinitialisé.
     • L'équipe GKI fusionne, compile, teste la régression et certifie la modification.

   • Publication :

     • Le binaire est publié sur ci.android.com.
     • Le délai ESRT se termine et l'équipe Google GKI marque la demande comme corrigée et fait référence au build de respin.
     • Le build de respin est également publié sur la page des builds de publication Generic Kernel Image (GKI).