Kernel comuni di Android

I kernel comuni AOSP (noti anche come ACK o kernel comuni Android) sono downstream dei kernel kernel.org e includono patch di interesse per la community di Android che non sono state unite nei kernel principali o LTS (Long Term Support). Queste patch possono includere:

• Backport e cherry-pick delle funzionalità upstream necessarie per le funzionalità di Android
• Funzionalità pronte per i dispositivi Android, ma ancora in fase di sviluppo a monte
• Funzionalità del fornitore/OEM utili per altri partner dell'ecosistema

android-mainline è il ramo di sviluppo principale per le funzionalità Android. La versione principale di Linux viene unita a android-mainline ogni volta che Linus Torvalds pubblica una release o una release candidate. Prima del 2019, i kernel comuni di Android venivano creati clonando il kernel LTS dichiarato di recente e aggiungendo patch specifiche per Android. Questo processo è cambiato nel 2019 per creare il nuovo kernel Android comum da android-mainline. Questo nuovo modello evita l'impegno significativo necessario per inoltrare le patch di Android e testarle ottenendo lo stesso risultato in modo incrementale. android-mainline viene sottoposto a test continui significativi, questo modello garantisce un kernel di alta qualità dal giorno della pubblicazione.

Quando viene dichiarato un nuovo LTS in upstream, il kernel comune corrispondente viene derivato da android-mainline. In questo modo, i partner possono iniziare un progetto prima della dichiarazione della versione LTS, unendo i dati da android-mainline. Dopo aver creato il nuovo ramo del kernel comune, i partner possono modificare facilmente la fonte di unione nel nuovo ramo.

Gli altri rami del kernel comuni ricevono unioni regolari dal kernel LTS associato. In genere queste unioni vengono eseguite immediatamente dopo la pubblicazione della release LTS. Ad esempio, quando Linux 6.1.75 è stato pubblicato, è stato unito al kernel comune 6.1 (android14-6.1). I partner sono vivamente invitati ad aggiornare i loro kernel per essere sempre al passo con le correzioni di bug specifiche di LTS e Android.

Ramo del kernel KMI ACK

I kernel GKI hanno un'interfaccia stabile del modulo del kernel. Il KMI è identificato in modo univoco dalla versione del kernel e dalla release della piattaforma Android, pertanto i branch sono denominati ANDROID_RELEASE-KERNEL_VERSION. Ad esempio, il kernel GKI 6.1 per Android 14 si chiama android14-6.1. Per Android 15 è stato introdotto il kernel GKI android15-6.6.

Inserire e avviare i kernel

Prima di Android 15, per il lancio del dispositivo poteva essere utilizzato uno dei tre kernel più recenti. A partire da Android 15, le due versioni del kernel più recenti possono essere utilizzate per il lancio del dispositivo. I kernel di lancio per Android 15 sono android15-6.6 e android14-6.1.

Poiché gli upgrade dei kernel non sono necessari quando si aggiorna la release della piattaforma, i kernel privi delle ultime funzionalità per una release della piattaforma possono comunque essere utilizzati per avviare i dispositivi. Di conseguenza, i kernel progettati per Android 14, come android14-6.1, possono essere utilizzati sui dispositivi anche dopo l'upgrade della release della piattaforma ad Android 15.

Gerarchia del kernel comune

Ramo da android-mainline

Il livello superiore della gerarchia del kernel comune è mostrato nella Figura 1.

Figura 1. Creazione di kernel comuni dal kernel android-mainline

Tieni presente che nel 2022 è stato creato un nuovo kernel Android common android14-6.1 da android-mainline. Nel 2023, quando è stato dichiarato il successivo LTS, android15-6.6 è stato diramato da android-mainline.

Come mostrato nella Figura 1, ogni versione del kernel può essere la base di due kernel GKI. Ad esempio, i due kernel v5.15 sono android13-5.15 e android14-5.15, entrambi kernel di funzionalità per le rispettive release della piattaforma. Questo è stato anche per la versione 5.10. android12-5.10 è stato creato quando è stato dichiarato LTS e android13-5.10 si è diramato da android12-5.10 al traguardo del completamento delle funzionalità del kernel nella primavera 2021 per consentire lo sviluppo di funzionalità per Android 13. A partire da Android 15 (2024), è presente un solo nuovo kernel GKI per versione del kernel (non è presente un kernel android15-6.1).

Ciclo di vita del ramo KMI ACK

Il ciclo di vita di un ramo KMI ACK è mostrato di seguito nella Figura 2.

Figura 2. 6.6 Ciclo di vita del ramo KMI di ACK

Per chiarire il processo di sviluppo e il ciclo di vita dei branch, la Figura 2 si concentra sui branch KMI di ACK per 6.6.

Ogni ramo KMI ACK passa attraverso tre fasi indicate nella Figura 2 con colori diversi in ogni ramo. Come mostrato, LTS viene unito regolarmente indipendentemente dalla fase.

Fase di sviluppo

Una volta creato, un ramo KMI ACK entra nella fase di sviluppo (etichettata come dev nella Figura 2) ed è aperto ai contributi delle funzionalità per la successiva release della piattaforma Android. Nella Figura 2, android15-6.6 è stato creato quando la versione 6.6 è stata dichiarata come nuovo kernel LTS upstream.

Fase di stabilizzazione

Quando il ramo KMI di ACK viene dichiarato completo, entra nella fase di stabilizzazione (contrassegnata come stabile nella Figura 2). Le funzionalità dei partner e le correzioni di bug sono ancora accettate, ma il monitoraggio KMI è abilitato per rilevare eventuali modifiche che influiscono sull'interfaccia. In questa fase sono accettate le modifiche che interrompono i KMI e la definizione dei KMI viene aggiornata secondo una cadenza predefinita (di solito ogni due settimane). Consulta la panoramica di GKI per informazioni dettagliate sul monitoraggio dei KMI.

Fase bloccata KMI

Prima che venga eseguito il push di una nuova release della piattaforma ad AOSP, il ramo ACK KMI viene bloccato e rimane bloccato 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 interruzioni del KMI, alcune patch unite dall'LTS potrebbero essere modificate o eliminate se la correzione non è necessaria per i dispositivi Android.

Quando un ramo KMI ACK è bloccato, è possibile accettare correzioni di bug e funzionalità dei partner se il kernel KMI comune esistente non è danneggiato. Il KMI può essere esteso con nuovi simboli esportati, a condizione che le interfacce che compongono il KMI attuale 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é cambia 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 è consentita:

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, la compatibilità con le versioni precedenti dello spazio utente viene mantenuta in modo che il kernel possa essere utilizzato in sicurezza per la release della piattaforma Android con cui è stato lanciato il dispositivo. I test continui con le release precedenti garantiscono il mantenimento della compatibilità. Pertanto, nella Figura 2, il kernel android15-6.6 può essere utilizzato per i dispositivi Android 15 e versioni successive. Poiché la release della piattaforma Android è compatibile anche con le versioni precedenti, è possibile utilizzare il kernel android14-6.1 per i dispositivi Android 15 per il lancio o l'upgrade.

Numero di generazione del KMI

Se durante la fase di stabilizzazione si verifica un'unione LTS o un problema di sicurezza o un altro evento che richiede l'accettazione di una patch che modifica il KMI, il numero di generazione del KMI registrato in build.config.common viene incrementato. La generazione KMI corrente può essere trovata utilizzando il comando uname:

$ uname -r
6.6.30-android15-6-g86d10b30f51f

Il numero dopo la release della piattaforma indica la generazione KMI (6 in questo caso).

Se la generazione KMI cambia, il kernel non è compatibile con i moduli del fornitore conformi alla generazione KMI precedente, pertanto i moduli devono essere ricostruiti e aggiornati in modo sincrono con il kernel. Dopo il blocco dei KMI, le modifiche alla generazione dei KMI dovrebbero essere molto rare.

Compatibilità tra i 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 compatibilità con le versioni precedenti di tutte le release della piattaforma Android che supportavano la versione del kernel. Inoltre, le release della piattaforma Android sono compatibili con le versioni precedenti dei kernel GKI delle release precedenti. Quindi puoi usare in sicurezza il kernel android14-6.1 sviluppato per Android 14 (2023) su dispositivi con Android 15 (2024). La compatibilità viene verificata tramite test continui di VTS e CTS dei kernel GKI con tutte le release supportate.

