I kernel comuni AOSP (noti anche come kernel comuni Android o ACK ) sono a valle dei kernel kernel.org e includono patch di interesse per la comunità Android che non sono state unite nei kernel mainline o Long Term Supported (LTS). Queste patch possono includere:
- Backport e cherry-pick delle funzionalità upstream necessarie per le funzionalità Android
- Funzionalità pronte per i dispositivi Android ma ancora in fase di sviluppo a monte (ad esempio, ottimizzazioni del posizionamento delle attività di Energy Aware Scheduler).
- Funzionalità del fornitore/OEM utili per altri partner dell'ecosistema (ad esempio, sdcardfs).
android-mainline è il ramo di sviluppo principale per le funzionalità Android. La linea principale di Linux viene unita alla android-mainline ogni volta che Linus Torvalds pubblica una release o una release candidate. Prima del 2019, i kernel comuni di Android venivano costruiti clonando il kernel LTS recentemente dichiarato e aggiungendo le patch specifiche di Android. Questo processo è cambiato nel 2019 per diramare il nuovo kernel comune di Android da android-mainline . Questo nuovo modello evita il notevole sforzo di inoltrare il port e testare le patch Android ottenendo lo stesso risultato in modo incrementale. android-mainline è sottoposto a significativi test continui, questo modello garantisce un kernel di alta qualità dal giorno in cui è stato pubblicato.
Quando un nuovo LTS viene dichiarato a monte, il kernel comune corrispondente viene ramificato da android-mainline . Ciò consente ai partner di iniziare un progetto prima della dichiarazione della versione LTS, unendosi da android-mainline . Dopo la creazione del nuovo ramo del kernel comune, i partner possono modificare senza problemi l'origine di unione nel nuovo ramo.
Altri rami del kernel comuni ricevono fusioni regolari dal kernel LTS associato. Queste unioni vengono normalmente eseguite immediatamente dopo la pubblicazione della versione LTS. Ad esempio, quando è stato pubblicato Linux 4.19.64, è stato unito ai kernel comuni 4.19 (ad esempio, android-4.19-q ). I partner sono fortemente incoraggiati a unire regolarmente i kernel comuni ai kernel dei loro prodotti per rimanere aggiornati con LTS e correzioni di bug specifiche per Android.
Ramo del kernel ACK KMI
I kernel GKI hanno un'interfaccia del modulo kernel stabile. Il KMI è identificato in modo univoco dalla versione del kernel e dalla versione della piattaforma Android, quindi i rami sono denominati <androidRelease>-<kernel version> . Ad esempio, il kernel GKI 5.4 per Android 11 è denominato android11-5.4. Per Android 12 sono disponibili due kernel GKI aggiuntivi, android12-5.4 e android12-5.10 .
Rami di kernel di dessert legacy
I kernel dessert legacy sono stati creati per garantire che lo sviluppo di nuove funzionalità non interferisse con l'unione dal kernel comune di Android. I rami sono stati creati prima del rilascio del dessert associato e ricevono fusioni regolari da LTS, ma nessuna nuova funzionalità. Ad esempio, android-4.9-q riceve unioni dal ramo LTS 4.9.y.
Se una versione del kernel non era un kernel di lancio, non è stato creato alcun kernel dessert, ma il kernel associato alla versione della piattaforma più recente è valido per l'aggiornamento alle versioni future della piattaforma Android. Ad esempio, android-4.9-q era l'ultimo dei rami dessert di android-4.9* , quindi è supportato e testato con la sua versione originale della piattaforma, Android 10. È anche supportato e testato con le versioni della piattaforma che supportano gli aggiornamenti dei dispositivi che eseguono 4.9 kernel: Android 11 e Android 12.
Poiché lo schema di denominazione dei dessert per le versioni della piattaforma Android è stato abbandonato con Android 10, le ultime versioni dei dessert che sarebbero state chiamate android-4.14-r e android-4.19-r sono state invece chiamate android-4.14-stable e android-4.19-stable .
I kernel per dessert sono sostituiti dai kernel GKI a partire da Android 11, quindi l'elenco completo dei kernel per dessert supportati è in questa tabella.
| Rilascio della piattaforma Android | Nocciolo | Supportato fino a |
|---|---|---|
| Androide 10 | android-4.9-qandroid-4.14-qandroid-4.19-q | gennaio 2023 |
| Androide 11 | android-4.14-stableandroid-4.19-stable | gennaio 2024 |
Rami del kernel della versione precedente
I kernel di rilascio vengono mantenuti per fornire backport delle patch citate nel bollettino mensile sulla sicurezza di Android . Sono stati creati per ogni kernel di lancio quando c'era una nuova versione della piattaforma Android. Sono deprecati quando la versione del kernel o della piattaforma associata è deprecata come descritto in Durata del supporto e patch di sicurezza .
Ogni mese, quando viene pubblicato il bollettino sulla sicurezza di Android, questi kernel vengono aggiornati con i backport delle patch citate nel bollettino che sono rilevanti per i kernel upstream e i kernel comuni di Android. Non ricevono patch LTS, quindi il numero di versione minore non cambia mai. Non contengono backport per patch specifiche del fornitore.
In Android 11 e nelle versioni successive della piattaforma, i partner devono unire da kernel dessert o GKI per applicare le patch citate nell'Android Security Bulletin. Non verrà creato alcun kernel di rilascio per Android 11 o versioni successive della piattaforma.
Pertanto, l'elenco completo dei 14 kernel di rilascio è mostrato in questa tabella e nessuno verrà aggiunto.
| Rilascio della piattaforma Android | Nocciolo | Supportato fino a |
|---|---|---|
| Androide 10 | android-4.9-q-releaseandroid-4.14-q-releaseandroid-4.19-q-release | gennaio 2023 |
Funzionalità e lancio dei kernel
Ogni versione della piattaforma Android supporta l'avvio di nuovi dispositivi basati su una qualsiasi delle tre versioni del kernel Linux. Come mostrato nella tabella seguente, i kernel di lancio per Android 11 sono android-4.14-stable , android-4.19-stable e android11-5.4 .
Poiché in genere gli aggiornamenti del kernel non sono richiesti durante l'aggiornamento della versione della piattaforma, i kernel che non dispongono delle funzionalità più recenti per una versione della piattaforma possono comunque essere usati per avviare i dispositivi. Pertanto i kernel progettati per Android 10, come android-4.19-q , possono essere utilizzati sui dispositivi anche dopo aver aggiornato la versione della piattaforma ad Android 11. A partire da Android 12, ci saranno meno kernel di funzionalità rispetto ai kernel di lancio per limitare il numero di KMI stabili che devono essere supportati.
| Rilascio della piattaforma Android | Avvia i kernel | Funzionalità kernel |
|---|---|---|
| Android 10 (2019) | android-4.9-qandroid-4.14-qandroid-4.19-q | android-4.9-qandroid-4.14-qandroid-4.19-q |
| Android 11 (2020) | android-4.14-stableandroid-4.19-stableandroid11-5.4 | android-4.14-stableandroid-4.19-stableandroid11-5.4 |
| Androide 12 (2021) | android-4.19-stableandroid11-5.4 1android12-5.4android12-5.10 | android12-5.4android12-5.10 |
| Androide 13 (2022) | android12-5.4 1android12-5.10 1android13-5.10android13-5.15 | android13-5.10android13-5.15 |
1 Potrebbero essere applicate ulteriori restrizioni se il BSP associato è stato aggiornato per la versione della piattaforma. In termini più generali, il numero di versione Android del kernel deve essere maggiore o uguale alla versione FCM di destinazione . Vedere Oggetto interfaccia fornitore - abbina i rami del kernel per i dettagli. | ||
Gerarchia del kernel comune
Ramificazione da Android-mainline
Il livello superiore della gerarchia del kernel comune è illustrato nella Figura 1.
Figura 1. Creazione di kernel comuni dal kernel della linea principale di Android
Si noti che il nuovo kernel comune Android android12-5.10 è stato ramificato da android-mainline nel 2020. Nel 2021, quando è stato dichiarato il prossimo LTS, android13-5.15 è stato ramificato da android-mainline .
Come mostrato nella Figura 1, ogni versione del kernel è la base per due kernel GKI. Ad esempio, i due kernel v5.4 sono android11-5.4 e android12-5.4 , entrambi kernel di funzionalità per le rispettive versioni della piattaforma. Questo sarà il caso anche per 5.10; android12-5.10 è stato creato quando l'LTS è stato dichiarato e android13-5.10 si diramerà da android12-5.10 alla pietra miliare completa delle funzionalità del kernel nella primavera del 2021 per consentire lo sviluppo di funzionalità per Android 13.
Ciclo di vita del ramo ACK KMI
Il ciclo di vita di un ramo ACK KMI è illustrato di seguito nella Figura 2.
Figura 2. 5.10 Ciclo di vita del ramo ACK KMI
Per chiarire il processo di sviluppo e il ciclo di vita del ramo, la Figura 2 si concentra sui rami ACK KMI per 5.10.
Ogni ramo ACK KMI passa attraverso tre fasi indicate nella Figura 2 da colori diversi in ciascun ramo. Come mostrato, LTS viene regolarmente unito indipendentemente dalla fase.
Fase di sviluppo
Quando viene creato, un ramo ACK KMI entra nella fase di sviluppo ( dev nella figura 2) ed è aperto per contributi di funzionalità per la prossima versione della piattaforma Android. Nella Figura 2, android12-5.10 è stato creato quando 5.10 è stato dichiarato come nuovo kernel LTS upstream. Il secondo ramo ACK KMI per una versione del kernel potrebbe essere creato in precedenza per consentire lo sviluppo della versione successiva. Nella figura 2, android13-5.10 viene creato quando android12-5.10 esce dalla fase di sviluppo.
Fase di stabilizzazione
Quando il ramo ACK KMI viene dichiarato completo di funzionalità, entra nella fase di stabilizzazione , etichettata come stab nella Figura 2. Le funzionalità dei partner e le correzioni di bug sono ancora accettate, ma il tracciamento KMI è abilitato per rilevare eventuali modifiche che interessano l'interfaccia. In questa fase, vengono accettate le modifiche di rottura KMI, ma la definizione KMI deve essere aggiornata se necessario. Vedere la panoramica GKI per i dettagli sul monitoraggio KMI.
Fase congelata KMI
Prima che una nuova versione della piattaforma venga inviata ad AOSP, il ramo ACK KMI viene bloccato e rimane tale per tutta la durata del ramo. Ciò significa che non vengono accettate modifiche che violano il KMI a meno che non venga identificato un grave problema di sicurezza che non può essere mitigato senza influire sul KMI stabile. Per evitare rotture di KMI, alcune patch unite da LTS potrebbero essere modificate o eliminate se la correzione non è richiesta per i dispositivi Android.
Quando un ramo KMI ACK è bloccato, le correzioni di bug e le funzionalità dei partner possono essere accettate purché il kernel comune KMI esistente non sia danneggiato. Il KMI può essere esteso con nuovi simboli esportati purché le interfacce che compongono l'attuale KMI non siano interessate. Quando vengono aggiunte nuove interfacce al KMI, diventano immediatamente stabili e non possono essere interrotte da modifiche future.
Ad esempio, una modifica che aggiunge un campo a una struttura utilizzata da un kernel comune dell'interfaccia KMI non è consentita perché modifica la definizione dell'interfaccia:
struct foo {
int original_field1;
int original_field2;
int new_field; // Not allowed
};
int do_foo(struct foo &myarg)
{
do_stuff(myarg);
}
EXPORT_SYMBOL_GPL(do_foo);
Tuttavia, l'aggiunta di una nuova funzione va bene:
struct foo2 {
struct foo orig_foo;
int new_field;
};
int do_foo2(struct foo2 &myarg)
{
do_stuff2(myarg);
}
EXPORT_SYMBOL_GPL(do_foo2);
Per tutta la durata del kernel GKI, viene mantenuta la retrocompatibilità con lo spazio utente in modo che il kernel possa essere utilizzato in sicurezza per la versione della piattaforma Android con cui è stato avviato il dispositivo. I test continui con le versioni precedenti garantiscono il mantenimento della compatibilità. Quindi, nella Figura 2, il kernel android12-5.10 può essere utilizzato per dispositivi Android 12 e dispositivi Android 13. Poiché la versione della piattaforma Android è compatibile anche con le versioni precedenti, il kernel android12-5.4 può essere utilizzato per i dispositivi Android 13 sia per l'avvio che per l'aggiornamento.
Quando si entra nella fase congelata, il ramo viene contrassegnato con git con la stringa della versione KMI contenente il numero di generazione KMI. Ad esempio, quando android11-5.4 è stato bloccato, è stato contrassegnato con la stringa di versione KMI 5.4-android11-0 dove lo 0 finale è il numero di generazione KMI. Se si verifica un problema di sicurezza o un altro evento che richiede l'accettazione di una patch di modifica del KMI, il numero di generazione del KMI viene incrementato e il ramo contrassegnato nuovamente. Ad esempio, se tale modifica viene accettata in android11-5.4 , il ramo verrà contrassegnato con la nuova versione KMI, 5.4-android11-1 . L'attuale generazione KMI può essere trovata usando il comando uname :
$ uname -r
5.4.61-android11-0-00153-ga972f59040e4
Il numero dopo il rilascio della piattaforma è la generazione KMI (0 in questo caso).
Se la generazione KMI cambia, il kernel non è compatibile con i moduli del fornitore conformi alla precedente generazione KMI, quindi i moduli devono essere ricostruiti e aggiornati in modo sincrono con il kernel. I cambi di generazione KMI dovrebbero essere molto rari.
Compatibilità tra kernel
I requisiti di compatibilità tra i kernel della stessa famiglia LTS stanno cambiando a partire dai nuovi kernel GKI.
kernel GKI
I kernel GKI mantengono la retrocompatibilità con tutte le versioni della piattaforma Android che supportano la versione del kernel. Inoltre, le versioni della piattaforma Android sono retrocompatibili con i kernel GKI delle versioni precedenti. Quindi puoi tranquillamente utilizzare il kernel android12-5.4 sviluppato per Android 12 su dispositivi che eseguono Android 13. La compatibilità viene verificata attraverso continui test VTS e CTS dei kernel GKI con tutte le versioni supportate.
Il KMI è stabile in modo che il kernel possa essere aggiornato senza richiedere una ricostruzione dei moduli del kernel nell'immagine del fornitore.
La compatibilità KMI non viene mantenuta tra diversi kernel GKI. Quindi, ad esempio, un android12-5.10 non può essere sostituito con un kernel android13-5.10 senza ricostruire tutti i moduli.
I kernel GKI sono supportati solo per le versioni iniziali e successive. Non sono supportati per le versioni precedenti. Quindi un kernel android13-5.10 non è supportato sui dispositivi Android 12.
Kernel legacy
I kernel dessert legacy ( *-q e *-stable ) non sono compatibili con le versioni precedenti delle versioni della piattaforma Android, ma i kernel delle due versioni precedenti della piattaforma Android sono supportati per l'aggiornamento. Pertanto, un dispositivo avviato con Android 10 utilizzando un kernel basato su android-4.19-q può continuare a utilizzare il kernel android-4.19-q durante l'aggiornamento ad Android 2020 o aggiornare il codice specifico del fornitore per supportare android-4.19-stable .
Matrice di compatibilità
Questa tabella mostra le versioni del kernel supportate e testate con ogni versione della piattaforma Android.
| Rilascio della piattaforma Android | Kernel supportati per l'aggiornamento | Kernel supportati per il lancio |
|---|---|---|
| Android 10 (2019) | android-3.18 (EOL)android-4.4-o (EOL)android-4.9-o (EOL)android-4.9-p (EOL)android-4.14-p (EOL) | android-4.9-q |
| Android 11 (2020) | android-4.4-o (EOL)android-4.4-p (EOL)android-4.9-o (EOL)android-4.9-p (EOL)android-4.9-q android-4.14-p (EOL)android-4.14-q | android-4.14-stable |
| Androide 12 (2021) | android-4.9-o (EOL)android-4.9-p (EOL)android-4.9-q (EOL)android-4.14-q | android-4.19-stable |
| Androide 13 (2022) | android-4.9-q | android11-5.4 |
Supporta durata e patch di sicurezza
I kernel comuni di Android sono supportati fino a quando il kernel LTS associato o la versione della piattaforma Android non sono più supportati. Mentre un kernel è supportato, continua a ricevere unioni LTS dall'upstream e correzioni di bug per il codice specifico di Android. Queste correzioni includono tutte le patch di sicurezza del kernel citate negli Android Security Bulletin mensili che sono rilevanti per i kernel comuni di Android.
I partner possono essere certi che, unendo regolarmente i kernel comuni di Android, otterranno tutte le patch di sicurezza del kernel possibili.
Test del kernel comune
I kernel comuni vengono testati con diversi sistemi CI oltre ai test a valle da parte dei fornitori.
Test funzionali del kernel Linaro
I test Linaro Kernel Functional Testing (LKFT) avviano varie suite di test tra cui kselftest, LTP, VTS e CTS su un set di dispositivi fisici arm32 e arm64. I risultati dei test recenti possono essere trovati qui .
Test KernelCI
I test di compilazione e avvio di KernelCI vengono avviati ogni volta che una nuova patch viene salvata in un ramo del kernel comune. Diverse centinaia di configurazioni di build vengono testate e avviate su varie schede. I risultati recenti per i kernel Android possono essere trovati qui .
Test Android pre-invio e post-invio
I test di preinvio vengono utilizzati per impedire l'introduzione di errori nei kernel comuni. I risultati non sono disponibili pubblicamente in questo momento.
Il test post-invio di Android viene eseguito quando una nuova patch viene salvata in un ramo del kernel comune. Inserendo aosp_kernel come nome di ramo parziale, viene visualizzato un elenco di rami del kernel con i risultati disponibili. Ad esempio, i risultati per android-mainline possono essere trovati qui .
Test di 0 giorni
Il test di 0 giorni esegue il test patch per patch su tutti i rami del kernel comuni di Android quando vengono salvate nuove patch. Vengono eseguiti vari test di avvio, funzionali e delle prestazioni. Unisciti al gruppo pubblico cros-kernel-buildreports
Matrice di prova
| Kernel comune di Android | Rilasci della piattaforma Android | Suite di prova | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Maestro | 13 | 12 | 11 | 10 | 9 (torta) | LKFT | KernelCI | Pre invio | Invia Invia | 0 giorni | |
android-mainline | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android13-5.15 | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android12-5.10 | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android11-5.4 | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
android-4.19-q | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ❌ | ❌ | ✅ | android-4.9-q | ❌ | ❌ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ❌ | ❌ | ✅ |
Contributo ai kernel comuni di Android
In generale, lo sviluppo delle funzionalità dovrebbe essere eseguito sulla linea principale di Linux e non sui kernel comuni di Android. Lo sviluppo a monte è fortemente incoraggiato e, dopo che lo sviluppo è stato accettato lì, può essere facilmente riportato al ramo ACK specifico, se necessario. L' Android Kernel Team è lieto di supportare gli sforzi di upstreaming a vantaggio dell'ecosistema Android.
Inviare le patch a Gerrit e conformarsi a queste linee guida per il contributo .