Processo di rilascio GKI (Generic Kernel Image)

Questa pagina descrive come viene rilasciato il GKI, incluse le release settimanali, mensili e di emergenza al di fuori della fascia. L'obiettivo di questo documento è fornire agli OEM linee guida su dove recuperare il GKI e sulla procedura per le correzioni di emergenza out-of-band. Gli OEM possono anche utilizzare lo sviluppo GKI per scoprire di più su come collaborare con il team del kernel di Android per ottimizzare il kernel GKI per i propri prodotti.

Cadenza di rilascio GKI

GKI viene rilasciato con cadenza mensile dopo il blocco KMI.

Rilascio GKI per Android 13, 14 e 15

La tabella seguente è applicabile solo a android13-5.10, android13-5.15, e android14-5.15.

La tabella seguente è applicabile solo a android14-6.1 e android15-6.6.

Release GKI di Android 12

Dopo maggio 2024, le release del android12-5.10 GKI avranno cadenza trimestrale e verranno pubblicate a metà mese. La tabella seguente è applicabile solo a android12-5.10.

Validità della build GKI per gli OEM

Gli OEM possono utilizzare una GKI di Android rilasciata di recente. Gli OEM possono lanciare i propri dispositivi con build certificate GKI, a condizione che siano conformi ai requisiti LTS riportati nel bollettino Android Security Bulletin (ASB).

Uscite settimanali per lo sviluppo

I file binari GKI sono disponibili per il self-service da CI per Android man mano che le modifiche vengono unite. Le build settimanali non verranno certificate, ma possono essere utilizzate come riferimento per lo sviluppo e i test. Le build settimanali non possono essere utilizzate per le build dei dispositivi di produzione per gli utenti finali.

Uscite mensili certificate

Le release mensili di GKI contengono un elemento boot.img testato che include un certificato inserito da Google per attestare che i file binari sono stati creati da una base di codice sorgente nota.

Ogni mese viene selezionata una release candidate mensile GKI (non certificata) dopo la data di scadenza del check-in, che in genere è la seconda compilazione settimanale del mese. Una volta selezionata la release candidate mensile, le nuove modifiche non verranno accettate nella release del mese in questione. Durante il periodo della finestra chiusa, è possibile risolvere solo i bug che causano l'errore del test. La release candidate viene sottoposta a controllo qualità, come descritto nella sezione relativa alla qualifica GKI, per garantire il superamento dei test di conformità nella compilazione GSI+GKI con un dispositivo di riferimento e con seppia.

Figura 1. Cronologia delle release di GKI

Procedura di rifiuto di emergenza

Un respin si riferisce al processo di riunione, ricostruzione, nuovo test e nuova certificazione di un file binario dopo una release pubblica del kernel GKI. Puoi richiedere il rifiuto di un file binario certificato per una delle seguenti circostanze:

• Per aggiornare un elenco di simboli.
• Per applicare una correzione a un bug, inclusi i bug rilevati durante l'approvazione in laboratorio dell'operatore.
• Per aggiungere un hook del fornitore.
• Per applicare una patch a una funzionalità esistente.
• Per applicare una patch di sicurezza (dopo 6 mesi).

Le patch di sicurezza vengono unite automaticamente a un ramo di rilascio fino a 6 mesi dopo il rilascio del ramo. Dopo la scadenza di 6 mesi, devi richiedere un nuovo rifiuto per applicare le patch di sicurezza a un ramo.

Linee guida per le richieste di nuovo spin

Prima di richiedere un nuovo rifiuto, tieni presente le seguenti linee guida:

• I respin sono consentiti solo nei rami di release dopo il lancio di una release pubblica iniziale di una build mensile.

• Le richieste di respingimento vengono accettate solo per un determinato ramo di rilascio per un massimo di sei mesi dopo il rilascio pubblico iniziale. Dopo sei mesi, i branch sono idonei per il rifiuto solo per le patch di sicurezza citate in un Bollettino sulla sicurezza di Android.

