Richiedere una nuova scansione

Un respin è il processo di unione, ricompilazione, ritest e ricertificazione di un binario dopo una release pubblica del kernel GKI.

Prima di richiedere una nuova rotazione, tieni presente le seguenti linee guida.

Idoneità e ciclo di vita

  • Tempistiche:puoi richiedere respins solo sui rami di rilascio dopo il lancio di una release pubblica iniziale di una build trimestrale. Richiedi richieste di respin per vendor-hook o altre funzionalità solo per un determinato ramo di rilascio per un massimo di sei mesi dopo il rilascio pubblico iniziale.
  • Sicurezza e LTS:dopo sei mesi, i branch sono idonei al respin solo per le patch di sicurezza citate in un Bollettino sulla sicurezza di Android (ASB) o per le correzioni di bug critici.
  • Ritiro:quando i requisiti LTS, definiti dal Bollettino sulla sicurezza di Android (ASB), rendono il branch non conforme, questo viene ritirato. Le richieste di respin per i branch ritirati non vengono accettate.
    • La data di ritiro di un determinato ramo di release di GKI è inclusa nelle note di build di release di GKI trimestrali nella sezione Release. Ad esempio, la release di settembre 2025 è supportata per i respins fino a marzo 2027. Questa data riflette la durata del kernel LTS 2.0 di 18 mesi per le release a partire da settembre 2025 (le release precedenti a settembre 2025 avevano una durata di 12 mesi).
  • Ambito:richiedi respins solo per correzioni di bug urgenti, aggiornamenti dell'elenco dei simboli o per applicare una patch per correggere una funzionalità esistente.

Standard di invio delle patch

Per rispettare il tempo di risoluzione standard previsto (ESRT) per l'elaborazione delle richieste di respin, tutte le patch inviate a un ramo di rilascio devono rispettare le seguenti regole tecniche.

Fonte attendibile e selezione mirata

  • Prima il ramo di sviluppo:tutte le patch che entrano nel ramo di rilascio trimestrale devono essere già state unite al ramo di sviluppo principale di GKI. Ad esempio, se è necessaria una patch per una nuova versione di android15-6.6-2025-08, deve essere già unita a android15-6.6.
  • Cherry-pick pulito:devi selezionare le patch direttamente dal ramo di sviluppo. Non selezionare in modo selettivo da altri rami di rilascio (ad esempio, non selezionare da 2025-08 a 2025-09), in quanto ciò può comportare informazioni sull'autore o sul commit incoerenti con la versione nel ramo di sviluppo. Le patch con informazioni incoerenti non verranno accettate.
  • Conserva i metadati:conserva i metadati del commit originale (ad esempio, autore, timestamp originale). Utilizza git cherry-pick -x per conservare i metadati.

Catena di commit

  • Catena sequenziale:se la richiesta di respin coinvolge più patch, caricale come una singola catena sequenziale di commit.
  • Posizionamento di ABI e KMI:se un respin con più patch include aggiornamenti dell'interfaccia del modulo kernel (KMI) e dell'interfaccia binaria dell'applicazione (ABI) (ad esempio, modifiche all'elenco dei simboli o aggiornamenti dei file XML/STG), posiziona questi commit alla fine della catena di commit.
  • Rebase: se modifichi un commit principale nella catena, devi eseguire il rebase di tutte le patch secondarie in base all'ultima revisione della patch principale per evitare errori di compilazione.
  • Risoluzione dei conflitti:verifica che non siano presenti indicatori di conflitto in nessuna patch.
  • Verifica della build:l'intera catena di commit deve essere compilata correttamente.

Tag obbligatori

L'avanzamento della richiesta di rigenerazione è bloccato senza i seguenti tag nel messaggio di commit:

  • Change-Id: deve essere identico a Change-Id della modifica del ramo di sviluppo.
  • Bug (esistente): i tag Bug: XYZ esistenti del commit del ramo di sviluppo originale non devono essere rimossi.
  • Bug (respin): devi aggiungere un nuovo tag Bug: XYZ, dove XYZ corrisponde all'ID bug associato alla richiesta di respin corrente.
  • Aggiorna il tag di commit UPSTREAM, se necessario: quando esegui il cherry-picking di una CL dal ramo di sviluppo al ramo di rilascio e la CL è taggata come UPSTREAM, considera gli scenari seguenti:
    • Se la CL viene applicata correttamente al ramo di rilascio, non devi eseguire altre azioni.
    • Se la CL non viene applicata correttamente, risolvi i conflitti, aggiorna il tag a BACKPORT e documenta le operazioni eseguite nell'ambito della risoluzione dei conflitti. Consulta Requisiti per i backport da Linux mainline.

Priorità e ESRT

Assegna una priorità (urgenza) alla richiesta di respin per aiutare il team GKI a stabilire le priorità. Questa priorità aiuta il team GKI ad assistere meglio i partner in modo tempestivo.

  • Per le richieste critiche o urgenti, contrassegna la priorità come P0.
  • Per le richieste P0 e P1, devi anche giustificare l'urgenza.

La seguente tabella fornisce una mappatura della priorità dei bug e del tempo di risoluzione (ESRT):

PrioritàESRT
P02 giorni lavorativi
P15 giorni lavorativi
P210 giorni lavorativi
P315 giorni lavorativi

Policy SLA

  • Invia una richiesta di respin separata per ogni ramo di rilascio.
  • Se hai modifiche da apportare a una richiesta di rotazione contrassegnata come corretta, invia una nuova richiesta di rotazione. Non riaprire la richiesta per aggiungere ulteriori changelist (CL).
  • Se una richiesta di respin richiede una tua risposta e non rispondi entro tre giorni lavorativi, la priorità viene declassata di un livello, ad esempio, P0 viene declassata a P1.
  • Se non rispondi per due settimane, il bug viene contrassegnato come Non risolvibile (obsoleto).

Inviare una richiesta di rotazione

Il seguente diagramma mostra la procedura di rigenerazione. La procedura inizia quando il partner OEM (tu) invia la richiesta di respin.

Procedura di rigenerazione di emergenza Figura 1. Procedura di respin di emergenza.

Per inviare una richiesta di rigenerazione:

  1. Compila il modulo di richiesta di respin del GKI e contatta immediatamente il tuo punto di contatto Google.

    • Questo modulo crea un bug di richiesta di respin GKI.

  2. Prepara le patch:

    • Verifica che la patch sia unita al ramo di sviluppo GKI.
    • Applica la patch al ramo di rilascio GKI appropriato.
    • Modifica la patch selezionata in modo da includere un tag Bug: XYZ che cita l'ID richiesta di respin.

    Esempio: Per selezionare una CL da android16-6.12 a 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. Invia il bug. Dopo l'invio della richiesta, si verifica quanto segue:

    • Procedura di revisione dopo l'invio:

      • Il team di Google GKI esamina la richiesta e la approva o la riassegna a te se sono necessarie ulteriori informazioni.
      • Una volta concordata una correzione, il team Google GKI esamina il codice della modifica. Il timer ESRT è attivo durante questa revisione. Tuttavia, se la patch viene rifiutata o richiede una rielaborazione, il timer ESRT viene reimpostato.
      • Il team GKI unisce, compila, esegue test di regressione e certifica la modifica.

    • Release: