Domande frequenti

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Google ha utilizzato OTA A/B su alcuni dispositivi?

Sì. Il nome commerciale degli aggiornamenti A/B è aggiornamenti seamless. Gli smartphone Pixel e Pixel XL da ottobre 2016 sono stati forniti con A/B e tutti i Chromebook utilizzano la stessa update_engine implementazione di A/B. L'implementazione del codice di piattaforma necessaria è pubblica in Android 7.1 e versioni superiori.

Perché le OTA A/B sono migliori?

Le OTA A/B offrono un'esperienza utente migliore durante l'applicazione degli aggiornamenti. Le misurazioni degli aggiornamenti di sicurezza mensili dimostrano che questa funzionalità ha già riscosso un grande successo: a maggio 2017, il 95% dei proprietari di Pixel esegue l'aggiornamento di sicurezza più recente dopo un mese, rispetto all'87% degli utenti di Nexus, e gli utenti di Pixel eseguono l'aggiornamento prima degli utenti di Nexus. Gli errori di aggiornamento dei blocchi durante un aggiornamento OTA non fanno più sì che il dispositivo non si avvii. Fino a quando la nuova immagine di sistema non viene avviata correttamente, Android mantiene la possibilità di eseguire il fallback all'immagine di sistema funzionante precedente.

Che cos'è system_other?

Le applicazioni sono memorizzate in file .apk, che sono in realtà archivi ZIP. Ogni file .apk contiene uno o più file .dex contenenti codice bytecode Dalvik portatile. Un file .odex (.dex ottimizzato) è separato dal file .apk e può contenere codice macchina specifico per il dispositivo. Se è disponibile un file .odex, Android può eseguire le applicazioni alle velocità di compilazione anticipata senza dover attendere la compilazione del codice ogni volta che viene lanciata l'applicazione. Un file .odex non è strettamente necessario: Android può eseguire il codice .dex direttamente tramite interpretazione o compilazione Just-In-Time (JIT), ma un file .odex offre la migliore combinazione di velocità di avvio e di esecuzione se lo spazio è disponibile.

Esempio: per il file installed-files.txt di un Nexus 6P con Android 7.1 e dimensioni totali dell'immagine di sistema di 2628 MiB (2755792836 byte), la suddivisione dei maggiori fattori di contributo alle dimensioni complessive dell'immagine di sistema per tipo di file è la seguente:

.odex	1391770312 byte	50,5%
.apk	846878259 byte	30,7%
.so (codice C/C++ nativo)	202162479 byte	7,3%
File .oat/immagini .art	163892188 byte	5,9%
Caratteri	38952361 byte	1,4%
Dati sulle impostazioni internazionali icu	27468687 byte	0,9%

Questi valori sono simili anche per altri dispositivi, quindi sui dispositivi Nexus/Pixel i file .odex occupano circa la metà della partizione di sistema. Ciò significa che potremmo continuare a utilizzare ext4, ma scrivere i file .odex nella partizione B in fabbrica e poi copiarli in /data al primo avvio. Lo spazio di archiviazione effettivo utilizzato con ext4 A/B è identico a quello di SquashFS A/B, perché se avessero usato SquashFS, avremmo caricato i file .odex preattivati su system_a anziché su system_b.

La copia dei file .odex in /data non significa che lo spazio risparmiato in /system viene perso in /data?

