Google prepara la prossima mossa contro la frammentazione di Android

Leggere le parole “frammentazione” e “Android” nella stessa frase fa inevitabilmente pensare alla tabella di distribuzione delle versioni di Android (che sul sito dedicato agli sviluppatori non viene più aggiornata da Google, ma risulta accessibile quando si utilizza la funzione Create New Project in Android Studio), ma adesso Google starebbe approntando la prossima mossa da mettere in campo per contrastare questo problema.

La causa della frammentazione di Android

Quando si affronta il discorso relativo alla frammentazione del sistema operativo Android viene spesso portato l’impietoso paragone con la situazione di iOS, sebbene tra i due maggiori sistemi operativi mobile corra una differenza sostanziale e ineliminabile: da una parte c’è un esiguo numero di modelli tutti facenti capo allo stesso produttore, Apple; dall’altra il numero dei dispositivi Android, riconducibili a tanti produttori diversi ognuno con la propria personalizzazione, cresce praticamente di giorno in giorno.

Ci sono diversi fattori che vengono citati nel tentativo di individuare le cause del problema della lentezza con la quale gli aggiornamenti delle versioni di Android vengono distribuiti, ma la realtà dei fatti è che, ora come ora, Google non può fare tantissimo per costringere i vari OEM a sviluppare e rilasciare più rapidamente gli aggiornamenti.

L’aspetto sul quale Big G può invece intervenire è quello della riduzione dei tempi di sviluppo e quindi dello sforzo necessario per il roll out degli aggiornamenti.

Che cos’ha fatto Google finora: Project Treble e Mainline

Arrivati a questo punto potreste chiedervi quali iniziative Google abbia messo in campo fino a questo momento contro la frammentazione di Android.

Ebbene, la prima importante iniziativa del progetto a lungo termine di Google per facilitare lo sviluppo è Project Treble. Annunciato nel 2017 al fianco di Android 8.0 Oreo, Project Treble aveva avuto il pregio di conferire una certa modularità ad Android separando il framework dell’OS dall’implementazione del vendor (HALs e fork del kernel Linux specifici per determinati device). Ciò aveva facilitato gli OEM Android permettendo loro di basare i rispettivi OS sull’ultimo framework AOSP senza bisogno di codice aggiornato dai vendor. Project Treble aveva così consentito agli OEM di sviluppare più rapidamente i propri fork di Android e di rilasciare aggiornamenti più velocemente.

Fast Forward di due anni e arriviamo al 2019: al fianco di Android 10 (allora ancora Android Q), viene annunciato Project Mainline, con cui Google rafforza il proprio controllo su elementi chiave del sistema operativo e vieta agli OEM di modificarli. Dal punto di vista pratico, questo nuovo project porta un’altra enorme novità: gli aggiornamenti di questi elementi vengono fatti passare da remoto tramite Google Play, accorciando i tempi di rilascio e togliendo un impegno agli OEM. Project Mainline ha segnato una svolta per l’aggiornamento di alcuni elementi importanti del sistema operativo, migliorando in un colpo solo la sicurezza dell’intero ecosistema Android.

E adesso?

Quella che sta per arrivare è forse la parte più importante della strategia a lungo termine di Google. Nel descrivere Project Treble si era parlato di modularità, includendo nel codice del vendor anche “fork del kernel Linux specifici per determinati device“. Ebbene qui risiede un problema che Google deve affrontare: i device Android usano kernel Linux, ma in realtà impiegano molto codice out-of-tree.

Come sottolineato dall’ingegnere software di Google Todd Kjos alla Linux Plumbers Conference, il kernel Linux viene forked più volte prima di arrivare su un dispositivo Android: si parte da Google, col ramo “Android Common Kernel” che aggiunge solo patch specifiche per Android; questo kernel arriva poi nelle mani dei SoC vendor (Qualcomm, Samsung, MediaTek, etc.), che realizzano un fork per ognuno dei propri SoC; infine, al kernel specifico per il SoC scelto gli OEM aggiungono patch per l’hardware specifico che intendono usare.

Secondo Google, «fino al 50% del codice operante su un device è out-of-tree (non provenente dal kernel upstream Linux o comune AOSP)». Questo rappresenta un rischio anche sul piano della sicurezza, visto che rallenta e aggrava il lavoro degli OEM per rilasciare le patch di sicurezza scoperte nel kernel Linux. Inoltre, tanti dispositivi Android rimangono fermi a release del kernel vecchie di anni, non beneficiando neppure di nuove funzioni introdotte nel frattempo.

L’inefficienza e la problematicità di un meccanismo del genere sono macroscopiche e la soluzione a cui Google sta lavorando è molto promettente: una Android Generic Kernel Image (GKI), ovvero un kernel compilato direttamente dal ramo ACK. La GKI isola le personalizzazioni di SoC vendor e OEM sotto forma di moduli plugin, eliminando il codice out-of-tree e permettendo a Google di occuparsi direttamente di rilasciare gli aggiornamenti del kernel agli utenti finali. Per oltre un anno, Google ha lavorato per far passare gli aggiornamenti GKI dal Play Store, usando un modulo di Mainline.

Secondo alcune fonti, la svolta è più vicina che mai: i device lanciati con Android 12 e kernel Linux 5.10 dovranno avere per forza una boot image firmata da Google. I Google Pixel 6 e Google Pixel 6 Pro dovrebbero essere i primi con Android 12 e kernel Linux 5.10 out-of-the-box e, quindi, i primi ad arrivare nelle tasche degli utenti con una GKI (Generic Kernel Image).

Todd Kjos ha poi rivelato il piano di Google di passare ad un modello di sviluppo “upstream first” per le nuove versioni del kernel Linux, per ridurre drasticamente il codice out-of-tree presente sui dispositivi Android. Ecco quanto dichiarato: «Dal momento che i moduli out-of-tree sono molto importanti per il nostro use case, ci aspettiamo di avere sempre un insieme di export e cose diverse o in aggiunta a quelle upstream, ma tutto questo progetto pluriennale tende a sbarazzarsi del maggior numero possibile di patch out-of-tree e ad allinearsi il più possibile all’upstream». Per quanto riguarda le tempistiche, Google intende rendere upstream le feature esistenti e isolare i cambiamenti dei vendor entro la fine del 2022 e adottare il modello di sviluppo “upstream first” a partire dal 2023.