Richiedere una nuova scansione

Un respin è la procedura di riunione, ricompilazione, ritest e ricertificazione di un file binario dopo una release pubblica del kernel GKI.

Prima di richiedere un respin, tieni presente le seguenti linee guida.

Idoneità e ciclo di vita

  • Tempistiche: puoi richiedere i respin solo sui branch di release dopo il lancio di una release pubblica iniziale di una build trimestrale. Richiedi i respin per i vendor-hook o altre funzionalità solo per un determinato branch di release per un massimo di sei mesi dopo la release pubblica iniziale.
  • Sicurezza e LTS: dopo sei mesi, i branch sono idonei per il 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 branch di release GKI è inclusa nelle note sulla build di release GKI trimestrale in Release. Ad esempio, la release di settembre 2025 è supportata per i respin fino a marzo 2027. Questa data riflette la durata del ciclo di vita della versione 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 i respin solo per le correzioni di bug urgenti, gli 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 branch di release devono rispettare le seguenti regole tecniche.

Fonte attendibile e cherry-pick

  • Branch di sviluppo prima: tutte le patch che vengono inserite nel branch di release trimestrale devono essere già unite nel branch di sviluppo GKI principale. Ad esempio, se è necessaria una patch per un respin di android15-6.6-2025-08, deve essere già unita in android15-6.6.
  • Cherry-pick pulito: devi eseguire il cherry-pick delle patch direttamente dal branch di sviluppo. Non eseguire il cherry-pick da altri branch di release (ad esempio, non eseguire il cherry-pick da 2025-08 a 2025-09), in quanto ciò può comportare informazioni sull'autore o sul commit non coerenti con la versione nel branch 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 riguarda più patch, caricale come singola catena sequenziale di commit.
  • Posizionamento ABI e KMI: se un respin con più patch include aggiornamenti dell'interfaccia del modulo del kernel (KMI) e dell'interfaccia binaria dell'applicazione (ABI) (ad esempio, modifiche all'elenco dei simboli o aggiornamenti dei file XML/STG), inserisci questi commit alla fine della catena di commit.
  • Rebasing: se modifichi un commit principale nella catena, devi eseguire il rebase di tutte le patch secondarie sulla revisione più recente della patch principale per evitare errori di build.
  • 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 respin è bloccato se nel messaggio di commit non sono presenti i seguenti tag:

  • Change-Id: deve essere identico a Change-Id della modifica del branch di sviluppo.
    • Eccezione: se la patch è stata unita nel branch di sviluppo nell'ambito di un aggiornamento LTS, deve essere un cherry-pick della versione LTS e formattata come patch UPSTREAM. Consulta Come inviare patch ai kernel comuni di Android.
  • Bug (esistente): i tag Bug: XYZ esistenti del commit del branch di sviluppo originale non devono essere rimossi.
  • Bug (respin): devi aggiungere un nuovo Bug: XYZ tag, dove XYZ corrisponde all'ID bug associato alla richiesta di respin corrente.
  • Aggiorna il tag di commit UPSTREAM se necessario: quando esegui il cherry-pick di un CL dal branch di sviluppo al branch di release e il CL è taggato come UPSTREAM, considera i seguenti scenari:
    • Se il CL si applica in modo pulito al branch di release, non devi intraprendere ulteriori azioni.
    • Se il CL non si applica in modo pulito, correggi 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à ed ESRT

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

  • Per le richieste urgenti o sensibili al tempo, 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

Criteri SLA

  • Invia una richiesta di respin separata per ogni branch di release.
  • Se hai apportato modifiche a una richiesta di respin contrassegnata come corretta, invia una nuova richiesta di respin. Non riaprire la richiesta per aggiungere ulteriori elenchi delle modifiche (CL).
  • Se una richiesta di respin richiede la tua risposta e non rispondi entro tre giorni lavorativi, la priorità viene ridotta di un livello, ad esempio P0 viene ridotta a P1.
  • Se non rispondi per due settimane, il bug viene contrassegnato come Non verrà corretto (obsoleto).

Invia una richiesta di respin

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

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

Per inviare una richiesta di respin:

  1. Compila il modulo di richiesta di respin GKI e contatta immediatamente il tuo referente Google.

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

  2. Prepara le patch:

    • Verifica che la patch sia unita nel branch di sviluppo GKI.
    • Applica la patch al branch di release GKI appropriato.
    • Modifica la patch di cui hai eseguito il cherry-pick in modo da includere un tag Bug: XYZ che cita l'ID della richiesta di respin.

    Esempio: Per eseguire il cherry-pick di un 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 aver inviato la richiesta, si verifica quanto segue:

    • Procedura di revisione dopo l'invio:

      • Il team GKI di Google esamina la richiesta e la approva o la riassegna a te se sono necessarie ulteriori informazioni.
      • Una volta concordata una correzione, il team GKI di Google esegue la revisione del 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, testa la regressione e certifica la modifica.

    • Release:

      • Il file binario viene rilasciato su ci.android.com.
      • Il periodo di tempo ESRT termina e il team GKI di Google contrassegna la richiesta come corretta e fa riferimento alla build di respin.
      • La build di respin viene pubblicata anche nella pagina delle build di release di Generic Kernel Image (GKI).