Hai mai desiderato provare un aggiornamento senza effettivamente aggiornarlo? DSU in Android 10 è progettato per questo, ma al momento è limitato. La situazione potrebbe cambiare presto.
Il sistema operativo Android e la frammentazione del livello di sicurezza rappresentano un enorme problema per cui Google sta investendo molti sforzi ingegneristici per combatterlo. Negli ultimi due anni, Google ha annunciato due importanti iniziative progettate per accelerare il lancio degli aggiornamenti: Progetto Treble E Linea principale del progetto. Quest'ultimo è stato annunciato solo lo scorso maggio durante Google I/O 2019ed è supportato solo sui dispositivi avviati con Android 10. Il primo, tuttavia, esiste da allora Google I/O 2017, quindi abbiamo visto l'impatto che ha avuto sugli aggiornamenti Android con Android 9 Pie E Androide 10.
Oltre a ridurre la frammentazione, Google vuole anche che Project Treble sia utile per gli sviluppatori di app. Ecco perché l'hanno svelato Aggiornamenti dinamici del sistema
(DSU) in Android 10 per consentire agli sviluppatori di provare una versione barebone di un nuovo aggiornamento del sistema operativo senza sbloccare il bootloader o cancellare i dati. Vedendo il potenziale di DSU, Google non si ferma qui: sta espandendo la sua utilità rendendo possibile l'installazione degli aggiornamenti OTA degli OEM nello stesso modo in cui vengono installati i GSI.È un sacco di gergo, ma immagina che ciò accada in futuro: un OEM rilascia un telefono con Android 10 e avvia un programma beta per Android 11. Sei interessato a provare questa beta per vedere le nuove funzionalità, ma non vuoi rischiare la stabilità del tuo attuale driver quotidiano. Invece di eseguire il flashing dell'aggiornamento beta e poi sperare che sia perfettamente stabile, perché non installarlo temporaneamente tramite il flusso DSU? Se non ti piace, riavvia e la configurazione tornerà alla normalità. Se ti piace, puoi "impegnarti" nell'aggiornamento.
Non so voi, ma questo sarebbe un gradito cambiamento per Android che renderebbe il beta testing più piacevole. Non dovresti più impegnarti per un aggiornamento beta solo per vedere com'è per te. Sono sicuro che molti di voi non vedono l'ora di vedere una beta di Android 10 per il proprio dispositivo, ma potresti non sentirti a tuo agio nell'installarla subito. Con le modifiche apportate alla DSU, ciò non costituirebbe più un problema.
Aggiornamenti dinamici del sistema in Android 10+: cosa sta cambiando
Luca Stefani, amico del Portale XDA e a Sviluppatore riconosciuto, ci ha informato di a nuovo impegno uniti in AOSP intitolato "monta più partizioni DSU quando presenti". Il commit apporta modifiche alla tabella del file system (fstab) e al file init per fare in modo che le partizioni DSU diverse dal sistema, per ora inclusi prodotto e fornitore, possano essere montate durante l'avvio processi.
Attualmente, DSU è progettato per consentire solo l'avvio di un'immagine di sistema generica (GSI), un'immagine di sistema barebone compilata da AOSP, in modo da poter testare le nuove API e altre modifiche nell'ultimo aggiornamento Android. Tuttavia, con questa modifica, DSU accetterà anche immagini di prodotti e fornitori. Il primo contiene app, librerie e altri file specifici del dispositivo, mentre il secondo contiene file binari specifici del dispositivo. Project Treble ha fatto in modo che tu possa avviare un dispositivo utilizzando un'immagine di sistema senza file specifici del dispositivo, quindi ora consentire il caricamento del prodotto e del fornitore non sembra avere molto senso.
Tuttavia, un ingegnere di Google afferma esplicitamente che questa modifica consiste nel "consentire agli OEM di installare pacchetti OTA su /data, quindi utilizzare il flusso 'DSU' per montare product.img, system.img, [e] fornitore.img da /data." Ciò significa che, invece di sovrascrivere l'installazione corrente con il nuovo pacchetto OTA, l'OTA può essere caricato temporaneamente tramite DSU. Dopo aver provato l'aggiornamento OTA, "l'utente può decidere se vuole 'impegnare' quelle immagini su /super oppure no." Quest'ultima parte circa "l'impegno" delle modifiche è ancora in corso, poiché un ingegnere di Google sottolinea che "al momento non abbiamo un piano per realizzare partizioni DSU permanente nel contesto DSU." Afferma poi come ciò potrebbe essere implementato, ma che tale implementazione è "oltre lo scopo" di questo patch corrente.
Ci sono alcuni termini e concetti che dobbiamo spiegare qui perché a Google piace cambiare lo schema di partizione in ogni versione di Android. Per cominciare, consiglio di leggere il mio precedente articolo su Aggiornamenti dinamici del sistema per un'ampia panoramica di come funziona, ma in sintesi, sfrutta il concetto di "partizione dinamica", una vera partizione di archiviazione (chiamata la partizione "super") che viene divisa in partizioni logiche ridimensionabili (inclusi sistema, fornitore, prodotto e system_ext), per installare temporaneamente una GSI. Quando si installa un GSI, DSU crea spazio per il nuovo sistema e le immagini dei dati utente ridimensionando la partizione dei dati utente esistente. Gli elementi costitutivi del supporto DSU (partizioni dinamiche, un ramdisk e checkpoint per i backup dei dati) sono requisiti di avvio per Androide 10, quindi qualsiasi dispositivo avviato con la nuova versione del sistema operativo Android dovrebbe supportare DSU. DSU non è la soluzione dual boot per ROM personalizzate che alcuni di voi stanno cercando, perché possono essere installate solo le immagini che corrispondono alle chiavi Android Verified Boot (AVB). Tuttavia, con questo nuovo cambiamento, potrebbe rivelarsi molto più utile in futuro.
Oltre alle partizioni dinamiche, Google ha introdotto anche il concetto di "A/B virtuale" in Android 10. Questa è fondamentalmente un'implementazione di doppie partizioni A/B da prima, ma con partizioni logiche. Le partizioni A/B implicano copie di partizioni importanti per consentire aggiornamenti continui e sicuri. Usare "A/B virtuale" è il modo in cui un ingegnere di Google immagina di "impegnare" le partizioni DSU sulle partizioni dell'installazione corrente; come con l'attuale processo di aggiornamento A/B OTA, forse le modifiche dalle nuove immagini vengono apportate alla partizione inattiva.
Queste modifiche sono ancora in fase di sviluppo e potrebbe richiedere del tempo prima che vengano utilizzate da Google o dagli OEM. Noi probabilmente non vedremo alcuna implementazione di questo fino a quando, al più presto, non verrà rilasciato Android 11 R anno. Anche così, non vi è alcuna garanzia che gli OEM adottino questa funzionalità per i propri aggiornamenti OTA. Considerando quanto ciò sembri utile per il beta testing, immagino che Google stia già lavorando con gli OEM interessati per abilitare questa funzionalità per futuri aggiornamenti. Personalmente sono entusiasta della prospettiva di provare prima di acquistare nuovi aggiornamenti Android, ma tu?