L'immagine kernel generica di Google è il prossimo passo verso la risoluzione del problema della frammentazione di Android

Google lavora da anni per ridurre la frammentazione su Android, anche se parte della causa di ciò è la natura intrinseca di Android e l'arma a doppio taglio della scelta e della libertà. Esistono innumerevoli OEM attivi nel settore e tutti desiderano apportare le proprie modifiche ai propri dispositivi. Il problema quindi è che sembra che gli aggiornamenti del sistema operativo Android siano lenti da implementare su tutta la linea, ma non c'è molto che Google possa effettivamente fare per costringere gli OEM ad aggiornare i propri dispositivi. Pertanto, la cosa migliore che Google può fare è rendere il processo di aggiornamento il più semplice e agevole possibile.

Alleviare il dolore dell'aggiornamento Android

La prima grande iniziativa nel progetto a lungo termine di Google per ridurre l’onere dello sviluppo è stata Progetto Treble

. Annunciato insieme ad Android 8.0 Oreo nel 2017, Project Treble ha modularizzato Android separando il framework del sistema operativo dall'implementazione del fornitore (HAL e il fork del kernel Linux specifico del dispositivo). Ciò ha reso più semplice per gli OEM Android ribasare i propri sistemi operativi sull'ultimo framework AOSP, poiché potevano avviare la versione più recente senza bisogno di codice aggiornato dai fornitori. Di conseguenza, gli OEM potrebbero preparare i loro fork Android personalizzati più rapidamente di prima e, per estensione, implementare più rapidamente i principali aggiornamenti del sistema operativo.

Il passo successivo nei piani di Google era quello di semplificare la fornitura di aggiornamenti ai componenti chiave di Android. Google ha chiamato questa iniziativa Linea principale del progetto quando lo ha introdotto insieme ad Android 10 nel 2019. Google ha sostanzialmente preso il controllo dei componenti chiave del sistema operativo e ha vietato agli OEM di modificarli. Hanno quindi impostato un meccanismo di consegna tramite Google Play in modo da poter implementare da remoto gli aggiornamenti a questi componenti chiave senza dover attendere che gli OEM applichino autonomamente le patch. Mainline ha notevolmente migliorato la rapidità con cui i dispositivi ricevono versioni aggiornate di importanti componenti del sistema operativo, migliorando a sua volta la sicurezza dell'ecosistema Android nel suo complesso.

Quando si tratta di Treble, però, il kernel Linux realisticamente non dovrebbe essere raggruppato con il codice del fornitore closed-source. Todd Kjos a la Linux Plumbers Conference di quest'anno ha spiegato in passato le difficoltà che si incontrano quando si tratta di frammentazione su Android, e gran parte ora è incentrata sul kernel Linux che gli OEM forniscono con i loro dispositivi. Per contesto, Google inserisce ciascun kernel Linux principale in un "Kernel comune Android" (ACK), che segue da vicino la versione principale ma aggiunge alcune patch specifiche per Android. I fornitori di SoC come Qualcomm, MediaTek e Samsung si biforcano Quello kernel per ogni SoC che producono. Gli OEM quindi prendono il kernel specifico del SoC e aggiungono ulteriori patch per implementare il supporto per l'hardware specifico che desiderano fornire.

Il diagramma sopra mostra come il kernel di un dispositivo attraversa diversi livelli di modifica che lo astraono dal kernel LTS di Linux. Per semplificarlo, iniziamo con il kernel Linux e questo verrà unito al kernel comune Android con alcune modifiche. Da lì, il kernel comune di Android viene fuso in un kernel del fornitore (Qualcomm, MediaTek, ecc.) con le proprie modifiche e cambiamenti. Infine, il kernel del fornitore viene unito al kernel specifico del dispositivo OEM. A questo punto, il kernel di qualsiasi dispositivo è molto lontano dal kernel Linux LTS con cui è iniziato.

Come risultato di tutti questi fork, fino al 50% del codice in esecuzione su un dispositivo Android è codice fuori dall'albero, il che significa che non proviene da kernel Linux upstream o AOSP comuni. Ciò rende incredibilmente difficile (per non parlare del dispendio di tempo e denaro) unire le modifiche a monte. Per gli OEM non vi è alcun incentivo a farlo, ma questa pratica può essere dannosa per la sicurezza dei dispositivi. Questo è anche il motivo per cui molti dispositivi Android vengono lasciati su versioni precedenti del kernel LTS, il che ha l'effetto collaterale di perdere l'accesso alle nuove funzionalità del kernel Linux.

Android è frammentato e Google lo sa

