Questo documento descrive le modalità di rilascio di GKI, incluse le release di emergenza settimanali, mensili e fuori banda. L'obiettivo di questo documento è fornire agli OEM delle linee guida su dove ritirare la GKI e sulla procedura per le correzioni di emergenza fuori banda. Gli OEM possono anche utilizzare la guida allo sviluppo GKI per saperne di più su come possono collaborare con il team del kernel Android per ottimizzare il kernel GKI per i loro prodotti.
Cadenza di rilascio GKI
GKI viene rilasciato ogni mese dopo il blocco del KMI.
Release di Android 13, 14 e 15 GKI
La tabella seguente è applicabile solo a android13-5.10, android13-5.15 e android14-6.1.
| Build certificate mensili GKI | Data limite per il check-in | Data di completamento del precaricamento GKI | Confermato? |
|---|---|---|---|
| Ottobre | 14 ottobre 2022 | 31 ottobre 2022 | Sì |
| Novembre | 14 novembre 2022 | 30 novembre 2022 | Sì |
| Dicembre | 9 dicembre 2022 | 21 dicembre 2022 | Sì |
| Gennaio | 17 gennaio 2023 | 31 gennaio 2023 | Sì |
| Febbraio | 15 febbraio 2023 | 28 febbraio 2023 | Sì |
| Marzo | 15 marzo 2023 | 31 marzo 2023 | Sì |
| Aprile | 13 aprile 2023 | 28 aprile 2023 | Sì |
| Maggio | 17 maggio 2023 | 31 maggio 2023 | Sì |
| Giugno | 15 giugno 2023 | 30 giugno 2023 | Sì |
| Luglio | 18 luglio 2023 | 31 luglio 2023 | Sì |
| Agosto | 16 agosto 2023 | 31 agosto 2023 | Sì |
| Settembre | 14 settembre 2023 | 29 settembre 2023 | Sì |
| Ottobre | 18 ottobre 2023 | 31 ottobre 2023 | Sì |
| Novembre | 10 novembre 2023 | 30 novembre 2023 | Sì |
| Dicembre | 7 dicembre 2023 | 22 dicembre 2023 | Sì |
| Gennaio | 16 gennaio 2024 | 31 gennaio 2024 | Sì |
| Febbraio | 13 febbraio 2024 | 29 febbraio 2024 | Sì |
| Marzo | 13 marzo 2024 | 29 marzo 2024 | Sì |
| Aprile | 16 aprile 2024 | 30 aprile 2024 | Sì |
| Maggio | 14 maggio 2024 | 31 maggio 2024 | Sì |
| Giugno | 12 giugno 2024 | 28 giugno 2024 | Sì |
| Luglio | 16 luglio 2024 | 31 luglio 2024 | Sì |
| Agosto | 15 agosto 2024 | 30 agosto 2024 | Sì |
| Settembre | 17 settembre 2024 | 30 settembre 2024 | Sì |
| Ottobre | 15 ottobre 2024 | 31 ottobre 2024 | Sì |
| Novembre | 11 novembre 2024 | 27 novembre 2024 | Sì |
| Dicembre | 6 dicembre 2024 | 23 dicembre 2024 | Sì |
A partire da gennaio 2024, riprenderemo le release mensili di android14-5.15
in conformità con la cadenza mensile specificata nella tabella di seguito.
android15-6.6 seguirà la stessa cadenza di rilascio, a partire da luglio 2024.
| Build certificate mensili GKI | Data limite per il check-in | Data di completamento del precaricamento GKI | Confermato? |
|---|---|---|---|
| Gennaio | 16 gennaio 2024 | 31 gennaio 2024 | Sì |
| Febbraio | 13 febbraio 2024 | 29 febbraio 2024 | Sì |
| Marzo | 4 marzo 2024 | 15 marzo 2024 | Sì |
| Aprile | 1° aprile 2024 | 17 aprile 2024 | Sì |
| Maggio | 1° maggio 2024 | 17 maggio 2024 | Sì |
| Giugno | 3 giugno 2024 | 17 giugno 2024 | Sì |
| Luglio | 1 luglio 2024 | 15 luglio 2024 | Sì |
| Agosto | 1° agosto 2024 | 16 agosto 2024 | Sì |
| Settembre | 2 settembre 2024 | 16 settembre 2024 | Sì |
| Ottobre | 1° ottobre 2024 | 14 ottobre 2024 | Sì |
| Novembre | 1° novembre 2024 | 15 novembre 2024 | Sì |
| Dicembre | 2 dicembre 2024 | 16 dicembre 2024 | Sì |
Release GKI di Android 12
Dopo maggio 2024, le release di GKI android12-5.10 vengono pubblicate con una cadenza trimestrale e
vengono pubblicate a metà mese.
La seguente tabella è applicabile solo a android12-5.10.
| Build certificate mensili GKI | Data limite per il check-in | Data di completamento del precaricamento GKI | Confermato? |
|---|---|---|---|
| Luglio | 3 luglio 2023 | 14 luglio 2023 | Sì |
| Settembre | 1° settembre 2023 | 15 settembre 2023 | Sì |
| Novembre | 3 novembre 2023 | 17 Novembre 2023 | Sì |
| Gennaio | 5 gennaio 2024 | 19 gennaio 2024 | Sì |
| Marzo | 4 marzo 2024 | 15 marzo 2024 | Sì |
| Maggio | 1° maggio 2024 | 17 maggio 2024 | Sì |
| Agosto | 1° agosto 2024 | 16 agosto 2024 | Sì |
| Novembre | 1° novembre 2024 | 15 novembre 2024 | Sì |
| Febbraio | 3 febbraio 2025 | 17 febbraio 2025 | Sì |
Validità della build GKI per gli OEM
Gli OEM possono utilizzare una GKI di Android rilasciata di recente. Gli OEM possono lanciare build con certificazione GKI purché siano conformi ai requisiti LTS nel Bollettino sulla sicurezza di Android (ASB).
Release di sviluppo settimanali
Le uscite vengono testate con seppie per verificare che superino un livello di qualità minimo.I file binari GKI sono disponibili per il self-service su ci.android.com man mano che le modifiche vengono unite. Le build settimanali non saranno certificate, ma possono essere utilizzate come base per sviluppo e test. Le build settimanali non possono essere usate per le build di dispositivi di produzione per gli utenti finali.
Release certificate mensili
Le release mensili di GKI contengono un elemento boot.img testato che include un certificato inserito da Google per attestare che i file binari sono stati creati da una base di codice sorgente nota.
Ogni mese, viene selezionato un candidato per la release mensile GKI (non certificato) dopo la data limite per il check-in, che in genere corrisponde alla seconda build settimanale del mese. Una volta selezionato il candidato per la release mensile, non saranno accettate nuove modifiche per l'uscita di quel mese. Durante il periodo di chiusura, è possibile risolvere solo le correzioni dei bug che causano errori di test. La candidata alla release viene sottoposta a controlli di qualità, come descritto nella sezione di idoneità GKI, per garantire che i test di conformità superino la build GSI+GKI con un dispositivo di riferimento e seppie.
Figura 1. Cronologia di rilascio GKI
Procedura di Respin di emergenza
Un respin è il processo di recupero, ricreazione, test e ricertificazione di un programma binario dopo una release pubblica del kernel GKI. Puoi richiedere il respin di un programma binario certificato per una delle seguenti circostanze:
- Per aggiornare un elenco di simboli.
- Per applicare una correzione a un bug, inclusi quelli rilevati durante l'approvazione del lab dell'operatore.
- Aggiungere un gancio 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 in un ramo di release per un massimo di 6 mesi dopo il rilascio del ramo. Dopo il limite di 6 mesi, devi richiedere il respin per applicare le patch di sicurezza a un ramo.
Prima di richiedere un nuovo movimento, tieni presente le seguenti linee guida:
I respin sono consentiti solo nei rami di release dopo il lancio di una release pubblica iniziale di una build mensile.
Le richieste di Respin vengono accettate solo per un determinato ramo di release per un massimo di sei mesi dopo la release pubblica iniziale. Dopo sei mesi, i rami possono ricevere il respin solo per le patch di sicurezza citate nel Bollettino sulla sicurezza di Android.
Quando i requisiti LTS, definiti dal Bollettino sulla sicurezza Android (ASB), causano la non conformità del ramo, questo viene deprecato. Le richieste di ripetizione per i rami deprecati non sono accettate. La data di ritiro per un determinato ramo di release GKI è inclusa nelle note mensili sulla build della release GKI in Release. Per la pianificazione futura, i requisiti LTS vengono aggiornati con cadenza annuale a maggio e novembre. Ad esempio, la filiale
android12-5.10-2023-07(5.10.177) non è supportata per i respin dopo il 1° maggio 2024 perché la filialeandroid12-5.10-2023-07(5.10.177) non è conforme ai requisiti LTS di ASB-2024-05.I respin sono validi solo per correzioni di bug urgenti, aggiornamenti dell'elenco di simboli o per applicare una patch per correggere una funzionalità esistente.
Tutte le patch inserite nel ramo di rilascio mensile devono essere già unite nel ramo di sviluppo GKI principale. Ad esempio, se è necessaria una patch per un respin di
android12-5.10-2022-09, deve essere già unita inandroid12-5.10.Devi scegliere le patch dal ramo di sviluppo GKI principale e caricarle nel ramo di rilascio mensile.
Nella richiesta di respin, devi assegnare una priorità (urgenza) alla richiesta. Questa priorità consente al team GKI di 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 Due giorni lavorativi P1 5 giorni lavorativi P2 10 giorni lavorativi P3 15 giorni lavorativi
Devi inviare una richiesta di respin separata per ramo di release. Ad esempio, se è necessario un respin sia per
android12-5.10-2022-08che perandroid12-5.10-2022-09, devi creare due richieste respin.Dopo che hai fornito una build e una richiesta respin viene contrassegnata come corretta, non devi riaprire la richiesta respin per aggiungere altre CL. Devi inviare una nuova richiesta respin se devi unire altre patch.
Per ogni CL da considerare, aggiungi i seguenti tag. L'avanzamento della richiesta di respin viene bloccato senza queste informazioni.
Bug: l'ID bug deve essere aggiunto al messaggio di commit per ogni CL.Change-Id: deve essere identico al Change-Id della modifica del ramo di base.
Se una richiesta di respin richiede la tua risposta e non rispondi entro tre giorni lavorativi, la priorità viene ridotta di un livello (ad esempio, P0 viene ridotto a P1). Se non rispondi entro due settimane, il bug verrà contrassegnato come Non risolvibile (obsoleto).
Inviare una richiesta di respin
Il seguente diagramma mostra la procedura di respin. La procedura inizia quando il partner OEM (tu) invia la richiesta di respin.
Figura 2. La procedura di respin
Per avviare la procedura di respin:
- Compila il modulo di richiesta GKI Respin e contatta immediatamente il tuo Technical Account Manager Google. Questo modulo crea un bug relativo alla richiesta di respin GKI. I bug delle richieste Respin sono visibili a te
(il richiedente), al team GKI e alle persone specifiche che aggiungi all'elenco
Cc del bug.
- Se hai già una correzione, la richiesta deve indirizzare all'invio della patch in AOSP, in modo che Google possa esaminarla. Se non è possibile inviare una patch, quest'ultima deve essere allegata alla richiesta come file di testo.
- Se non hai una correzione, la richiesta deve contenere quante più informazioni possibile, tra cui il numero di versione del kernel e i log, in modo che Google possa aiutarti a eseguire il debug del problema.
- Il team GKI di Google esamina la richiesta e la approva o te la assegna se sono necessarie ulteriori informazioni.
- Una volta concordata una correzione, il team GKI di Google esamina il codice (CR+2) della modifica. La revisione inizia il periodo di tempo ESRT. Il team GKI unisce, crea, testa la regressione e certifica la modifica.
- Il programma binario viene rilasciato su ci.android.com. Il periodo di tempo ESRT termina e il team GKI di Google contrassegna la richiesta come corretta e fa riferimento alla build respin. La build respin viene pubblicata anche nella pagina delle build di release del kernel generico (GKI).
Qualifiche GKI
| Tipi di build GKI | Applicazione della qualità | Notes |
|---|---|---|
| Ogni settimana | Test delle seppie
|
|
| Mensile (con certificazione) | Test delle seppie
|
|
| Respins (certificati) | Test delle seppie
|
|
Dove trovare gli artefatti della build
Gli artefatti di tutte le release possono essere ottenuti su ci.android.com.
Puoi trovare ulteriori informazioni sull'integrazione continua, inclusi i risultati dei test, nella dashboard Integrazione continua di Android.
Domande frequenti
È possibile creare un nuovo programma binario GKI basato su una GKI già rilasciata?
Sì, è un respin. Il processo di respin è supportato purché la build GKI rilasciata (per la quale è richiesto il respin) sia conforme ai requisiti LTS nel Bollettino sulla sicurezza Android (ASB).
È possibile riprodurre binari GKI?
Sì, fai riferimento all'esempio riportato di seguito.
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/manifestmv manifest_7364300.xml .repo/manifestsrepo init -m manifest_7364300.xml --depth=1repo sync # build the GKI images # You may want to use LTO=thin to build faster for developmentBUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh # (optional) build virtual platform modulesBUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh
Puoi recuperare la copia dell'artefatto GKI da out/.../dist.
Il programma binario GKI (compresa la patch di rotazione di emergenza) è stato costruito sul codebase più recente?
No. I Respin contengono solo patch che si trovano sopra i kernel certificati mensili che sono stati scelti. Questi respin contengono tutte le correzioni di bug di blocco del lancio segnalate fino a un determinato momento dagli OEM utilizzando la corrispondente release mensile di base. Guarda l'esempio che segue di come accade questo tipo di scenario.
- OEM1 e OEM2 decidono di utilizzare la release binaria GKI a partire da novembre 2021.
- OEM1 e OEM2 rilevano problemi che richiedono patch per l'assistenza. Queste patch possono essere diverse o uguali.
- I respin sopra il programma binario di novembre 2021 presentano correzioni relative al blocco dell'avvio segnalate sia da OEM1 che da OEM2 durante la finestra di reso, ma niente di più.
- I problemi menzionati nel secondo punto dell'elenco sono inclusi anche nelle successive release mensili di GKI.
Per il respin di ottobre sono incluse tutte le patch inviate dagli OEM, ma sono interessate da altre patch OEM, poiché non sono state testate in modo specifico con i nostri prodotti. È possibile includere solo la nostra patch?
Ciò non è possibile. Un percorso respin "per OEM" al momento non è scalabile. Al contrario, il team GKI esamina ogni singola modifica apportata alle build di respin e testa le modifiche con tutto l'hardware disponibile prima di creare una nuova build. Se rileva che il problema riguarda in modo specifico un OEM/dispositivo/modello, il team GKI può garantire che il codice aggiunto dalla modifica venga eseguito solo sul dispositivo/modello/SKU interessato.
Il vantaggio principale dei respin unificati è che ogni dispositivo che utilizza la stessa base di release si trae vantaggio l'uno dall'altro, soprattutto se i bug rilevati sono generici e applicabili a tutti gli utenti. I bug core del kernel trovati nei test degli operatori sono un esempio specifico di questo concetto.
Ci sono situazioni in cui Google fornisce informazioni specifiche sulle patch degli 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 aggiunge alcuna modifica a una build di respin finché il problema non viene compreso e non sono stati raccolti tutti i dettagli. come vedi nel log delle modifiche (messaggio di commit). Google non rivela quale dispositivo specifico è interessato, ma gli OEM possono sempre trovare la descrizione del problema e la soluzione nel log delle modifiche.