Kernel comuni di Android

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 community Android che non sono state unite ai kernel mainline o LTS (Long Term Supported). 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 upstream
• Funzionalità del fornitore/OEM utili per altri partner dell'ecosistema

android-mainline è il ramo di sviluppo principale per le funzionalità di Android. Linux mainline viene unito 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 le patch specifiche di Android. Nel 2019 questa procedura è stata modificata per creare un ramo del nuovo kernel comune Android da android-mainline. Questo nuovo modello evita lo sforzo significativo di inoltrare la porta e testare le patch Android ottenendo lo stesso risultato in modo incrementale. android-mainline viene sottoposto a test continui significativi, questo modello include un kernel di alta qualità dal giorno della pubblicazione.

Quando viene dichiarato un nuovo LTS upstream, il kernel comune corrispondente viene ramificato da android-mainline. Ciò consente ai partner di iniziare un progetto prima della dichiarazione della versione LTS, eseguendo il merge 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 unioni regolari dal kernel LTS associato. Queste unioni vengono eseguite normalmente subito dopo la pubblicazione della release LTS. Ad esempio, quando è stato pubblicato Linux 6.1.75, è stato unito al kernel comune 6.1 (android14-6.1). I partner sono fortemente incoraggiati ad aggiornare i propri kernel per rimanere al passo con le correzioni di bug specifiche di LTS e Android.

ACK KMI kernel branch

I kernel GKI hanno un'interfaccia del modulo kernel stabile. Il KMI è identificato in modo univoco dalla versione del kernel e dalla release della piattaforma Android, pertanto i rami 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.

Kernel delle funzionalità e dei lanci

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

Poiché gli upgrade del kernel non sono necessari durante l'aggiornamento della release della piattaforma, i kernel che non dispongono delle funzionalità più recenti per una release della piattaforma possono comunque essere utilizzati per lanciare i dispositivi. Pertanto, 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

Branch 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 comune Android android14-6.1 da android-mainline. Nel 2023, quando è stata dichiarata la successiva versione LTS, android15-6.6 è stata creata da android-mainline.

Come mostrato nella Figura 1, ogni versione del kernel può essere la base per due kernel GKI. Ad esempio, i due kernel v5.15 sono android13-5.15 e android14-5.15, entrambi kernel delle funzionalità per le rispettive release della piattaforma. Questo è stato il caso anche per la versione 5.10; android12-5.10 è stato creato quando è stato dichiarato l'LTS e android13-5.10 è stato creato da android12-5.10 al traguardo di completamento delle funzionalità del kernel nella primavera del 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 esiste un kernel android15-6.1).

Ciclo di vita del ramo KMI ACK

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

Figura 2. 6.6 Ciclo di vita del ramo KMI ACK

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

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

Fase di sviluppo

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

Fase di stabilizzazione

Quando il ramo ACK KMI viene dichiarato completo, entra nella fase di stabilizzazione (etichettata come stabile nella Figura 2). Le funzionalità dei partner e le correzioni di bug vengono ancora accettate, ma il monitoraggio dell'interfaccia di gestione delle informazioni (KMI) è abilitato per rilevare eventuali modifiche che interessano l'interfaccia. In questa fase, le modifiche che provocano un errore nell'interfaccia KMI vengono accettate e la definizione dell'interfaccia KMI viene aggiornata con una cadenza predefinita (normalmente ogni due settimane). Consulta la panoramica di GKI per i dettagli sul monitoraggio di KMI.

Fase di blocco di KMI

Prima che una nuova release della piattaforma venga inviata 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 interrompono la KMI, a meno che non venga identificato un grave problema di sicurezza che non può essere mitigato senza influire sulla KMI stabile. Per evitare interruzioni del KMI, alcune patch unite da LTS potrebbero essere modificate o eliminate se la correzione non è necessaria per i dispositivi Android.