Google sa benissimo che questo è un problema e ha anche una sezione chiamata "I costi della frammentazione" nella documentazione per sviluppatori Android. Google lo dice "la maggior parte dei dispositivi di punta viene fornita con una versione del kernel vecchia di almeno 18 mesi". Ancora peggio, lo dice anche Google "Android 10 supporta i kernel 3.18, 4.4, 4.9, 4.14 e 4.19, che in alcuni casi non sono stati migliorati con nuove funzionalità da Android 8 nel 2017." Ciò rende difficile aggiungere funzionalità che richiedono nuove versioni del kernel Linux. Il kernel Linux 3.18 è stato lanciato nel dicembre 2014, quando Android 5.0 Lollipop era l'ultima versione di Android. Questo è chiaramente un problema e può frenare la piattaforma.

Ad esempio, Code Aurora Forum, o CAF in breve, ospita il codice sorgente per vari SoC Qualcomm Snapdragon. Qualcomm, come SoC fornitore, distribuisce una versione biforcuta del kernel Linux a OEM/ODM e tali aziende aggiungono quindi modifiche specifiche al dispositivo sulla spedizione dispositivi. Questo è ciò che aggiunge diversi livelli di frammentazione. Inoltre, Qualcomm apporta modifiche al framework AOSP per ottimizzare Android per ciascuna delle piattaforme mobili Snapdragon dell'azienda. Qualcomm distribuisce privatamente il kernel Linux modificato, il framework AOSP e altri strumenti software ai suoi partner come parte di un Board Support Package o BSP. CAF è il luogo in cui Qualcomm pubblica pubblicamente queste modifiche al kernel Linux e al framework AOSP.

Questa versione CAF può essere utile per gli sviluppatori di ROM personalizzate che desiderano utilizzarla come punto di partenza anziché AOSP puro, motivo per cui a volte vedi ROM “basate su CAF” sui nostri forum. Ricordate lo Snapdragon 625 che sembrava alimentare per anni così tanti smartphone di fascia media? Quello lanciato con Linux Kernel 3.18, e solo verso la fine del 2018 (due anni dopo il lancio del chipset) Qualcomm ha aggiornato i sorgenti del kernel e li ha pubblicati su CAF per msm8953 (il nome del chipset dello Snapdragon 625) che porta il supporto per Linux Kernel 4.9. Il problema è che la maggior parte degli OEM non aggiornerà i telefoni a questa nuova versione del kernel Linux, soprattutto non i telefoni di fascia media due anni dopo l'uscita del chip rilasciato. Certo, è molto raro che avvenga un aggiornamento importante del kernel come questo, ma il punto è che ha è successo, quindi non è solo uno scenario impossibile.

Tutto sommato, l'attuale frammentazione di Android è un disastro, per dirla alla leggera. Gli ultimi tentativi di Google di correggere questa frammentazione si presentano sotto forma di Generic Kernel Image o GKI.

Presentazione dell'immagine kernel generica

Per risolvere questa frammentazione, Google ha lavorato sull'Android Generic Kernel Image (GKI). Questo è essenzialmente un kernel compilato direttamente da un ramo ACK. La GKI isola le personalizzazioni dei fornitori SoC e degli OEM nei moduli plug-in, eliminando il codice fuori struttura e consentendo a Google di inviare gli aggiornamenti del kernel direttamente all'utente finale. Per oltre un anno, Google ha lavorato su un modo per fornire gli aggiornamenti GKI tramite il Play Store, attraverso l'utilizzo di un modulo Mainline.

Di conseguenza, i dispositivi avviati con Android 12 che eseguono Linux kernel 5.10.43 o versioni successive devono eseguire una delle seguenti operazioni: secondo Mishaal Rahman.

• Distribuisci un'immagine di avvio firmata da Google

O

• Distribuisci un'immagine di avvio con un kernel che esporta una KMI (Kernel Module Interface) che è un sottoinsieme della KMI esportata dal GKI, esporta un'API dello spazio utente che è un superset dell'UAPI esposta dalla GKI e supporta tutte le funzionalità della GKI corrispondente versione

I fornitori possono creare moduli che si collegano alla GKI, ma l'idea della GKI è che Google si assuma l'onere della responsabilità di gestire le modifiche del kernel. L'interfaccia del modulo kernel (o KMI, ne parleremo più avanti nelle parti successive dell'articolo) è effettivamente il luogo in cui ci si aspetta che vada il codice fuori dall'albero.

La serie Google Pixel 6 è stata lanciata con Android 12 pronto all'uso e viene fornita con il kernel Linux 5.10 ed è il primo telefono a essere fornito con un GKI. Poiché Google potrebbe potenzialmente aggiornare il kernel tramite il Play Store, potremmo anche vedere frequenti aggiornamenti del kernel, poiché gli aggiornamenti del kernel LTS vengono generalmente rilasciati settimanalmente. In ogni caso, è un sistema molto migliore rispetto al metodo attualmente ingombrante di aggiornamento tramite OTA, anche se ciò significa che è intrinsecamente legato al framework GMS.