Non esattamente. Su Pixel, la maggior parte dello spazio occupato dai file .odex è destinato alle app, che in genere esistono su /data. Queste app ricevono gli aggiornamenti di Google Play, pertanto i file .apk e .odex nell'immagine di sistema non vengono utilizzati per la maggior parte del ciclo di vita del dispositivo. Questi file possono essere esclusi del tutto e sostituiti da piccoli file .odex basati su profilo quando l'utente utilizza effettivamente ogni app (quindi non richiedono spazio per le app che l'utente non utilizza). Per maggiori dettagli, consulta l'intervento L'evoluzione dell'arte tenuto alla conferenza Google I/O 2016.

Il confronto è difficile per alcuni motivi chiave:

• I file .odex delle app aggiornate da Google Play sono sempre stati su /data non appena hanno ricevuto il primo aggiornamento.
• Le app che l'utente non esegue non richiedono affatto un file .odex.
• La compilazione basata su profilo genera file .odex più piccoli rispetto alla compilazione anticipata (in quanto la prima ottimizza solo il codice critico per le prestazioni).

Per informazioni dettagliate sulle opzioni di ottimizzazione disponibili per gli OEM, consulta Configurazione di ART.

Non ci sono due copie dei file .odex in /data?

È un po' più complicato… Dopo aver scritto la nuova immagine di sistema, la nuova versione di dex2oat viene eseguita sui nuovi file .dex per generare i nuovi file .odex. Questo accade mentre il vecchio sistema è ancora in esecuzione, quindi i file .odex vecchi e nuovi sono contemporaneamente su /data.

Il codice in OtaDexoptService (frameworks/base/+/main/services/core/java/com/android/server/pm/OtaDexoptService.java) chiama getAvailableSpace prima di ottimizzare ogni pacchetto per evitare un riempimento eccessivo /data. Tieni presente che la quantità di spazio disponibile indicata qui è ancora conservativa: si tratta dello spazio rimanente prima di raggiungere la soglia di spazio ridotto del sistema (misurata sia come percentuale sia come numero di byte). Pertanto, se /data è pieno, non ci saranno due copie di ogni file .odex. Lo stesso codice ha anche un valore BULK_DELETE_THRESHOLD: se il dispositivo si avvicina a riempire lo spazio disponibile (come appena descritto), i file .odex appartenenti alle app non utilizzate vengono rimossi. Si tratta di un altro caso in cui non sono presenti due copie di ogni file .odex.

Nel peggiore dei casi, quando /data è completamente pieno, l'aggiornamento attende che il dispositivo sia riavviato nel nuovo sistema e non abbia più bisogno dei file .odex del vecchio sistema. Il PackageManager gestisce questo: (frameworks/base/+/main/services/core/java/com/android/server/pm/PackageManagerService.java#7215). Dopo l'avvio del nuovo sistema, installd (frameworks/native/+/main/cmds/installd/dexopt.cpp#2422) può rimuovere i file .odex utilizzati dal vecchio sistema, riportando il dispositivo allo stato stabile in cui è presente una sola copia.

Pertanto, anche se è possibile che /data contenga due copie di tutti i file .odex, (a) si tratta di un problema temporaneo e (b) si verifica solo se hai comunque molto spazio libero su /data. Tranne durante un aggiornamento, esiste una sola copia. Inoltre, nell'ambito delle funzionalità di robustezza generale di ART, non riempirà mai /data con file .odex (perché sarebbe un problema anche in un sistema non A/B).

Tutta questa scrittura/copia non aumenta l'usura del flash?

Viene riscritta solo una piccola parte del flash: un aggiornamento di sistema completo di Pixel scrive circa 2,3 GB. Anche le app vengono ricompilate, ma questo vale anche per i test non A/B. Tradizionalmente, le OTA complete basate su blocchi scrivevano una quantità simile di dati, pertanto i tassi di usura del flash dovrebbero essere simili.

Il flashing di due partizioni di sistema aumenta il tempo di flashing di fabbrica?

No. Le dimensioni dell'immagine di sistema di Pixel non sono aumentate (è stato semplicemente diviso lo spazio in due partizioni).

Il mantenimento dei file .odex su B non rallenta il riavvio dopo il ripristino dei dati di fabbrica?

Sì. Se hai effettivamente utilizzato un dispositivo, hai eseguito un aggiornamento OTA ed eseguito un ripristino dei dati di fabbrica, il primo riavvio sarà più lento del solito (1 minuto e 40 secondi contro 40 secondi su Pixel XL) perché i file .odex saranno stati persi da B dopo il primo OTA e quindi non possono essere copiati su /data. Questo è il compromesso.

Il ripristino dei dati di fabbrica dovrebbe essere un'operazione rara rispetto all'avvio normale, pertanto il tempo impiegato è meno importante. Ciò non influisce sugli utenti o sui recensori che ricevono il dispositivo dalla fabbrica, poiché in questo caso la partizione B è disponibile. L'utilizzo del compilatore JIT significa che non è necessario ricompilare tutto, quindi non è così grave come potresti pensare. È anche possibile contrassegnare le app come che richiedono la compilazione anticipata utilizzando coreApp="true" nel file manifest: (frameworks/base/+/main/packages/SystemUI/AndroidManifest.xml#23). Questo valore è attualmente utilizzato da system_server perché non è consentito il JIT per motivi di sicurezza.

Non rallenta il riavvio dopo un aggiornamento OTA se i file .odex vengono conservati in /data anziché in /system?

No. Come spiegato sopra, il nuovo dex2oat viene eseguito mentre la vecchia immagine di sistema è ancora in esecuzione per generare i file necessari al nuovo sistema. L'aggiornamento non è considerato disponibile finché non viene completato il lavoro.

Possiamo (dobbiamo) spedire un dispositivo A/B da 32 GB? 16 GB? 8 GB?

32 GB funzionano bene, come è stato dimostrato su Pixel, e 320 MB su 16 GB significano una riduzione del 2%. Analogamente, 320 MB su 8 GB corrispondono a una riduzione del 4%. Ovviamente, la scelta A/B non è consigliata su dispositivi con 4 GB, poiché l'overhead di 320 MB corrisponde quasi al 10% dello spazio totale disponibile.

AVB2.0 richiede OTA A/B?

No. Avvio verificato di Android ha sempre richiesto aggiornamenti basati su blocchi, ma non necessariamente aggiornamenti A/B.

Gli OTA A/B richiedono AVB2.0?

di serie

Gli OTA A/B compromettono la protezione rollback di AVB2.0?

No. C'è un po' di confusione perché se un sistema A/B non riesce ad avviarsi nell'immagine di sistema nuova, dopo un certo numero di tentativi determinati dal bootloader, tornerà automaticamente all'immagine di sistema "precedente". Il punto chiave, però, è che "precedente" nel senso A/B è in realtà ancora l'immagine di sistema "attuale". Non appena il dispositivo avvia correttamente una nuova immagine, viene attivata la protezione del rollback che impedisce di tornare indietro. Tuttavia, finché non hai effettivamente avviato la nuova immagine, la protezione del rollback non la considera l'immagine di sistema corrente.

Se stai installando un aggiornamento mentre il sistema è in esecuzione, non è lento?

Con gli aggiornamenti non A/B, l'obiettivo è installare l'aggiornamento il più rapidamente possibile perché l'utente è in attesa e non può utilizzare il dispositivo durante l'applicazione dell'aggiornamento. Con gli aggiornamenti A/B, accade il contrario: poiché l'utente sta ancora utilizzando il dispositivo, l'obiettivo è avere il minor impatto possibile, pertanto l'aggiornamento è volutamente lento. Tramite la logica nel client di aggiornamento del sistema Java (che per Google è GmsCore, il pacchetto di base fornito da GMS), Android tenta anche di scegliere un momento in cui gli utenti non utilizzano affatto i propri dispositivi. La piattaforma supporta la messa in pausa/la ripresa dell'aggiornamento e il client può utilizzarla per mettere in pausa l'aggiornamento se l'utente inizia a utilizzare il dispositivo e riprenderlo quando il dispositivo è di nuovo inattivo.

Esistono due fasi durante l'esecuzione di un OTA, mostrate chiaramente nell'interfaccia utente come Passaggio 1 di 2 e Passaggio 2 di 2 sotto la barra di avanzamento. Il passaggio 1 corrisponde alla scrittura dei blocchi di dati, mentre il passaggio 2 è la precompilazione dei file .dex. Queste due fasi sono molto diverse in termini di impatto sul rendimento. La prima fase è di semplice I/O. Ciò richiede poche risorse (RAM, CPU, I/O) perché si tratta solo di copiare lentamente i blocchi.

La seconda fase esegue dex2oat per precompilare la nuova immagine di sistema. Ovviamente, i suoi requisiti sono meno chiari perché compila app reali. Inoltre, la compilazione di un'app grande e complessa richiede ovviamente molto più lavoro rispetto a un'app piccola e semplice. Al contrario, nella fase 1 non esistono blocchi di disco più grandi o più complessi di altri.

La procedura è simile a quella che viene eseguita quando Google Play installa un aggiornamento dell'app in background prima di mostrare la notifica 5 app aggiornate, come avviene da anni.

E se un utente è in attesa dell'aggiornamento?

L'attuale implementazione in GmsCore non distingue tra aggiornamenti in background e aggiornamenti avviati dall'utente, ma potrebbe farlo in futuro. Se l'utente ha esplicitamente richiesto l'installazione dell'aggiornamento o sta guardando la schermata di avanzamento dell'aggiornamento, daremo la priorità al lavoro di aggiornamento presupponendo che l'utente stia attivamente aspettando il completamento.

Che cosa succede se non è possibile applicare un aggiornamento?

Con gli aggiornamenti non A/B, se l'applicazione di un aggiornamento non andava a buon fine, l'utente rimaneva solitamente con un dispositivo inutilizzabile. L'unica eccezione è se l'errore si è verificato prima dell'avvio di un'applicazione (ad esempio perché la verifica del pacchetto non è riuscita). Con gli aggiornamenti A/B, la mancata applicazione di un aggiornamento non influisce sul sistema attualmente in esecuzione. L'aggiornamento può essere riprovato in un secondo momento.