Il KMI è stabile, pertanto il kernel può essere aggiornato senza richiedere una ricostruzione degli eventuali moduli del kernel nell'immagine del fornitore.

La compatibilità KMI non viene mantenuta tra i diversi kernel GKI. Quindi, ad esempio, un kernel android14-6.1 non può essere sostituito con un kernel android15-6.6 senza creare nuovamente tutti i moduli.

I kernel GKI sono supportati solo per le release iniziali e successive. Non sono supportati per le release precedenti. Pertanto, un kernel android15-6.6 non è supportato per i dispositivi con Android 14 (2023).

Matrice di compatibilità

Questa tabella mostra le versioni del kernel supportate e testate con ogni release della piattaforma Android.

Supporta le patch di sicurezza e le durate

Gli ACK ricevono le unioni LTS dall'upstream e le correzioni di bug per il codice specifico di Android. Queste correzioni includono tutte le patch di sicurezza del kernel citate nei Bollettini sulla sicurezza di Android mensili pertinenti a ACK.

Gli ACK potrebbero essere supportati per più tempo rispetto al kernel stabile upstream corrispondente su kernel.org. In questo caso, Google fornisce assistenza estesa fino alla data di fine del ciclo di vita indicata in questa sezione. Quando i kernel arrivano al termine del ciclo di vita, non sono più supportati da Google e i dispositivi che li eseguono sono considerati vulnerabili.

A partire dal kernel 6.6, il ciclo di vita del supporto per i kernel stabili è di 4 anni.

Questa tabella mostra la durata delle ACK supportate:

Test comuni del kernel

I kernel comuni vengono testati con diversi sistemi CI, oltre ai test a valle eseguiti dai fornitori.

Test funzionale del kernel Linux

I test Linux Kernel Functional Test (LKFT) avviano varie suite di test, tra cui kselftest, LTP, VTS e CTS, su un insieme di dispositivi fisici ARM32 e ARM64. I risultati dei test recenti sono disponibili qui.

Test di KernelCI

I test di build e avvio KernelCI vengono avviati ogni volta che viene eseguito il commit di una nuova patch 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 sono disponibili qui.

Test pre-invio e post-invio di Android

I test di preinvio vengono utilizzati per evitare l'introduzione di errori nei kernel comuni di Android. Il riepilogo dei risultati del test si trova nella scheda "Controlli" della modifica del codice nella gerrit del kernel comune di Android.

I test post-invio di Android vengono eseguiti su nuove build pubblicate nei rami del kernel comune di Android quando vengono eseguiti commit di nuove patch in un ramo del kernel comune di Android in ci.android.com. Inserendo aosp_kernel come nome parziale del ramo in ci.android.com, viene visualizzato un elenco di rami del kernel con risultati disponibili. Ad esempio, i risultati per android-mainline sono disponibili qui. Quando fai clic su una determinata build, troverai lo stato del test nella scheda Test Results.

I test definiti da test-mapping con il gruppo di test kernel-presubmit nella struttura della sorgente della piattaforma Android verranno eseguiti come pre-submit per i branch del kernel di Android. Ad esempio, la seguente configurazione in test/vts/tests/kernel_proc_file_api_test/TEST_MAPPING attiverà vts_kernel_proc_file_api_test come test di presbumit al check-in del codice del kernel comune di Android.

{
  "kernel-presubmit": [
    {
      "name": "vts_kernel_proc_file_api_test"
    }
  ]
}

Test zero-day

Il test di 0 giorni esegue test patch per patch su tutti i rami del kernel comuni di Android quando vengono confermate nuove patch. Vengono eseguiti vari test di avvio, funzionamento e prestazioni. Unisciti al gruppo pubblico cros-kernel-buildreports

Matrice di test

Contribuire ai kernel comuni di Android

In genere, lo sviluppo delle funzionalità deve essere eseguito su Linux mainline e non su i kernel comuni di Android. Lo sviluppo upstream è vivamente incoraggiato e, dopo che lo sviluppo è stato accettato, può essere facilmente eseguito il backporting al ramo ACK specifico in base alle esigenze. Il team del kernel di Android è felice di supportare le attività di upstreaming a beneficio dell'ecosistema Android.

Invia le patch a Gerrit e rispetta queste linee guida per i contributi.