Processo di rilascio GKI (Generic Kernel Image)

Questa pagina descrive come viene rilasciato GKI, incluse le release trimestrali e di emergenza fuori banda. L'obiettivo di questa pagina è fornire agli OEM una linea guida su dove recuperare il GKI, nonché la procedura per le correzioni di emergenza fuori banda. 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 il lancio con build con certificazione GKI a condizione che siano conformi ai requisiti del kernel con supporto a lungo termine (LTS) nel Bollettino sulla sicurezza di Android (ASB).

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, dopo la data limite di check-in, viene selezionata una release candidata trimestrale del GKI (non certificata). Una volta selezionata la release candidate trimestrale, le nuove modifiche non verranno accettate nella release del mese. Durante il periodo di chiusura della finestra, possono essere risolte solo le correzioni dei bug che causano l'esito negativo del test. La release candidata viene sottoposta al controllo qualità, come descritto nella sezione Qualifica GKI, per verificare che i test di conformità vengano superati su una build GSI+GKI con un dispositivo di riferimento e Cuttlefish.

Figura 1. Cronologia di rilascio di GKI

Qualifiche GKI

Dove ottenere gli artefatti della build

Gli OEM possono ottenere gli artefatti per tutte le release 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. Il processo di respin è supportato 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 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 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 le 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 potrebbero essere diverse o uguali.
• I respins aggiuntivi rispetto al binario di novembre 2021 includono correzioni che bloccano l'avvio segnalate sia da OEM1 che da OEM2 durante la finestra di respins, ma nient'altro.
• I problemi menzionati nel secondo punto elenco sono inclusi anche nelle release trimestrali successive di 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 singoli OEM non è scalabile. Il team GKI esamina attentamente ogni singola modifica che viene inserita nelle 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, un dispositivo o un modello, il team GKI può verificare che il codice aggiunto dalla modifica venga eseguito solo sul dispositivo, sul modello o sullo SKU interessato.

Il vantaggio principale dei respins unificati è 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 di base trovati nei test degli operatori sono un esempio specifico di questo concetto.

Esistono situazioni in cui Google fornisce informazioni specifiche su patch OEM e scenari di problemi, in modo che gli OEM possano valutare l'impatto e il rischio di implementare le patch con i loro prodotti?

Google non aggiungerà mai una modifica a una build di respin finché il team GKI non avrà compreso il problema e raccolto tutti i dettagli. Puoi visualizzarlo 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 changelog.