Quando un ramo ACK KMI è bloccato, le correzioni di bug e le funzionalità partner possono essere accettate a condizione che il kernel comune KMI esistente non sia danneggiato. L'interfaccia KMI può essere estesa con nuovi simboli esportati, a condizione che le interfacce che la compongono non vengano 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'interfaccia KMI del kernel comune 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 è 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 l'intero ciclo di vita del kernel GKI, la compatibilità con le versioni precedenti con lo spazio utente viene mantenuta in modo che il kernel possa essere utilizzato in sicurezza per la versione della piattaforma Android con cui è stato lanciato il dispositivo. I test continui con le versioni precedenti mantengono la 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, il kernel android14-6.1 potrebbe essere utilizzato per i dispositivi Android 15 per l'avvio 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 successivo 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 il rilascio della piattaforma è 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 ricompilati e aggiornati in modo sincrono con il kernel. Dopo il blocco del KMI, le modifiche alla generazione del KMI sono previste molto raramente.

Compatibilità tra kernel

I requisiti di compatibilità tra i kernel della stessa famiglia LTS cambiano 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 i kernel GKI delle release precedenti. In questo modo, puoi utilizzare in sicurezza il kernel android14-6.1 sviluppato per Android 14 (2023) sui dispositivi con Android 15 (2024). La compatibilità viene verificata tramite test VTS e CTS continui dei kernel GKI con tutte le release supportate.

L'interfaccia KMI è stabile, quindi il kernel può essere aggiornato senza richiedere una ricompilazione dei moduli del kernel nell'immagine del fornitore.

La compatibilità KMI non viene mantenuta tra i diversi kernel GKI. Ad esempio, un kernel android14-6.1 non può essere sostituito con un kernel android15-6.6 senza ricompilare 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.

Durata del supporto e patch di sicurezza

Gli ACK ricevono unioni LTS upstream e 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 per ACK.

Gli ACK potrebbero essere supportati più a lungo del kernel stabile upstream corrispondente su kernel.org. In questo caso, Google fornisce il supporto esteso fino alla data di fine ciclo di vita (EOL) mostrata in questa sezione. Quando i kernel raggiungono la fine 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, la durata del supporto per i kernel stabili è di 4 anni.

Questa tabella mostra le durate degli ACK supportati:

Test del kernel comuni

I kernel comuni vengono testati con diversi sistemi CI, oltre ai test downstream dei fornitori.

Test funzionale del kernel Linux

Linux Kernel Functional Test (LKFT) avvia 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 nella pagina android-lkft.

Test KernelCI

I test di build e avvio di KernelCI vengono avviati ogni volta che viene eseguito il commit di una nuova patch in un ramo del kernel comune. Vengono testate e avviate diverse centinaia di configurazioni di build su varie schede. I risultati recenti per i kernel Android sono disponibili sul sito KernelCL.

Test pre-invio e post-invio di Android

I test pre-invio vengono utilizzati per evitare che vengano introdotti errori nei kernel comuni di Android. Il riepilogo dei risultati del test è disponibile nella scheda "Controlli" della modifica del codice in Android common kernel gerrit.

I test post-invio di Android vengono eseguiti sulle nuove build pubblicate nei rami del kernel comune di Android quando vengono commit di nuove patch in un ramo del kernel comune di Android in ci.android.com. Se inserisci aosp_kernel come nome parziale del ramo in ci.android.com, visualizzi un elenco di rami del kernel con risultati disponibili. Ad esempio, i risultati per android-mainline sono disponibili nella dashboard di integrazione della build continua di Android (CI Android). Fai clic su una build specifica per trovare lo stato del test nella scheda Test Results.

I test definiti da test-mapping con il gruppo di test kernel-presubmit nell'albero dei sorgenti della piattaforma Android vengono eseguiti come pre-invio per i rami del kernel Android. Ad esempio, la seguente configurazione in test/vts/tests/kernel_proc_file_api_test/TEST_MAPPING abilita vts_kernel_proc_file_api_test come test di pre-invio al momento del check-in del codice del kernel comune di Android.

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

Test zero-day

Il test 0-day esegue test patch per patch su tutti i rami del kernel comune di Android quando vengono eseguite nuove patch. Vengono eseguiti vari test di avvio, funzionali e di rendimento. 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 sui kernel comuni di Android. Lo sviluppo upstream è fortemente incoraggiato e, una volta accettato, può essere eseguito il backporting al ramo ACK specifico in base alle esigenze. Il team del kernel Android è felice di supportare gli sforzi di upstreaming a vantaggio dell'ecosistema Android.

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