Processo di rilascio GKI (Generic Kernel Image)

Questa pagina descrive come viene rilasciato GKI, inclusi i rilasci settimanali, trimestrali e di emergenza fuori banda. L'obiettivo di questo documento è fornire agli OEM una linea guida su dove recuperare il GKI, nonché la procedura per le correzioni di emergenza out-of-band. Gli OEM possono anche utilizzare lo sviluppo di GKI per scoprire di più su come collaborare con il team del kernel Android per ottimizzare il kernel GKI per i loro prodotti.

Cadenza di rilascio di GKI

La GKI viene rilasciata con cadenza trimestrale dopo il blocco dell'interfaccia del modulo del kernel (KMI).

Validità della build GKI per gli OEM

Gli OEM possono utilizzare una GKI Android rilasciata di recente. Gli OEM possono eseguire l'avvio con build certificate GKI, a condizione che siano conformi ai requisiti LTS riportati nel Bollettino sulla sicurezza di Android (ASB).

Uscite settimanali per gli sviluppatori

I file 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 base di riferimento per lo sviluppo e il test. Le build settimanali non possono essere utilizzate per le build dei dispositivi di produzione per gli utenti finali.

Uscite trimestrali certificate

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

Ogni trimestre, viene selezionato un candidato al rilascio trimestrale del GKI (non certificato) dopo la data limite di check-in, che di solito è la seconda build settimanale di quel mese. Una volta selezionata la release candidata trimestrale, le nuove modifiche non verranno accettate nella release del mese. Durante il periodo di chiusura della finestra, possono essere risolti solo i bug che causano l'esito negativo del test. La release candidate viene sottoposta al controllo della qualità, come descritto nella sezione qualificazione GKI, per garantire che i test di conformità vengano superati nella build GSI+GKI con un dispositivo di riferimento e con Cuttlefish.

Figura 1. Cronologia di rilascio di GKI

Procedura di rigenerazione di emergenza

Un respin si riferisce al processo di unione, ricompilazione, ritest e ricertificazione di un binario dopo una release pubblica del kernel GKI. Puoi richiedere una nuova rotazione di un binario certificato in una delle seguenti circostanze:

• Per aggiornare un elenco di simboli.
• Per applicare una correzione a un bug, inclusi quelli trovati durante l'approvazione del lab 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 per un massimo di 6 mesi dopo il rilascio del ramo. Dopo il termine di 6 mesi, devi richiedere una nuova build per applicare le patch di sicurezza a un ramo.

Linee guida per le richieste di respin

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

• I respins sono consentiti solo sui rami di rilascio dopo il lancio di una versione pubblica iniziale di una build trimestrale.

• Le richieste di respin 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 al respin solo per le patch di sicurezza citate in un Bollettino sulla sicurezza di Android.

• Quando i requisiti LTS, definiti dal Bollettino sulla sicurezza di Android (ASB), rendono il ramo non conforme, questo viene ritirato. Le richieste di respin per i rami ritirati non vengono accettate. La data di ritiro di un determinato ramo di release GKI è inclusa nelle note di build di release GKI trimestrali in Release. Per la pianificazione futura, i requisiti LTS vengono aggiornati a maggio e novembre di ogni anno. Ad esempio, il ramo android12-5.10-2023-07 (5.10.177) non è supportato per i respins 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 respins sono applicabili solo per correzioni di bug urgenti, aggiornamenti dell'elenco dei simboli o per applicare una patch per correggere una funzionalità esistente.

• Tutte le patch che vengono inserite nel ramo di rilascio trimestrale devono essere già unite al ramo di sviluppo principale di GKI. Ad esempio, se è necessaria una patch per una nuova versione di android12-5.10-2022-09, deve essere già unita a android12-5.10.

• Devi selezionare le patch dal ramo di sviluppo principale di GKI e caricarle nel ramo di rilascio trimestrale.

• Nella richiesta di respin, 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, contrassegna la priorità come P0. Per le richieste P0 e P1, devi anche giustificare l'urgenza. La tabella seguente fornisce una mappatura della priorità dei 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 respin separata per ogni ramo di rilascio. Ad esempio, se è necessario un respin sia per android12-5.10-2022-08 sia per android12-5.10-2022-09, devi creare due richieste di respin.

