Aggiornamenti dinamici del sistema in Android Q: in che modo Project Treble migliorerà le future versioni di Android

Oltre al rilascio di Android 8.0 Oreo, Google ha presentato Progetto Treble: un'importante riprogettazione del modo in cui comunicano il framework del sistema operativo Android, gli HAL del fornitore e il kernel Linux. Treble è un'importante iniziativa progettata per ridurre la versione della piattaforma Android e frammentazione delle patch di sicurezzae tutti i dispositivi con marchio Android che vengono avviati con Android Pie devono supportare Project Treble. OEM e fornitori testano la compatibilità di Treble avviando un'immagine di sistema generica (GSI), una build stock pura di Android di AOSP, e superando il test Suite di test del fornitore (VTS) e Compatibility Test Suite su immagine di sistema generica (CTS-on-GSI). Il GSI si è dimostrato utile non solo consentendo agli ingegneri del software che lavorano per gli OEM di testare la compatibilità degli alti, ma ha anche aperto la porta a un

ampia comunità di ROM personalizzate su XDA. Per la versione di Android Q, Google vuole rendere i GSI utili per un altro gruppo: gli sviluppatori di app.

Di solito arriva la prima versione stabile e il rilascio del codice sorgente di una determinata piattaforma Android in agosto, gli sviluppatori che desiderano testare la prossima versione di Android su un dispositivo reale in genere hanno bisogno dell'accesso a uno smartphone Google se non vogliono aspettare che l'aggiornamento raggiunga il proprio hardware. Tuttavia, Google ha collaborato con gli OEM per portare un Android P beta su diversi dispositivi l'anno scorso e quest'anno hanno proseguito con un Android Q beta. Oltre a una beta ufficiale di Android Q, Google quest'anno ha rilasciato anche una versione beta Q beta GSI ufficiale quindi qualsiasi sviluppatore con un dispositivo compatibile con Project Treble può installare l'ultima versione di Q senza dover attendere mesi affinché la build raggiunga i propri dispositivi. Questo nuovo modo di testare la prossima versione di Android offre agli sviluppatori più opportunità, e quindi più tempo, per testare le proprie app importanti cambiamenti in Android.

Sfortunatamente, l'attuale metodo di installazione di un GSI può essere difficile. Richiede lo sblocco del bootloader, il che significa cancellare tutti i dati dell'utente e/o invalidare la garanzia, e flashare un'immagine tramite il protocollo fastboot. Non è un processo rapido e semplice da eseguire per uno sviluppatore di app, se il suo dispositivo consente anche di sbloccare il bootloader. Ecco perché, per il ultimi mesi, Google ha lavorato su un nuovo modo di avviare GSI. Inserisci una nuova funzionalità chiamata Dynamic System Update o DSU.

