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.

Frequenza di rilascio di GKI

GKI viene rilasciato con cadenza mensile dopo il blocco del 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.

Build mensili certificate GKI	Data limite per il check-in	Data di disponibilità del precaricamento GKI	Conferma?
Novembre	11 novembre 2024	27 novembre 2024	Sì
Gennaio	14 gennaio 2025	31 gennaio 2025	Sì
Marzo	14 marzo 2025	31 marzo 2025	Sì

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

Build mensili certificate GKI	Data limite per il check-in	Data di disponibilità del precaricamento GKI	Conferma?
Ottobre	1° ottobre 2024	14 ottobre 2024	Sì
Novembre	1° novembre 2024	15 novembre 2024	Sì
Dicembre	2 dicembre 2024	16 dicembre 2024	Sì
Gennaio	6 gennaio 2025	22 gennaio 2025	Sì

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.

Build mensili certificate GKI	Data limite per il check-in	Data di disponibilità del precaricamento GKI	Conferma?
Novembre	1° novembre 2024	15 novembre 2024	Sì
Febbraio	3 febbraio 2025	17 febbraio 2025	Sì

Validità della compilazione GKI per gli OEM

Gli OEM possono utilizzare un GKI Android rilasciato 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

Le release vengono testate con Cuttlefish per garantire che superino una soglia di qualità minima.

I binari GKI sono disponibili per il self-service da Android CI 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 boot.img testato che include un certificato inserito da Google per attestare che i binari sono stati compilati 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 respin 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 branch di rilascio dopo il lancio di una pubblicazione 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 Android Security Bulletin (ASB), fanno sì che il ramo non sia conforme, il ramo viene ritirato. 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.

• Tutti i patch che vanno nel ramo di rilascio mensile devono essere già uniti al ramo di sviluppo GKI principale. Ad esempio, se è richiesta una patch per un respin di android12-5.10-2022-09, deve essere già stata unita a 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 rifiuto sia per android12-5.10-2022-08 sia per android12-5.10-2022-09, devi creare due richieste di rifiuto.

• 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 modifica del ramo di base.

• Se una richiesta di rifiuto 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 entro due settimane, il bug viene contrassegnato come Non verrà risolto (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 possibili, inclusi 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 esamina il codice (CR+2) della modifica. La revisione avvia l'intervallo di tempo dell'ESRT. Il team GKI esegue l'unione, la compilazione, i test per 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 del kernel generico (GKI).

Qualifiche GKI

Tipi di build GKI	Applicazione della qualità	Notes
Settimanale	Test di seppia Avvio Sottoinsieme di VTS Sottoinsieme di CTS	Non certificato. Solo per test e avvio del dispositivo . Non può essere utilizzato per avviare i dispositivi.
Mensile (certificato)	Test di seppia Avvio VTS CTS Test hardware di riferimento Avvio VTS CTS
Nuovi giri (certificati)	Test di seppia Avvio VTS Sottoinsieme di CTS Test del dispositivo di riferimento Avvio VTS	Basato su una build certificata GKI. La build viene certificata dopo la qualifica.

Dove ottenere gli elementi 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 di Android Continuous Integration.

Domande frequenti

Di seguito sono riportate alcune domande frequenti relative alla procedura di rilascio del GKI.

È possibile creare un nuovo programma binario GKI in base a un GKI già rilasciato?

Sì, si tratta di un rifiuto. La procedura di respin è supportata a condizione che la compilazione GKI rilasciata (per la quale viene richiesto il respin) sia conforme ai requisiti LTS nel bollettino sulla sicurezza di 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 le patch aggiuntive ai kernel mensili certificati 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 file binario di novembre 2021 hanno correzioni per i blocchi del lancio segnalate sia da OEM1 che da OEM2 durante la finestra di respin, ma non altro.
• 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 di rifiuto "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 è specifico per un OEM, un dispositivo o un modello, può assicurarsi che il codice aggiunto dalla modifica venga eseguito solo sul dispositivo, sul modello o sullo SKU interessato.

Il principale vantaggio dei rifiuti unificati è che ogni dispositivo che utilizza la stessa base di rilascio 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.

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

Google non aggiungerà mai una modifica a una build di rifiuto finché il problema non sarà compreso e non saranno stati raccolti tutti i dettagli. Questo viene visualizzato nel log delle modifiche (messaggio di commit). Google non rivela il dispositivo specifico interessato, ma gli OEM possono sempre trovare la descrizione e la soluzione del problema nel log delle modifiche.