Android 11 verrà fornito con DSU Loader all'interno delle Opzioni sviluppatore che ti consentirà di scaricare e installare automaticamente GSI compatibili! Continua a leggere per saperne di più!
Un buon ecosistema di app è uno dei pilastri più importanti del successo di un sistema operativo. Sia Google che Apple riconoscono il valore di avere buone applicazioni sulle loro piattaforme, quindi entrambe le aziende cercano di bilanciare le esigenze dei loro utenti e dei loro sviluppatori di app. Gli utenti continuano a spingere per i cambiamenti nei sistemi operativi e, sebbene la maggior parte delle persone generalmente apprezzi le nuove funzionalità, queste le modifiche non sono sempre divertenti per gli sviluppatori di app in quanto possono alterare molte delle funzionalità di base e comportamento. Per gli sviluppatori che lavorano costantemente per mantenere le proprie app pertinenti, la gestione di questi cambiamenti si aggiunge alla loro lista di lavoro in crescita. Anche se queste modifiche non influiscono direttamente sulle loro applicazioni, gli sviluppatori devono comunque assicurarsi che le loro app funzionino con il nuovo aggiornamento del sistema operativo. Google ha apportato molte modifiche nel corso degli anni per rendere questo processo più semplice per gli sviluppatori di app Android e ora, una novità funzione di Android 11, chiamata DSU Loader, renderà ancora più semplice per gli sviluppatori di app testare le loro app sul nuovo Android versioni.
Inizia con Project Treble
Project Treble, introdotto in Android 8.0, è un importante riprogettazione del sistema operativo Android. L'obiettivo di Project Treble era dividere il sistema operativo Android in due grandi parti: il framework e l'implementazione del fornitore ("vendor" qui si riferisce al produttore di qualsiasi componente hardware proprietario trovato all'interno di un dispositivo, di solito riferito al silicio). Il framework del sistema operativo Android è il sistema operativo stesso, incluse tutte le app di sistema, l'interfaccia utente e i relativi componenti e le API condivise tra i dispositivi Android. L'implementazione del fornitore contiene gli HAL (Hardware Abstraction Layers) del fornitore e il kernel Linux ei moduli del kernel Linux.
Poiché gli OEM spediscono smartphone con molti componenti hardware diversi di molti fornitori diversi, devono fare molto lavoro solo per far funzionare l'hardware su una singola versione del sistema operativo Android. Quindi, con ogni nuovo aggiornamento del sistema operativo Android, devono fare ancora più lavoro per assicurarsi che il loro hardware funzioni con la nuova versione. Ma con Project Treble che standardizza l'ABI (Application Binary Interface) tra il framework del sistema operativo Android e gli HAL per una particolare versione di Android, Gli OEM Android possono iniziare a testare gli aggiornamenti dei propri dispositivi senza dover attendere che i produttori di silicio e altri produttori di componenti aggiornino il loro lato di il codice. Questo cambiamento è notevolmente accelerato il modo in cui vengono gestiti gli aggiornamenti di Android.
Questo è il succo di ciò che Project Treble ha fatto per gli aggiornamenti di Android, ma ciò che è più importante per l'app sviluppatori qui è che Treble ha abilitato l'uso di immagini di sistema generiche (GSI) per la compatibilità test.
L'emergere di GSI
Affinché gli OEM possano testare se hanno implementato correttamente Project Treble, Google richiede che l'OEM sia in grado di avviare una build pulita di Android da AOSP sul dispositivo. Questa build pulita di Android è chiamata Generic System Image o GSI. Se il GSI si avvia e la maggior parte dell'hardware di base funziona correttamente, l'OEM sa che il proprio dispositivo soddisfa i requisiti di Project Treble. Lo scopo iniziale dei GSI era quindi quello di testare la compatibilità Treble, ma come abbiamo visto con la comunità di sviluppo qui a XDA-Developers, possono essere utilizzati per altri scopi. Abbiamo visto come GSI potrebbe essenzialmente consentire ai dispositivi con UX Android pesanti di godere dell'ultima versione di Android con funzionalità funzionanti entro pochi giorni da una nuova versione. Ma Google prevede un altro scopo alla base del GSI: offrire agli sviluppatori di app la possibilità di testare le proprie app su una nuova versione di Android su un dispositivo fisico che già possiedono.
Con Android 10, Google ha rilasciato le proprie build GSI per gli sviluppatori. Google ha cementato l'idea che gli sviluppatori di app dovrebbero utilizzare un GSI per avviare una build pulita di Android sul proprio hardware, rendendo più semplice testare il comportamento della loro applicazione rispetto ad Android di serie. Questo metodo si è quindi aggiunto alle opzioni esistenti per testare la compatibilità delle app su Android di serie senza modifiche al comportamento OEM, essendo gli altri utilizzando uno smartphone Pixel, utilizzando l'emulatore Android ufficiale all'interno di Android Studio o distribuendo build di app su un'istanza del dispositivo nel cloud.
Nonostante tutta la comodità che i GSI portavano con sé, la loro installazione era ancora un processo ingombrante. Gli sviluppatori di app potrebbero non sentirsi a proprio agio con il flashing manuale di un'immagine di sistema su un dispositivo Android poiché questo è qualcosa che in genere solo gli hobbisti o gli sviluppatori di sistemi operativi Android avranno familiarità. L'installazione di un GSI richiedeva il flashing di un'immagine di sistema su fastboot, che richiede la disabilitazione di Android Verified Boot e lo sblocco del bootloader. Lo sblocco del bootloader, a sua volta, richiede una cancellazione completa dei dati dell'utente. E come tutti sappiamo, non esiste esattamente un singolo processo o guida per sbloccare il bootloader di ogni dispositivo Android là fuori, quindi non c'è coerenza da trovare. Ad esempio, i dispositivi Samsung non hanno fastboot mentre i dispositivi Xiaomi ti fanno saltare alcuni cerchi per sbloccare il bootloader. È un comodo pasticcio che ha il potenziale per essere districato in qualcosa di più semplice.
È qui che entrano in gioco gli aggiornamenti dinamici del sistema.
Aggiornamenti dinamici del sistema semplicemente installando GSI
Google si è reso conto che l'attuale metodo di installazione dei GSI non era una soluzione perfetta, quindi ha iniziato a lavorare su una soluzione migliore. In Android 10, Google ha iniziato a testare gli aggiornamenti dinamici del sistema, o DSU. DSU è un nuovo modo per installare temporaneamente un GSI senza dover utilizzare i comandi fastboot per eseguire il flashing di un'immagine di sistema, sovrascrivendo l'installazione originale. Con DSU, puoi eseguire l'avvio in un GSI, testare la tua app e quindi riavviare comodamente l'installazione originale che è rimasta intatta.
Il motivo per cui DSU può installare un GSI senza toccare l'installazione originale è che crea nuove immagini di partizione dati e di sistema che vengono temporaneamente archiviate in /data/gsi. Queste immagini vengono quindi montate durante l'avvio anziché il sistema originale e le partizioni di dati. Poiché il telefono necessita di ulteriore spazio di archiviazione per queste nuove immagini temporanee, il telefono deve disporre di "partizioni logiche" a bordo, che sono partizioni ridimensionabili dinamicamente. Le partizioni logiche sono un nuovo sistema di partizionamento dello spazio utente per Android, obbligatorio per i dispositivi che si avviano con Android 10. Se il tuo dispositivo è stato avviato con Android 10, dovrebbe supportare l'installazione di GSI tramite DSU.
In Android 10, tutto ciò che devi fare per installare un GSI tramite DSU consiste nel modificare una proprietà di sistema e quindi avviare il file DynamicSystemUpdatesInstallationService inviando un intent con il percorso al GSI come intent extra.
Sebbene questo processo possa sembrare poco familiare, è di gran lunga più semplice e meno invadente rispetto all'utilizzo comandi fastboot e affrontare la seccatura di tutto, inclusa l'installazione originale, essere spazzato. È necessaria una certa conoscenza di ADB e intenti per utilizzare DSU, ma questo non dovrebbe essere un problema per la maggior parte degli sviluppatori di app. Tuttavia, non c'è motivo per cui il processo non possa essere reso ancora più semplice. Inoltre, c'è il fatto che l'installazione di un GSI tramite DSU richiede ancora di sbloccare il bootloader, cancellando tutti i dati utente nel processo. A tal fine, Google ha implementato modifiche per migliorare entrambi gli aspetti dell'installazione di GSI. In Android 11, hanno eliminato la necessità di utilizzare la riga di comando per installare un GSI. Separatamente, hanno anche reso possibile installare un GSI senza sbloccare il bootloader.
Caricatore DSU in Android 11
DSU Loader è un nuovo strumento presente nelle Opzioni sviluppatore di Android 11 che ti consente di farlo scaricamento E installare l'ultimo GSI di Google senza dover inserire alcun comando fastboot o ADB. Basta toccare l'opzione DSU Loader in Impostazioni e verrà visualizzata una finestra di dialogo con un elenco di GSI supportati direttamente da Google. Questi GSI supportati saranno basati sul sistema operativo e sull'architettura correnti, quindi puoi installare solo GSI più recenti della versione del tuo sistema operativo e che corrispondono alla tua architettura SoC. Basta scegliere il GSI che si desidera installare e verrà scaricato dai server di Google e installato automaticamente in background.
Con DSU Loader, gli sviluppatori non devono mai toccare la riga di comando per installare un GSI. Almeno, questo è il sogno, perché c'è ancora un problema da risolvere.
La strada davanti
Attualmente, per installare un GSI tramite DSU Loader, è necessario un bootloader sbloccato. Sebbene ciò possa vanificare lo scopo dell'intero calvario, non dovrebbe essere così e ci viene detto che verrà risolto. Google ha pianificato che gli utenti possano avviare i GSI firmati da Google tramite DSU senza dover sbloccare il bootloader. In effetti, Google lo impone tutti i dispositivi di avvio Android 10 includono le chiavi pubbliche Android Verified Boot di Android 10, Android 11 e Android 12 GSI firmati da Google. L'inclusione delle chiavi pubbliche di AVB nel ramdisk del dispositivo assicurerà che AVB non rifiuterà il GSI che si sta tentando di avviare. Questo è il motivo per cui il metodo attuale prevede lo sblocco del bootloader: eseguendo il flashing di un'immagine vbmeta vuota nella partizione vbmeta, disabiliti AVB in modo che non rifiuti il GSI che stai per eseguire il flashing. La disabilitazione di AVB è un grave rischio per la sicurezza, tuttavia, poiché significa che qualsiasi file modificato la partizione di sistema/avvio/prodotto/fornitore può essere caricata sul dispositivo, motivo per cui Google vuole farlo via con quel requisito.
Quindi, quando puoi aspettarti di avviare un GSI tramite DSU senza dover sbloccare il bootloader o utilizzare strumenti da riga di comando? Si spera presto, poiché Google ci ha detto che avevano alcuni problemi da appianare con le anteprime iniziali degli sviluppatori di Android 11 prima che potessero far funzionare tutto correttamente. Andando avanti, ci si può aspettare di installare futuri GSI Developer Preview tramite DSU senza dover sbloccare il bootloader. Forse quando le anteprime per sviluppatori di Android 12 saranno rese disponibili, sarai persino in grado di avviarlo completamente utilizzando DSU Loader nelle Opzioni sviluppatore di Android 11. Per gli sviluppatori di app, ciò significa che ci sarà ancora un altro modo per testare le tue applicazioni su hardware fisico che esegue una nuova versione di Android.