(Questa funzionalità è stata precedentemente sviluppata con i nomi "Live Image", "Dynamic Android" e "Android on Tap", quindi non sorprenderti se Google la chiamerà qualcos'altro tra poche settimane o mesi.)

Aggiornamenti di sistema dinamici in Android Q

L'obiettivo della funzionalità DSU è consentire a uno sviluppatore di eseguire l'avvio in un GSI senza interferire con l'installazione corrente. Ciò significa che non è necessario sbloccare il bootloader e cancellare i dati dell'utente. Anche il processo di installazione è notevolmente semplificato poiché Google ha fornito un'interfaccia a riga di comando tramite ADB e un'app che può essere controllata tramite intent. Ecco come appare l'avvio di un GSI utilizzando DSU:

In questo video*, un Google Pixel 3 XL con Android Q beta 3 si riavvia in un GSI. In questo ambiente, uno sviluppatore di app può installare e testare la compatibilità della propria app con l'API Q. Una volta terminati i test, possono semplicemente riavviarsi nel normale software Q beta 3 sul dispositivo. In pratica stai eseguendo il dual boot di un GSI in modo da poter testare in sicurezza la tua app!

*Abbiamo registrato questo video al Google I/O 2019 quando DSU non era ancora disponibile pubblicamente, quindi la build Q beta 3 sul Pixel 3 XL filmato è stata leggermente modificata da Google per includere il supporto DSU. I dispositivi che eseguono Q beta 4 e versioni successive sono idonei a supportare DSU se soddisfano i requisiti riportati di seguito.

Requisiti per gli aggiornamenti di sistema dinamici

Ottenere quello che è essenzialmente un dual boot attivo e funzionante non è stato un compito facile per Google. È stato necessario apportare importanti modifiche al modo in cui vengono gestite le partizioni su Pixel 3, il banco di prova di Google per DSU. Pertanto, il primo requisito importante per il supporto DSU è che il dispositivo supporti partizioni dinamiche. Le partizioni dinamiche implicano una partizione reale di archiviazione divisa in partizioni logiche ridimensionabili come sistema, fornitore, odm, oem, prodotto, ecc. Durante l'installazione di un GSI, lo spazio viene riservato per le nuove partizioni di sistema e di dati utente prelevando i blocchi inutilizzati dalla partizione di dati utente esistente. Poiché queste nuove partizioni possono avere dimensioni di diversi gigabyte, il supporto DSU ha senso solo dal punto di vista logico partizioni altrimenti un dispositivo dovrebbe riservare in modo permanente diversi gigabyte di spazio di archiviazione per GSI installazioni.

Altri requisiti includono un ramdisk, che decide se avviare il ripristino, il sistema o una partizione logica, e una partizione di metadati per archiviare i metadati del GSI. In generale, gli elementi costitutivi del supporto DSU sono i requisiti di lancio di Android Q, secondo il capo del Project Treble Iliyan Malchev. Non siamo sicuri se qualunque cosa necessario per supportare DSU è un requisito di lancio di Android Q, ma possiamo presumere che la maggior parte, se non tutti, i dispositivi si avviano con Android Q Potere supportano DSU anche se Google attualmente non lo richiede. Finora, solo Pixel 3, Pixel 3 XL, Pixel 3a e Pixel 3a XL hanno partizioni dinamiche e di questi dispositivi solo Pixel 3 e Pixel 3 XL supportano DSU in Android Q beta 4. Sebbene il supporto DSU non sia richiesto, Google spera che gli OEM abilitino comunque la funzionalità perché semplifica i test sicuri per la compatibilità Treble. Ad esempio, un ingegnere del software OEM può inserire un GSI su una scheda SD in modo che possano avviarsi rapidamente su più dispositivi per testare la compatibilità Treble.

Sicurezza per gli aggiornamenti dinamici del sistema

Poiché DSU introduce essenzialmente un secondo sistema operativo nel mix, Google deve assicurarsi che questa nuova installazione non possa essere manomessa per compromettere l'integrità del dispositivo. Quindi, il per l'installazione GSI sono presenti le stesse protezioni di sicurezza di base dell'installazione originale: Criteri di avvio verificato per Android e SELinux. Inoltre, solo le app con firma INSTALL_DYNAMIC_SYSTEM|autorizzazione privilegiata possono avviare un GSI installazione, mentre le app con l'autorizzazione della firma MANAGE_DYNAMIC_SYSTEM possono abilitare/disabilitare o cancellare un GSI installazione. Ciò significa che solo le app affidabili a livello di sistema possono funzionare con DSU.

Per garantire che i dati dell'utente originale siano protetti, Google ha aggiunto un file meccanismo di protezione aggiuntiva in Android Q. Chiamato "Punto di controllo," la funzionalità protegge dalla distruzione dei dati utente ripristinando le partizioni checkpoint al loro stato originale. Tuttavia, i checkpoint sono utili non solo per DSU. Sono anche usati per proteggersi dai pasticci Linea principale del progetto Modulo APEX e A/B Aggiornamenti dell'OTA. (Dispositivi con partizioni A/B dispongono già di protezione rollback, ma tali rollback richiedono il ripristino dei dati di fabbrica mentre i checkpoint dei dati utente no.)

Installazione di un GSI

Se il tuo dispositivo supporta DSU come la serie Pixel 3, è facile installare un GSI. Devi prima assicurarti che il flag della funzione Sistema dinamico sia abilitato in uno dei due modi seguenti:

1. Se utilizzi una build userdebug, abilita il flag settings_dynamic_android in Impostazioni > Sistema > Opzioni sviluppatore > Flag funzionalità.
2. Se utilizzi una build utente, esegui il seguente comando adb shell:

   setproppersist.sys.fflag.override.settings_dynamic_system 1

Quindi, scarica l'ultima versione beta GSI di Android Q da Google o l'OEM del tuo dispositivo. (DSU consente solo l'installazione di GSI firmati da Google o da un OEM.) Una volta scaricato, utilizzare simg2img per convertire l'immagine sparsa in un'immagine grezza. Utilizza gzip per comprimere l'immagine grezza, quindi copia l'archivio risultante in una posizione sul tuo dispositivo memoria esterna (ad esempio /data/media/0/Download) o un vero e proprio supporto di memorizzazione esterno (come una scheda SD fisica carta). Infine, avvia l'app DynamicSystemInstallationService con il giusto intento di iniziare l'installazione:

adb shell am start-activity \ -n com.android.dynsystem/com.android.dynsystem.VerificationActivity \ -a android.os.image.action.START_INSTALL \ -d file:///storage/emulated/0/Download/system_raw.gz \ --el KEY_SYSTEM_SIZE $(du -b system_raw.img|cut -f1) \ --el KEY_USERDATA_SIZE 8589934592

Dopo aver fatto clic su Riavvia, verrà avviato GSI. L'usabilità del dispositivo nel GSI dipende da quanto bene l'OEM del tuo dispositivo ha implementato Treble (o meglio, quanto poco hanno violato Treble compatibilità.) Alcuni dispositivi funzioneranno meglio con GSI rispetto ad altri, ma in generale non aspettarti di utilizzare questa installazione quotidianamente autista. Dovresti testare la tua app e poi uscire riavviando. Se si desidera rimanere nell'installazione GSI per ulteriori test, è possibile utilizzare il file gsi_tool comando di shell.

È possibile trovare le istruzioni complete di installazione GSI per DSU Qui. I bug possono essere segnalati sul file Monitoraggio dei problemi di Google,Reddit, O Overflow dello stack.

Il motivo dietro gli aggiornamenti dinamici del sistema

Quando ho parlato con Iliyan Malchev al Google I/O, ha ribadito ciò che ha detto Hung-ying Tyan del team Treble sull'accesso anticipato a GSI su Android Dev Summit di novembre. Google ha creato DSU per sollecitare il feedback da un pubblico quanto più ampio possibile. L'obiettivo è migliorare la qualità del GSI, che a sua volta migliora la qualità della futura versione di Android poiché un GSI è la forma più pura di Android. Google è attualmente l'unica azienda che testa la compatibilità GSI della prossima versione (ad esempio, il funzionamento dell'immagine del sistema Android Q su Android P). implementazione del fornitore), ma man mano che sempre più persone eseguono il flashing dei GSI e forniscono feedback, gli OEM possono correggere le violazioni della compatibilità Treble in modo che i GSI funzionino ancora meglio nel futuro. Iliyan afferma che c'è un forte interesse da parte di OEM e fornitori come Qualcomm nel riutilizzare le immagini dei fornitori della versione precedente di Android con l'immagine del sistema della versione successiva. Iniziative come DSU aiutano Google e gli OEM a colmare il divario nella copertura dei test automatizzati come VTS e CTS-on-GSI. Pertanto, Google ottiene più beta tester per fornire feedback sulla prossima versione di Android, ascoltando anche le violazioni della compatibilità Treble in modo che gli OEM possano migliorare il loro lavoro.

L'aggiunta degli aggiornamenti di sistema dinamici in Android Q è benvenuta, ma non sarà la soluzione dual boot che alcuni di voi sperano. Come accennato in precedenza, è possibile installare solo le immagini di sistema firmate da Google o dagli OEM. Quando ho chiesto a Iliyan della possibilità di estendere DSU per supportare un ecosistema Android alternativo sistemi, ha affermato che è tecnicamente possibile farlo poiché DSU è semplicemente un canale per fornire il sistema immagini. Qualsiasi OEM può utilizzarlo come preferisce purché il risultato finale sia compatibile con Android. Google non ha creato un'alternativa al sistema OTA in questo caso e DSU non è destinato ad essere utilizzato per un vero dual boot. Indipendentemente da ciò, il lavoro svolto da Google su Treble sta rendendo Android più modulare, quindi non sarei sorpreso se il dual boot nativo diventasse realtà in futuro.