Aggiornamenti di sistema non A/B

Gli aggiornamenti non AB sono una metodologia OTA deprecata utilizzata dai dispositivi Android meno recenti (Android 6 e versioni precedenti). Questi dispositivi dispongono di una partizione di ripristino dedicata contenente il software necessario per scompattare un pacchetto di aggiornamento scaricato e applicare l'aggiornamento alle altre partizioni.

Sui dispositivi Android meno recenti senza partizioni A/B, lo spazio flash in genere contiene le seguenti partizioni:

avvio

Contiene il kernel Linux e un file system radice minimo (caricato in un disco RAM). Monta il sistema e altre partizioni e avvia il runtime situato nella partizione di sistema.

di infotainment

Contiene applicazioni e librerie di sistema il cui codice sorgente è disponibile nell'Android Open Source Project (AOSP). Durante il normale funzionamento, questa partizione viene montata in sola lettura; i suoi contenuti cambiano solo durante un aggiornamento OTA.

fornitore

Contiene applicazioni e librerie di sistema per le quali non è disponibile il codice sorgente su Android Open Source Project (AOSP). Durante il normale funzionamento, questa partizione viene montata in sola lettura; i relativi contenuti cambiano solo durante un aggiornamento OTA.

userdata

Memorizza i dati salvati dalle applicazioni installate dall'utente e così via. Questa partizione non viene solitamente modificata dalla procedura di aggiornamento OTA.

cache

Spazio di accodamento temporaneo utilizzato da alcune applicazioni (l'accesso a questa partizione richiede autorizzazioni speciali per le app) e per l'archiviazione dei pacchetti di aggiornamento OTA scaricati. Altri programmi utilizzano questo spazio con l'aspettativa che i file possano scomparire in qualsiasi momento. Alcune installazioni di pacchetti OTA possono comportare l'eliminazione completa di questa partizione. La cache contiene anche i log di aggiornamento di un aggiornamento OTA.

recupero

Contiene un secondo sistema Linux completo, incluso un kernel e il codice binario di ripristino speciale che legge un pacchetto e utilizza i relativi contenuti per aggiornare le altre partizioni.

misc

Piccola partizione utilizzata dal recupero per archiviare alcune informazioni sulle operazioni in corso nel caso in cui il dispositivo venga riavviato durante l'applicazione del pacchetto OTA.

Ciclo di vita di un aggiornamento OTA

Un tipico aggiornamento OTA contiene i seguenti passaggi:

1. Il dispositivo esegue un controllo regolare con i server OTA e riceve una notifica della disponibilità di un aggiornamento, incluso l'URL del pacchetto di aggiornamento e una stringa di descrizione da mostrare all'utente.
2. Aggiorna i download in una cache o una partizione di dati e la firma crittografica viene verificata in base ai certificati in /system/etc/security/otacerts.zip. All'utente viene chiesto di installare l'aggiornamento.
3. Il dispositivo si riavvia in modalità di ripristino, in cui vengono avviati il kernel e il sistema nella partizione di ripristino anziché il kernel nella partizione di avvio.
4. Il file binario di ripristino viene avviato da init. Trova gli argomenti della riga di comando in /cache/recovery/command che rimandano al pacchetto scaricato.
5. Il recupero verifica la firma crittografica del pacchetto in base alle chiavi pubbliche in /res/keys (parte del disco RAM contenuto nella partizione di ripristino).
6. I dati vengono estratti dal pacchetto e utilizzati per aggiornare le partizioni di boot, di sistema e/o del fornitore, se necessario. Uno dei nuovi file rimasti nella partizione di sistema contiene i contenuti della nuova partizione di ripristino.
7. Il dispositivo si riavvia normalmente.
   1. La partizione di avvio appena aggiornata viene caricata, montata e inizia a eseguire i binari nella partizione di sistema appena aggiornata.
   2. Durante la normale procedura di avvio, il sistema controlla i contenuti della partizione di ripristino rispetto ai contenuti desiderati (che in precedenza erano memorizzati come file in /system). Se sono diversi, la partizione di ripristino viene riflashata con i contenuti desiderati. (Al riavvio successivo, la partizione di ripristino contiene già i nuovi contenuti, quindi non è necessario eseguire il reflash.)

L'aggiornamento di sistema è stato completato. I log di aggiornamento sono disponibili in /cache/recovery/last_log.#.

Aggiorna i pacchetti

Un pacchetto di aggiornamento è un file .zip contenente il file binario eseguibile META-INF/com/google/android/update-binary. Dopo aver verificato la firma sul pacchetto, recovery estrae questo file binario in /tmp ed esegue il file binario, passando i seguenti argomenti:

• Aggiorna il numero di versione dell'API binaria. Se gli argomenti passati all'aggiornamento cambiano in formato binario, questo numero aumenta.
• Descrittore file della pipe di comando. Il programma di aggiornamento può utilizzare questo pipe per inviare nuovamente i comandi al file binario di ripristino, principalmente per le modifiche all'interfaccia utente, ad esempio per indicare l'avanzamento all'utente.
• Nome del file del pacchetto di aggiornamento .zip.

Un pacchetto di aggiornamento può utilizzare qualsiasi file binario collegato in modo statico come file binario di aggiornamento. Gli strumenti di compilazione del pacchetto OTA utilizzano il programma di aggiornamento (bootable/recovery/updater), che fornisce un semplice linguaggio di scripting in grado di eseguire molte attività di installazione. Puoi sostituire qualsiasi altro file binario in esecuzione sul dispositivo.

Per informazioni dettagliate sul file binario dell'aggiornamento, sulla sintassi di edify e sulle funzioni predefinite, consulta Informazioni sui pacchetti OTA.

Eseguire la migrazione dalle release precedenti

Durante la migrazione dalla release Android 2.3/3.0/4.0, la modifica più importante è la conversione di tutte le funzionalità specifiche del dispositivo da un insieme di funzioni C con nomi predefiniti a oggetti C++. La tabella seguente elenca le vecchie funzioni e i nuovi metodi che hanno una finalità approssimativamente equivalente:

Funzione C	Metodo C++
device_recovery_start()	Device::RecoveryStart()
device_toggle_display() device_reboot_now()	RecoveryUI::CheckKey() (anche RecoveryUI::IsKeyPressed())
device_handle_key()	Device::HandleMenuKey()
device_perform_action()	Device::InvokeMenuItem()
device_wipe_data()	Device::WipeData()
device_ui_init()	ScreenRecoveryUI::Init()

La conversione delle vecchie funzioni nei nuovi metodi dovrebbe essere ragionevolmente semplice. Non dimenticare di aggiungere la nuova funzione make_device() per creare e restituire un'istanza della nuova sottoclasse Device.