• Dopo che è stata fornita una build e una richiesta di respin è stata contrassegnata come corretta, non devi riaprire la richiesta di respin per aggiungere altre CL. Devi inviare una nuova richiesta di respin 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 di commit per ogni CL.
  • Change-Id: deve essere identico a Change-Id della modifica del ramo di base.

• 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.

Figura 2. Il processo di riassegnazione

Per avviare la procedura di respin:

1. Compila il modulo di richiesta di nuovo spin del GKI e contatta immediatamente il tuo Technical Account Manager Google. Questo modulo crea un bug di richiesta di rigenerazione di GKI. I bug delle richieste di respin sono visibili a te (il richiedente), al team GKI e a persone specifiche che aggiungi all'elenco CC del bug.
   • Se hai già una correzione, la richiesta deve rimandare all'invio della patch in AOSP in modo che Google possa esaminarla. Se l'invio della patch non è fattibile, la patch deve essere allegata alla richiesta come file di testo.
   • 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 di Google GKI esamina la richiesta e la approva o la riassegna a te se sono necessarie ulteriori informazioni.
3. Una volta concordata una correzione, il team Google GKI esegue la revisione del codice (CR+2) della modifica. La revisione inizia il periodo di tempo ESRT. Il team GKI esegue il merge, la build, i test per la regressione e certifica la modifica.
4. Il binario viene rilasciato su ci.android.com. Il periodo di tempo ESRT termina e il team Google GKI contrassegna la richiesta come corretta e fa riferimento alla build di respin. La build di respin verrà pubblicata anche nella pagina delle build di release di Generic Kernel Image (GKI).

Qualifiche GKI

Dove ottenere gli artefatti della build

Gli artefatti per 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 Android.

Domande frequenti

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

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

Sì, questa operazione è nota come respin. La procedura di respin è supportata a condizione che la build GKI rilasciata (su cui viene richiesto il respin) sia conforme ai requisiti LTS nel Bollettino sulla sicurezza di Android (ASB).

È possibile riprodurre i 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 questo 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'artefatto GKI da out/.../dist.

Il binario GKI (inclusa la patch di emergenza) è stato creato sull'ultima base di codice?

No. I respins contengono solo patch che si trovano sopra i kernel certificati trimestrali che sono stati scelti. Questi respins contengono tutte le correzioni dei bug che bloccano il lancio segnalate fino a un determinato momento dagli OEM che utilizzano la release trimestrale di base corrispondente. Vedi il seguente 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 rilevano problemi che richiedono patch per l'assistenza. Queste patch potrebbero essere diverse o uguali.
• Le nuove versioni del binario di novembre 2021 contengono correzioni del blocco dell'avvio segnalate da OEM1 e OEM2 durante la finestra di nuova versione, ma nient'altro.
• I problemi menzionati nel secondo punto elenco sono inclusi anche nelle release trimestrali successive del GKI.

Il respin di ottobre include tutte le patch inviate dagli OEM, ma altre patch OEM ci riguardano perché non sono state testate in modo specifico con i nostri prodotti. È possibile includere solo la nostra patch?

Non è possibile. Un percorso di respin "per OEM" non è scalabile. Il team GKI esamina attentamente ogni singola modifica apportata alle build di respin e le testa con tutto l'hardware disponibile prima di creare una nuova build. Se il team GKI rileva che il problema è specifico di un OEM, di un dispositivo o di un modello, può assicurarsi che il codice aggiunto dalla modifica venga eseguito solo sul dispositivo, sul modello o sullo SKU interessato.

Il vantaggio principale delle rigenerazioni unificate è che tutti i dispositivi che utilizzano la stessa base di rilascio traggono vantaggio l'uno dall'altro, soprattutto se i bug che scoprono sono generici e applicabili a tutti gli utenti. I bug del kernel principale rilevati nei test dell'operatore sono un esempio specifico di questo concetto.

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

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