Questo documento descrive come viene rilasciato GKI, inclusi i rilasci di emergenza settimanali, mensili e fuori banda. L'obiettivo di questo documento è fornire agli OEM linee guida su dove ritirare la GKI nonché il processo per le correzioni di emergenza fuori banda. Gli OEM possono anche utilizzare la guida allo sviluppo di GKI per saperne di più su come collaborare con il team del kernel Android per ottimizzare il kernel GKI per i loro prodotti.
Cadenza di rilascio GKI
GKI viene rilasciato con cadenza mensile dopo il blocco di KMI.
Rilascio GKI Android 13 e 14
La tabella seguente è applicabile solo ad android13-5.10 , android13-5.15 e android14-6.1 .
| Build mensili certificate GKI | Data limite per il check-in | Data di pronto 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 i rilasci mensili di android14-5.15 in conformità con la cadenza mensile specificata nella tabella seguente.
| Build mensili certificate GKI | Data limite per il check-in | Data di pronto 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Ì |
Rilascio GKI di Android 12
Dopo maggio 2023, le versioni GKI android12-5.10 avranno cadenza bimestrale e verranno pubblicate a metà mese. La tabella seguente è applicabile solo ad android12-5.10 .
| Build mensili certificate GKI | Data limite per il check-in | Data di pronto 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Ì |
Validità della build GKI per gli OEM
Gli OEM possono utilizzare un GKI Android rilasciato di recente. Gli OEM possono eseguire il lancio con build certificate GKI purché siano conformi ai requisiti LTS dell'Android Security Bulletin (ASB).
Rilasci di sviluppo settimanali
Le uscite vengono testate con le seppie per garantire che superino un livello minimo di qualità .I file binari GKI sono disponibili per il self-service da ci.android.com man mano che le modifiche vengono unificate. Le build settimanali non saranno certificate, ma potranno essere utilizzate come base per lo sviluppo e il test. Le build settimanali non possono essere utilizzate per build di dispositivi di produzione per gli utenti finali.
Rilasci mensili certificati
Le versioni mensili 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 base di codice sorgente nota.
Ogni mese, un candidato al rilascio mensile GKI (non certificato) viene selezionato dopo la data limite per il check-in, che in genere corrisponde alla seconda build settimanale di quel mese. Dopo aver selezionato la versione candidata per la versione mensile, le nuove modifiche non verranno accettate nella versione di quel mese. Durante il periodo di chiusura, è possibile risolvere solo le correzioni dei bug che causano il fallimento del test. La release candidate è sottoposta al controllo qualità, come descritto nella sezione di qualificazione GKI , per garantire che i test di conformità superino la build GSI+GKI con un dispositivo di riferimento e seppia.
Figura 1. Cronologia del rilascio della GKI
Procedura di respin di emergenza
Un respin si riferisce al processo di ricomposizione, ricostruzione, nuovo test e ricertificazione di un file binario dopo un rilascio pubblico del kernel GKI . Puoi richiedere una nuova rotazione di un file binario certificato per una qualsiasi delle seguenti circostanze:
- Per aggiornare un elenco di simboli.
- Per applicare una correzione a un bug, inclusi i bug rilevati durante l'approvazione del laboratorio del corriere.
- Per aggiungere un hook del fornitore .
- Per applicare una patch a una funzionalità esistente.
- Applicare una patch di sicurezza (dopo 6 mesi).
Le patch di sicurezza vengono automaticamente unite in un ramo di rilascio fino a 6 mesi dopo il rilascio del ramo. Dopo il periodo limite di 6 mesi, è necessario richiedere un nuovo giro per applicare le patch di sicurezza a un ramo.
Prima di richiedere un respin, tieni presenti le seguenti linee guida:
I respin sono consentiti solo sui rami di rilascio dopo il lancio di un rilascio pubblico iniziale di una build mensile .
Le richieste di respin sono accettate solo per un determinato ramo di rilascio per un massimo di sei mesi dopo il rilascio pubblico iniziale. Dopo sei mesi, le filiali possono beneficiare del respin solo per le patch di sicurezza citate in un Bollettino sulla sicurezza Android .
Quando i requisiti LTS definiti dall'Android Security Bulletin (ASB) rendono il ramo non conforme, il ramo viene deprecato. Le richieste di respin per i rami deprecati non sono accettate. La data di deprecazione per un determinato ramo di rilascio GKI è inclusa nelle note mensili sulla build di rilascio GKI in Releases . Per la pianificazione futura, i requisiti LTS vengono aggiornati annualmente a maggio e novembre. Ad esempio, il ramo
android12-5.10-2023-07(5.10.177) non è supportato per i respin dopo il 1 maggio 2024, perché il ramoandroid12-5.10-2023-07(5.10.177) non è conforme ai Requisiti LTS di ASB-2024-05.I Respin sono applicabili solo per correzioni urgenti di bug, aggiornamenti dell'elenco di simboli o per applicare una patch per correggere una funzionalità esistente.
Tutte le patch destinate al ramo di rilascio mensile devono già essere unite al ramo di sviluppo GKI principale. Ad esempio, se è necessaria una patch per un respin di
android12-5.10-2022-09, deve già essere unita adandroid12-5.10.È necessario selezionare le patch dal ramo di sviluppo GKI principale e caricare la patch nel ramo di rilascio mensile.
Nella richiesta di respin è necessario assegnare una priorità (urgenza) alla richiesta. Questa priorità aiuta il team GKI ad assistere meglio i partner in modo tempestivo. Per richieste critiche o urgenti, contrassegnare la priorità come P0 . Per le richieste P0 e P1 è necessario giustificare anche l'urgenza. La tabella seguente fornisce una mappatura della priorità del bug e del tempo necessario alla risoluzione (ESRT):
Priorità ESRT P0 2 giorni lavorativi P1 5 giorni lavorativi P2 10 giorni lavorativi P3 15 giorni lavorativi
È necessario inviare una richiesta di respin separata per ramo di rilascio. Ad esempio, se è necessaria una ripetizione sia per
android12-5.10-2022-08cheandroid12-5.10-2022-09, devi creare due richieste di ripetizione.Dopo che è stata fornita una build e una richiesta di ripetizione è stata contrassegnata come corretta, non è necessario riaprire la richiesta di ripetizione per aggiungere ulteriori CL. È necessario inviare una nuova richiesta di respin se sono presenti patch aggiuntive che devono essere unificate.
Per ogni CL in esame, aggiungi i seguenti tag. L'avanzamento della richiesta di respin è bloccato senza queste informazioni.
-
Bug: l'ID del bug deve essere aggiunto al messaggio di commit per ogni CL. -
Change-Id: deve essere identico al Change-Id della modifica del ramo base.
-
Se una richiesta di ripetizione richiede la tua risposta e tu non rispondi entro tre giorni lavorativi, la priorità viene ridotta di un livello (ad esempio, P0 viene declassato a P1 ). Se non rispondi per due settimane, il bug verrà contrassegnato come Non risolto (Obsoleto) .
Invia una richiesta di ripetizione
Il diagramma seguente mostra il processo di respin. Il processo inizia quando il partner OEM (tu) invia la richiesta di respin.
Figura 2. Il processo di respin
Per accedere al processo di respin:
- Compila il modulo di richiesta GKI Respin . e contatta immediatamente il tuo gestore tecnico dell'account Google. Questo modulo crea un bug di richiesta di respin GKI. I bug delle richieste Respin sono visibili a te (il richiedente), al team GKI e agli individui specifici che aggiungi all'elenco CC del bug.
- Se disponi già di una correzione, la richiesta dovrebbe puntare all'invio della patch in AOSP in modo che Google possa esaminarla. Se l'invio della patch non è fattibile, la patch deve essere allegata come file di testo alla richiesta.
- Se non disponi di una soluzione, la richiesta deve contenere quante più informazioni possibili, inclusi il numero di versione del kernel e i log, in modo che Google possa aiutarti a risolvere il problema.
- Il team GKI di Google esamina la richiesta e la approva o te la riassegna se sono necessarie ulteriori informazioni.
- Dopo aver concordato una correzione, il codice del team GKI di Google esamina (CR+2) la modifica. La revisione inizia il periodo di tempo dell'ESRT. Il team GKI unisce, crea, testa la regressione e certifica la modifica.
- Il binario viene rilasciato su ci.android.com . Il periodo di tempo ESRT termina e il team GKI di Google contrassegna la richiesta come fissa e fa riferimento alla build di respin. La build di respin verrà pubblicata anche sulla pagina delle build di rilascio dell'immagine generica del kernel (GKI) .
Qualifiche GKI
| Tipi di build GKI | Applicazione della qualità | Appunti |
|---|---|---|
| settimanalmente | Prova della seppia
|
|
| Mensile (certificato) | Prova della seppia
| |
| Respin (certificati) | Prova della seppia
|
|
Dove ottenere artefatti di costruzione
Gli artefatti per tutte le versioni possono essere ottenuti da ci.android.com .
Puoi trovare ulteriori informazioni sull'elemento della configurazione, inclusi i risultati dei test, nel dashboard di integrazione continua Android .
Domande frequenti
È possibile creare un nuovo binario GKI basato su un GKI già rilasciato?
Sì, questo è noto come respin. Il processo di ripetizione è supportato purché la build GKI rilasciata (sulla quale è richiesta la ripetizione) sia conforme ai requisiti LTS nell'Android Security Bulletin (ASB).
È possibile riprodurre i binari GKI?
Sì, fai riferimento all'esempio seguente.
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/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 binario GKI (inclusa la patch spin di emergenza) è stato creato sulla base di codice più recente?
No. I Respin contengono solo patch che si aggiungono ai kernel certificati mensili scelti. Questi respin contengono tutte le correzioni di bug che bloccano il lancio segnalate fino a un dato momento dagli OEM utilizzando la corrispondente versione mensile di base. Vedere l'esempio seguente di come si verifica questo tipo di scenario.
- OEM1 e OEM2 decidono di utilizzare la versione binaria GKI a partire da novembre 2021.
- OEM1 e OEM2 rilevano problemi che richiedono patch per il supporto. Queste patch potrebbero essere diverse o potrebbero essere le stesse.
- I respin sopra il binario di novembre 2021 presentano correzioni di blocco del lancio segnalate sia da OEM1 che da OEM2 durante la finestra di respin, ma niente di più.
- I problemi menzionati nel secondo punto sono inclusi anche nelle successive versioni mensili di GKI.
Il respin di ottobre contiene tutte le patch inviate dagli OEM, ma le altre patch OEM ci riguardano perché non sono state testate specificatamente con i nostri prodotti. È possibile includere solo la nostra patch?
Non è possibile. Un percorso di ripetizione "per OEM" non è attualmente scalabile. Invece, 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 il team GKI rileva che il problema è specifico per un OEM/dispositivo/modello, 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 rilascio beneficia l'uno dell'altro, soprattutto se i bug scoperti sono generici e applicabili a tutti gli utenti. I bug principali del kernel rilevati nei test dei carrier sono un esempio specifico di questo concetto.
Esistono situazioni in cui Google fornisce informazioni specifiche sulle patch OEM e sugli scenari dei 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é non verrà compreso il problema e non saranno stati raccolti tutti i dettagli. Questo è visibile nel registro delle modifiche (messaggio di commit). Google non rivela quale dispositivo specifico sia interessato, ma gli OEM possono sempre trovare la descrizione del problema e la soluzione nel registro delle modifiche.