Questo documento descrive le modalità di rilascio di GKI, inclusi settimanalmente, mensilmente e in uscita release di emergenza del cinturino. L'obiettivo di questo documento è offrire agli OEM una linee guida su dove ritirare la GKI e sul processo per fuori banda correzioni di emergenza. Gli OEM possono anche utilizzare la guida allo sviluppo GKI per saperne di più su come possono collaborare con il team Android Kernel per l'ottimizzazione del 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à alla 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 eseguite con una cadenza trimestrale e
pubblicati 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 certificate GKI, purché siano conformi ai requisiti LTS del Bollettino sulla sicurezza di Android (ASB).
Release di sviluppo settimanali
Le uscite vengono testate con seppie per assicurarsi di superare un livello di qualità minima.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 usate come una base per lo sviluppo e il test. Non è possibile usare build settimanali per le build di dispositivi di produzione per gli utenti finali.
Release certificate mensili
Le release mensili di GKI contengono un boot.img testato che include un
inserito un certificato per attestare che i file binari sono stati creati da un'origine nota
base del codice.
Ogni mese, viene selezionato un candidato per la release mensile GKI (non certificato) dopo la data limite per il check-in, che solitamente corrisponde alla seconda build settimanale di quel mese. Dopo aver selezionato la release mensile candidata, nuova modifiche non saranno accettate nella release di quel mese. Durante la finestra chiusa è possibile risolvere solo i bug che causano errori dei test. La il candidato della release viene sottoposto ai controlli di qualità, come descritto in GKI qualifica, per garantire che i test di conformità vengano superati 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 ripristino, ricreare, ripetere il test la ricertificazione di un file binario una release pubblica del kernel GKI. Puoi richiedere la ripetizione della rotazione di un programma binario certificato per uno dei seguenti documenti: 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, è necessario richiedere un respin per applicare patch di sicurezza a un ramo.
Linee guida per le richieste di ripetizione
Prima di richiedere un nuovo movimento, tieni presente le seguenti linee guida:
I respin sono consentiti solo nei rami di release dopo una release pubblica iniziale di una build mensile è stato avviato.
Le richieste di Respin sono accettate solo per un determinato ramo di release per un per un massimo di sei mesi dopo la pubblicazione iniziale. Dopo sei mesi, le filiali sono idonee al respin solo per le patch di sicurezza citate in un Bollettino sulla sicurezza di Android.
Quando i requisiti LTS , definita dal Bollettino sulla sicurezza di Android (ASB) perché il ramo non è conforme, viene deprecato. Richieste di ripetizione per i rami deprecati non sono accettati. La data di ritiro di un determinato GKI è incluso nelle note mensili sulla build di GKI nella sezione Release. Per la pianificazione futura, i requisiti LTS vengono aggiornati a maggio e novembre all'anno. Ad esempio, la proprietà
android12-5.10-2023-07Ramo (5.10.177) non è supportato per i respin dopo il 1° maggio 2024, perchéandroid12-5.10-2023-07: ramo (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 e correggere una funzionalità esistente.
Tutte le patch inserite nel ramo di release mensile devono essere già unite ramo principale dello sviluppo GKI. Ad esempio, se è necessaria una patch per un respin di
android12-5.10-2022-09, deve essere già unitaandroid12-5.10.Devi scegliere le patch dal ramo di sviluppo GKI principale caricare la patch 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 P0 e P1 necessarie, devi anche giustificare l'urgenza. La seguente tabella 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 ramo di release. Ad esempio, se è necessario il respin sia per
android12-5.10-2022-08cheandroid12-5.10-2022-09, devi creare due richieste respin.Dopo aver fornito una build e aver contrassegnato una richiesta respin come corretta, non è necessario riaprire la richiesta di respin per aggiungere altri CL. Devi inviare un nuovo respin se sono presenti patch aggiuntive che devono essere unite.
Per ogni CL da considerare, aggiungi i seguenti tag.
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, viene eseguito il downgrade della priorità di un livello (ad esempio P0 viene retrocesso a P1). Se non rispondi per due settimane, il bug è contrassegnato come Non risolvibile (obsoleto).
Inviare una richiesta di respin
Il seguente diagramma mostra la procedura di respin. Il processo 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 della richiesta respin GKI. I bug delle richieste di Respin ti sono visibili
(il richiedente), il team GKI e le persone specifiche che aggiungi
l'elenco Cc del bug.
- Se hai già una correzione, la richiesta deve indirizzare alla patch inviato in AOSP per consentire a Google di esaminarlo. Se l'invio della patch non la patch deve essere allegata alla richiesta come file di testo.
- Se non hai una correzione, la richiesta deve contenere informazioni, tra cui il numero di versione del kernel e i log, quindi Google può aiutarti a eseguire il debug del problema.
- Il team GKI di Google esamina la richiesta e la approva o la assegna nuovamente se sono necessarie ulteriori informazioni.
- Una volta concordata una correzione, il team GKI di Google esamina il codice (CR+2) modifica. La revisione inizia il periodo di tempo ESRT. Il team GKI unisce, crea e testa per la regressione e certifica la modifica.
- Il file binario viene rilasciato ci.android.com. La Il periodo di tempo ESRT termina e il team GKI di Google contrassegna la richiesta come corretta e fare riferimento alla build respin. La build respin viene inoltre pubblicata Pagina delle build della release GKI (Generic Kernel Image).
Qualifiche GKI
| Tipi di build GKI | Applicazione della qualità | Notes |
|---|---|---|
| Settimanale | Test delle seppie
|
|
| Mensile (con certificazione) | Test delle seppie
|
|
| Respins (certificati) | Test delle seppie
|
|
Dove trovare gli artefatti della build
Gli artefatti per tutte le release possono essere ottenuti ci.android.com.
Puoi trovare maggiori informazioni su CI, tra cui il test risultati relativi all'integrazione continua di Android Fitbit.com.
Domande frequenti
È possibile creare un nuovo programma binario GKI basato su una GKI già rilasciata?
Sì, è un respin. Il processo respin è supportato purché build GKI rilasciata (per la quale è richiesto il respin) è conforme a LTS nel Bollettino sulla sicurezza di 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 aggiungono alle patch certificate mensili che hai scelto. Questi respin contengono tutti i bug di blocco del lancio correzioni segnalate fino a un determinato momento dagli OEM utilizzando il modello di base con il rilascio mensile. 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 potrebbero essere diversi o potrebbero essere uguali.
- I respin sopra il programma binario di novembre 2021 hanno un blocco dell'avvio. correzioni segnalate sia da OEM1 che da OEM2 durante la finestra di respin, ma nulla altro ancora.
- I problemi menzionati nel secondo punto dell'elenco sono inclusi anche nella GKI successiva di uscite mensili.
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 modello "per OEM" Il percorso respin al momento non è scalabile. Il team GKI invece esamina ogni singola modifica apportata al respin e testa le modifiche con tutto l'hardware disponibile prima di creare creare. Se il team GKI rileva che il problema riguarda specificamente un OEM/dispositivo/modello, il team GKI può assicurarsi che il codice aggiunto dalla modifica venga eseguito dispositivo/modello/SKU interessato.
Il vantaggio principale dei respin unificati è che ogni dispositivo usando la stessa base di release si traggono vantaggio l'uno dall'altro, soprattutto se i bug che sono generici e applicabili a tutti gli utenti. Rilevati bug core del kernel dei test con gli operatori è 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 che sono stati raccolti tutti i dettagli. come indicato 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.