Come APEX potrebbe essere il prossimo passo evolutivo di Android (Q)

Abbiamo già parlato in passato di APEX, un nuovo modo di "modularizzare" Android per velocizzarne gli aggiornamenti. Oggi vediamo più in dettaglio come questa nuova metodica dovrebbe essere implementata in Android Q, e cosa potrebbe davvero fare.

L'idea alla base di APEX si trova già comunemente implementata in molte distribuzioni GNU/Linux odierne, dove le librerie di sistema possono essere aggiornate singolarmente e direttamente, senza richiedere un intero aggiornamento OTA dell'OS stesso. Su Android invece non è mai stato possibile implementare questa funzione, dato che tutte le librerie di sistema ed i vari framework vengono memorizzati in una partizione di sola lettura (laddove in molte distro Linux vengono invece impiegate partizioni read-write, che permettono appunto l'aggiornamento indipendente).

L'introduzione di APEX, che dovrebbe avvenire con Android Q, permetterà quindi di aggiornare individualmente dette librerie anche su Android, con gli evidenti vantaggi del caso. Questo significa che criticità e nuove funzioni potranno essere rese disponibili in modo più rapido, con vantaggi sia per utenti che sviluppatori, ed al contempo i normali aggiornamenti di sistema saranno più leggeri, perché non dovranno contenere per forza le nuove librerie.

I pacchetti APEX non sono infatti altro che dei file compressi, come del resto lo sono gli APK delle app, che possono essere installati anche via ADB, ma non è escluso (anzi, la strada sarà sicuramente quella) che in futuro basterà il Play Store o il generico installatore di pacchetti di Android (quello che già adesso usiamo quando vogliamo installare un'app manualmente).

A parole sembra tutto facile, ma per rendere possibile ciò sono necessarie profonde modifiche tecniche rispetto a come Android ha funzionato finora. Per il dettaglio più preciso, vi rimandiamo a questo articolo di XDA, che le illustra più in dettaglio. I concetti generali sono comunque quelli che abbiamo espresso finora.

In base a quanto abbiamo già detto, sembra chiaro che APEX sia un modo per velocizzare gli aggiornamenti, o quantomeno per scorporare certe parti del sistema in modo da renderne più autonomo lo sviluppo. Google potrebbe però compiere un passo più in là, ovvero creare un insieme di pacchetti APEX basilari, da condividere con i vari partner, in modo da occuparsi in prima persona dell'aggiornamento di detti pacchetti, che poi dovrebbe arrivare simultaneamente su tutti gli smartphone supportati, senza aspettare l'intervento dei vari OEM (che è da sempre un notevole collo di bottiglia).

Ovviamente stiamo speculando, perché non ci sono prove che le cose andranno proprio così, ma indubbiamente si tratta di una prospettiva interessante, e considerando gli sforzi passati in tal senso (vedi Project Treble) ci sembra anche un'ipotesi ragionevole.

Teoricamente tutti i dispositivi possono supportare APEX, ma ci sono degli impedimenti. Al di là di qualche patch al kernel necessaria al suo funzionamento, il demone di APEX, che /data/apex sia accessibile subito dopo l'avvio, per aggiornare i vari moduli di Android. Peccato però che con la Full-disk Encryption, /data/apex (e altre partizioni) sia crittografata fintanto che il dispositivo non venga sbloccato dall'utente tramite PIN/password/impronta ecc. Questo potrebbe portare ad un ripensamento nel meccanismo con cui viene implementata la crittografia, dato che Google l'ha già impiegata nei suoi stessi Pixel.

In teoria, risolti "i problemi" cui abbiamo accennato, il supporto ad APEX dovrebbe essere fattibile per qualsiasi device. Come andranno davvero le cose però lo scopriremo probabilmente solo con Android Q, la cui prima developer preview dovrebbe essere a poche settimane dal lancio (ma non è detto che basti questa a dipanare il mistero).