Processo di rilascio GKI (Generic Kernel Image)

Questa pagina descrive come viene rilasciata la GKI, inclusi i rilasci di emergenza trimestrali e fuori banda. L'obiettivo di questa pagina è fornire agli OEM una linea guida su dove trovare il GKI, nonché sulla 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 propri prodotti.

Frequenza di rilascio della GKI

La GKI viene rilasciata con cadenza trimestrale dopo il blocco del KMI.

Validità della build GKI per gli OEM

Gli OEM possono utilizzare una GKI Android rilasciata di recente. Gli OEM possono lanciare build certificate GKI, purché siano conformi ai requisiti del kernel con assistenza a lungo termine (LTS) nel Bollettino sulla sicurezza di Android (ASB).

Release GKI a 16 kB

Il team di rilascio della GKI gestisce le release della GKI da 16 KB utilizzando la stessa cadenza di rilascio trimestrale, gli stessi test di qualificazione e lo stesso processo di respin delle release della GKI da 4 KB:

• Rami supportati:
  • android15-6.6 (a partire da gennaio 2026)
  • android16-6.12 (a partire da marzo 2026)
  • android17-6.18 (a partire da giugno 2026)
• Parità di build e certificazione:i file binari GKI da 16 KB utilizzano lo stesso tag di origine e lo stesso ID build del kernel della release GKI da 4 KB corrispondente. Fino al 2027, la scheda Build di release da 16 KB nelle pagine delle build di release android15-6.6, android16-6.12 e android17-6.18 fornisce file binari di release GKI da 16 KB non certificati. Non è necessario aggiornare i kernel da 4 kB e 16 kB contemporaneamente, anche se ti consigliamo di farlo.
• Respin on demand:richiedi i respin GKI da 16 kB utilizzando lo stesso modulo e la stessa procedura di richiesta di respin delle build da 4 kB.

Release 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 di codice sorgente nota.

Ogni trimestre, dopo la data limite di check-in, viene selezionato un candidato per la release trimestrale del GKI (non certificato). Una volta selezionato il candidato per la release trimestrale, non verranno accettate nuove modifiche nella release di quel mese. Durante il periodo di chiusura, possono essere apportate solo correzioni per i bug che causano errori dei test. Il candidato per la release viene sottoposto alla garanzia di 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 delle release di GKI

Qualifiche GKI

Dove ottenere gli artefatti di 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 Integrazione continua di Android.

Domande frequenti

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

È possibile creare un nuovo file 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 del 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'artefatto GKI da out/.../dist.

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

No. Le nuove versioni contengono solo le patch che si trovano sopra i kernel certificati trimestralmente che sono stati scelti. Queste nuove versioni 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.
• Le nuove versioni basate sul file binario di novembre 2021 contengono correzioni di blocco del lancio segnalate sia da OEM1 che da OEM2 durante la finestra di nuova versione, ma niente di più.
• I problemi menzionati nel secondo punto sono inclusi anche nelle successive release trimestrali di GKI.

La nuova versione di ottobre contiene tutte le patch inviate dagli OEM, ma altre patch degli OEM ci riguardano perché non sono state testate specificamente con i nostri prodotti. È possibile includere solo la nostra patch?

Non è possibile. Un percorso di rigenerazione per i singoli 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, un dispositivo o un modello, può verificare che il codice aggiunto dalla modifica venga eseguito solo sul dispositivo, sul modello o sullo SKU interessato.

Il vantaggio principale delle nuove versioni unificate è che ogni dispositivo che utilizza la stessa base di release trae vantaggio dagli altri, soprattutto se i bug rilevati sono generici e applicabili a tutti gli utenti. I bug del kernel di base rilevati durante i test degli operatori 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 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 vederlo 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.