• Quando i requisiti LTS, definiti dal Bollettino sulla sicurezza Android (ASB), causano la non conformità del ramo, questo viene deprecato. Le richieste di respin per i branch ritirati non sono accettate. La data di ritiro di un determinato ramo di release GKI è inclusa nelle note di build della release GKI mensile in Release. Per la pianificazione futura, i requisiti LTS vengono aggiornati ogni anno a maggio e a novembre. Ad esempio, il ramo android12-5.10-2023-07 (5.10.177) non è supportato per i rifiuti dopo il 1° maggio 2024 perché il ramo android12-5.10-2023-07 (5.10.177) non è conforme ai requisiti LTS di ASB-2024-05.

• I respin sono applicabili solo per correzioni urgenti di bug, aggiornamenti degli elenchi di simboli o per applicare una patch per correggere una funzionalità esistente.

• Tutte le patch che vanno nel ramo di rilascio mensile devono essere già unite al ramo di sviluppo GKI principale. Ad esempio, se è necessaria una patch per un respin di android12-5.10-2022-09, deve essere già unita in android12-5.10.

• Devi scegliere le patch dal ramo di sviluppo GKI principale e caricarle nel ramo di rilascio mensile.

• Nella richiesta di rifiuto, devi assegnare una priorità (urgenza) alla richiesta. Questa priorità aiuta il team GKI ad assistere meglio i partner in modo tempestivo. Per le richieste critiche o urgenti, assegna la priorità P0. Per le richieste P0 e P1, devi anche giustificare l'urgenza. La tabella seguente fornisce una mappatura della priorità del bug e del tempo di risoluzione (ESRT):

  Priorità	ESRT
  P0	2 giorni lavorativi
  P1	5 giorni lavorativi
  P2	10 giorni lavorativi
  P3	15 giorni lavorativi

• Devi inviare una richiesta di rifiuto separata per ogni ramo di rilascio. Ad esempio, se è necessario un respin sia per android12-5.10-2022-08 che per android12-5.10-2022-09, devi creare due richieste respin.

• Dopo aver fornito una build e aver contrassegnato una richiesta di rifiuto come risolta, non devi riaprire la richiesta di rifiuto per aggiungere altri CL. Devi inviare una nuova richiesta di respingimento se sono presenti patch aggiuntive da unire.

• Per ogni CL in esame, aggiungi i seguenti tag.

  • Bug: l'ID bug deve essere aggiunto al messaggio del commit per ogni CL.
  • Change-Id: deve essere identico al valore Change-Id della variazione del ramo di base.

• Se una richiesta di rifiuto richiede una 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 entro due settimane, il bug viene contrassegnato come Non risolvibile (obsoleto).

Inviare una richiesta di rifiuto

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

Figura 2. La procedura di rifiuto

Per avviare la procedura di rifiuto:

1. Compila il modulo di richiesta di risposta GKI. e contatta immediatamente il tuo Technical Account Manager di Google. Questo modulo crea un bug di richiesta di rifiuto GKI. I bug relativi alle richieste di respingimento sono visibili a te (l'autore della richiesta), al team GKI e a persone specifiche che aggiungi all'elenco Cc del bug.
   • Se hai già una correzione, la richiesta deve indicare l'invio della patch in AOSP in modo che Google possa esaminarla. Se non è possibile inviare la patch, deve essere allegata come file di testo alla richiesta.
   • Se non hai una correzione, la richiesta deve contenere quante più informazioni possibile, tra cui il numero di versione del kernel e i log, in modo che Google possa aiutarti a eseguire il debug del problema.
2. Il team GKI di Google esamina la richiesta e la approva o la riassegna a te se sono necessarie ulteriori informazioni.
3. Una volta concordata una correzione, il team GKI di Google (CR+2) esamina il codice della modifica. La revisione avvia l'intervallo di tempo dell'ESRT. Il team GKI unisce, crea, testa la regressione e certifica la modifica.
4. Il file binario viene rilasciato su ci.android.com. Il periodo di tempo dell'ESRT termina e il team GKI di Google contrassegna la richiesta come corretta e fa riferimento alla build di respin. La build respin viene pubblicata anche nella pagina delle build di release dell'immagine kernel generica (GKI).

Qualifiche GKI

Dove trovare gli artefatti della build

Gli elementi di tutte le release possono essere ottenuti da ci.android.com.

Puoi trovare ulteriori informazioni sull'integrazione continua, inclusi i risultati dei test, nella dashboard Integrazione continua di Android.

Domande frequenti

Di seguito sono riportate alcune domande frequenti relative al processo di rilascio di GKI.

È possibile creare un nuovo programma binario GKI basato su una GKI già rilasciata?

Sì, si tratta di un rifiuto. Il processo di respin è supportato purché la build GKI rilasciata (per la quale è richiesto il respin) sia conforme ai requisiti LTS nel Bollettino sulla sicurezza Android (ASB).

È possibile riprodurre i file binari GKI?

Sì, ecco un esempio:

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

Per riprodurre l'esempio, scarica manifest_$id.xml ed esegui il seguente comando:

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

Puoi recuperare la copia dell'elemento GKI da out/.../dist.

Il file binario GKI (inclusa la patch di spin di emergenza) è stato compilato sulla base di codice più recente?

No. I Respin contengono solo patch che si trovano sopra i kernel certificati mensili che sono stati scelti. Questi respin contengono tutte le correzioni dei bug che bloccano il lancio segnalate fino a un determinato momento dagli OEM che utilizzano la release mensile di base corrispondente. Di seguito è riportato un esempio di come si verifica questo tipo di scenario.

• OEM1 e OEM2 decidono di utilizzare la release binaria GKI di novembre 2021.
• OEM1 e OEM2 trovano problemi che richiedono patch per l'assistenza. Questi patch possono essere diversi o uguali.
• I respin sopra il programma binario di novembre 2021 presentano correzioni relative al blocco dell'avvio segnalate sia da OEM1 che da OEM2 durante la finestra di reso, ma niente di più.
• I problemi menzionati nel secondo punto sono inclusi anche nelle release mensili GKI successive.

Il rifiuto di ottobre include tutte le patch inviate dagli OEM, ma altre patch degli OEM ci interessano perché non sono state testate specificamente con i nostri prodotti. È possibile includere solo la nostra patch?

Non è possibile. Un percorso respin "per OEM" non è scalabile. Il team GKI esamina invece ogni singola modifica che viene inserita nelle build respin e la testa con tutto l'hardware disponibile prima di creare una nuova build. Se il team GKI rileva che il problema riguarda in modo specifico un OEM, un dispositivo o un modello, può garantire che il codice aggiunto dalla modifica venga eseguito solo sul dispositivo, modello o SKU interessato.

Il principale vantaggio dei rifiuti unificati è che ogni dispositivo che utilizza la stessa base di release ne trae vantaggio, soprattutto se i bug rilevati sono generici e applicabili a tutti gli utenti. I bug del kernel di base rilevati nei test dell'operatore sono un esempio specifico di questo concetto.

Ci sono situazioni in cui Google fornisce informazioni specifiche sulle patch degli OEM e sugli scenari di problemi, in modo che gli OEM possano valutare l'impatto e il rischio dell'implementazione delle patch nei loro prodotti?

Google non aggiunge alcuna modifica a una build di respin finché il problema non viene compreso e non sono stati raccolti tutti i dettagli. come visibile nel log delle modifiche (messaggio di commit). Google non rivela quale dispositivo specifico è interessato, ma gli OEM possono sempre trovare la descrizione del problema e la soluzione nel log delle modifiche.