Kernel comuni di Android

I kernel comuni AOSP (noti anche come kernel comuni Android o ACK) sono kernel downstream di 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à fornitore/OEM utili per altri partner dell'ecosistema

android-mainline è il ramo di sviluppo principale per le funzionalità di Android. Il kernel mainline di Linux viene unito ad android-mainline ogni volta che Linus Torvalds pubblica una release o un candidato per la release. Prima del 2019, i kernel comuni Android venivano creati clonando il kernel LTS dichiarato di recente e aggiungendo le patch specifiche di Android. Questa procedura è stata modificata nel 2019 per creare il nuovo kernel comune Android da android-mainline. Questo nuovo modello evita il notevole sforzo di eseguire il porting e testare le patch di Android, ottenendo lo stesso risultato in modo incrementale. android-mainline è sottoposto a test continui significativi, quindi questo modello include un kernel di alta qualità dal giorno della pubblicazione.

Quando viene dichiarato un nuovo kernel LTS upstream, il kernel comune corrispondente viene creato da android-mainline. In questo modo, i partner possono iniziare un progetto prima della dichiarazione della versione LTS, eseguendo l'unione da android-mainline. Dopo aver creato il nuovo ramo del kernel comune, i partner possono modificare facilmente l'origine dell'unione nel nuovo ramo.

Gli altri rami del kernel comune 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 vivamente invitati ad aggiornare i propri kernel per rimanere aggiornati con le correzioni di bug specifiche di LTS e Android.

Ramo del kernel KMI ACK

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

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 comune Android android14-6.1 da android-mainline. Nel 2023, quando è stato dichiarato il successivo kernel LTS, è stato creato android15-6.6 da android-mainline.

Come mostrato nella Figura 1, ogni versione 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 di funzionalità per le rispettive release della piattaforma. Questo è stato il caso anche per 5.10; android12-5.10 è stato creato quando è stato dichiarato il kernel 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), è disponibile un solo nuovo kernel GKI per versione 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. Ciclo di vita del ramo KMI ACK 6.6

Per chiarire la procedura di sviluppo e il ciclo di vita del ramo, la Figura 2 si concentra sui rami KMI ACK per 6.6.

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

Fase di sviluppo

Quando viene creato, un ramo KMI ACK entra nella fase di sviluppo (etichettata come dev nella Figura 2) ed è aperto ai contributi di funzionalità per la prossima 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 KMI ACK viene dichiarato completo, entra nella fase di stabilizzazione (etichettata come stable nella Figura 2). Le funzionalità e le correzioni di bug dei partner sono ancora accettate, ma il monitoraggio KMI è abilitato per rilevare eventuali modifiche che interessano l'interfaccia. In questa fase, le modifiche che interrompono il KMI vengono accettate e la definizione del KMI viene aggiornata con una cadenza predefinita (in genere ogni due settimane). Per informazioni dettagliate sul monitoraggio KMI, consulta la panoramica di GKI.

Fase di blocco KMI

Prima che una nuova release della piattaforma venga inviata ad AOSP, il ramo KMI ACK viene bloccato e rimane bloccato per tutta la durata del ramo. Ciò significa che non vengono accettate modifiche che interrompono 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 dal kernel LTS potrebbero essere modificate o eliminate se la correzione non è necessaria per i dispositivi Android.

Quando un ramo KMI ACK è bloccato, le correzioni di bug e le funzionalità dei partner possono essere accettate a condizione che il kernel comune KMI esistente non venga interrotto. Il KMI può essere esteso con nuovi simboli esportati a condizione che le interfacce che compongono il KMI corrente non siano interessate. Quando vengono aggiunte nuove interfacce al KMI, diventano immediatamente stabili e non possono essere interrotte da modifiche future.

Ad esempio, non è consentita una modifica che aggiunge un campo a una struttura utilizzata da un kernel comune dell'interfaccia KMI 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 tutta la durata del kernel GKI, viene mantenuta la compatibilità con le versioni precedenti dello spazio utente 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 mantengono la compatibilità. Quindi, 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 il lancio o l'upgrade.

Numero di generazione KMI

Se durante la fase di stabilizzazione si verifica un'unione del kernel 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 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 è 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, quindi i moduli devono essere ricompilati e aggiornati in modo sincrono con il kernel. Dopo il blocco KMI, le modifiche alla generazione 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 supportano la versione kernel. Inoltre, le release della piattaforma Android sono compatibili con le versioni precedenti dei kernel GKI delle release precedenti. Pertanto, 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.

Il 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 kernel GKI diversi. 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 all'ACK.

Gli ACK potrebbero essere supportati per un periodo più lungo rispetto al kernel stabile upstream corrispondente su kernel.org. In questo caso, Google fornisce il supporto esteso fino alla data di fine del ciclo di vita indicata 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 la durata del supporto per gli ACK supportati:

Test del kernel comune

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

Test KernelCI

I test di compilazione 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 compilazione su varie schede. I risultati recenti per i kernel Android sono disponibili sul sito KernelCL.

Test preinvio e postinvio di Android

I test preinvio vengono utilizzati per impedire l'introduzione di errori nei kernel comuni Android. Il riepilogo dei risultati dei test è disponibile nella scheda "Controlli" della modifica del codice in Gerrit del kernel comune Android.

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

I test definiti dal mapping dei test con il gruppo di test kernel-presubmit nell'albero di origine della piattaforma Android vengono eseguiti come test preinvio 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 preinvio al check-in del codice del kernel comune Android.

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

Test zero-day

Il testzero-day esegue test patch per patch su tutti i rami del kernel comune 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 Android

In genere, lo sviluppo delle funzionalità deve essere eseguito sul kernel mainline di Linux e non sui kernel comuni Android. Lo sviluppo upstream è vivamente consigliato e, una volta accettato, può essere eseguito il backport al ramo ACK specifico in base alle esigenze. Il team del kernel Android è felice di supportare gli sforzi di upstream a vantaggio dell'ecosistema Android.

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