Processo di rilascio GKI (Generic Kernel Image)

Questa pagina descrive come viene rilasciato GKI, incluse le release settimanali, trimestrali e di emergenza fuori banda. Lo scopo 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 della 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 con certificazione GKI, a condizione che siano conformi ai requisiti LTS nel Bollettino sulla sicurezza di Android (ASB).

Uscite certificate trimestrali

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 a partire da una baseline del codice sorgente nota.

Ogni trimestre, viene selezionata una release candidate trimestrale della GKI (non certificata) dopo la data di chiusura del 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 della finestra chiusa, possono essere risolte solo le correzioni dei bug che causano l'esito negativo del test. La release candidate viene sottoposta al controllo 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

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 Android Continuous Integration.

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 del 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 sulla base di codice più recente?

No. I respins contengono solo patch che si trovano sopra i kernel certificati trimestrali che sono stati scelti. Questi respins contengono tutte le correzioni di 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 possono essere diverse o uguali.
• I respins sopra il binario di novembre 2021 hanno correzioni del blocco dell'avvio segnalate sia da OEM1 che da OEM2 durante la finestra di respin, 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 interessano perché non sono state testate specificamente con i nostri prodotti. È possibile includere solo la nostra patch?

Non è possibile. Un percorso di ricompilazione "per OEM" non è scalabile. Il team GKI esamina attentamente ogni singola modifica apportata alle build di respin e testa le modifiche 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 ricompilazioni 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.