Google definisce semplicemente il GKI come segue:

• È costruito dalle fonti ACK.
• È un file binario a kernel singolo più moduli caricabili associati per architettura, per versione LTS (attualmente solo arm64 per android11-5.4 E android12-5.4).
• È stato testato con tutte le versioni della piattaforma Android supportate per l'ACK associato. Non è prevista alcuna deprecazione delle funzionalità per tutta la durata di una versione del kernel GKI
• Espone un KMI stabile ai conducenti all'interno di un dato LTS.
• Non contiene SoC o codice specifico della scheda.

Google vuole addirittura essere in una posizione entro il 2023 in cui può adottare un modello di sviluppo “upstream first”. Ciò aiuterà Google a garantire che il nuovo codice arrivi prima nel kernel Linux principale, riducendo il "debito tecnico" accumulato sul codice fuori albero sui dispositivi Android.

L'interfaccia del modulo kernel (KMI)

La Kernel Module Interface, o KMI, fa parte della soluzione di Google alla frammentazione in corso in Android. In sostanza, il SoC e il supporto della scheda non si trovano più nel core del kernel e vengono invece spostati in moduli caricabili. Sia il kernel che i moduli possono quindi essere aggiornati indipendentemente, poiché i moduli vengono aggiornati in /lib/modules. La stessa GKI dovrebbe essere il più pulita e generica possibile, il che è reso possibile scaricando quello che ora è il codice fuori dall'albero in moduli separati.

Come Ted Kjos spiegato a alla Linux Plumbers Conference di quest'anno, "la grande spinta pluriennale è quella di far uscire tutto il codice specifico dell'hardware dal kernel generico e nei moduli del fornitore. Dobbiamo avere un'interfaccia stabile tra i moduli di questi fornitori e il kernel generico in modo che possano essere distribuiti in modo asincrono." GKI 1.0 è essenzialmente un "test di conformità".

Infatti, la compatibilità GKI significa che il dispositivo supera i test VTS e CTS-on-GSI+GKI con la Generic System Image (GSI) e il kernel GKI installato eseguendo il flashing dell'immagine di avvio GKI nella partizione di avvio e dell'immagine di sistema GSI nel sistema partizione. Il Vendor Test Suite, o VTS, è un test automatizzato che tutti i dispositivi devono superare per essere considerati compatibili con Project Treble. Per accedere alla suite di applicazioni di Google è necessaria la Compatibility Test Suite, o CTS.

I dispositivi possono essere forniti con un kernel del prodotto diverso e possono utilizzare moduli caricabili non forniti da GKI. Tuttavia, sia il prodotto che i kernel GKI devono caricare i moduli dalle stesse partizioni fornitore_boot e fornitore. Pertanto, tutti i kernel del prodotto devono avere la stessa interfaccia binaria del modulo kernel (KMI).

Il diagramma sopra mostra ciò che Google vuole fare e spiega come intende raggiungere tale obiettivo. Il kernel generico e i moduli GKI faranno parte di AOSP e il GKI potrà comunicare con il framework Android e l'Hardware Abstraction Layer (HAL) che un fornitore può implementare. Il codice proprietario specifico che un fornitore desidera nel kernel (ad esempio, i driver della fotocamera) verrà invece inserito in un modulo del fornitore che diventa un'estensione del GKI tramite KMI.

Come GKI può aiutare a risolvere il problema della frammentazione di Android

Google ha lavorato molto per semplificare il processo di sviluppo degli smartphone. Ogni OEM desidera la propria identità di marca e ogni OEM vuole poter possedere i propri dispositivi. A differenza del programma Android One, gli smartphone Android possono essere praticamente quello che vogliono, purché rispettino l'insieme di regole che Google stabilisce per ricevere una licenza GMS. Tuttavia, in passato, Google non ha fatto molto per dominare lo sviluppo di dispositivi Android modifiche come Project Treble, Mainline e ora GKI sono molto più recenti in Android storia.

Ma aiuterà? Dovrebbe andare bene, anche se è probabile che si tratti di un affare pluriennale che porterà frutti visibili più avanti. Ciò si applicherà solo ai dispositivi avviati con Android 12, il che significa che vedremo dispositivi che non dispongono di GKI negli anni a venire. Anche questa è stata una critica al Project Treble quando è stato annunciato, anche se ovviamente tutti i dispositivi lanciati oggi lo supportano. Queste cose richiedono tempo e, mentre Google prende lentamente il sopravvento su Android, il processo di sviluppo viene facilitato per tutti gli OEM in l'ecosistema Android, anche se alcuni di loro preferirebbero mantenere il pieno controllo sul kernel Linux utilizzato su Android smartphone.