Aggiornamenti di sistema non A/B

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

stivale
Contiene il kernel Linux e un filesystem root minimo (caricato in un disco RAM). Monta il sistema e altre partizioni e avvia il runtime situato sulla partizione di sistema.
sistema
Contiene applicazioni e librerie di sistema con codice sorgente disponibile su Android Open Source Project (AOSP). Durante il normale funzionamento, questa partizione è montata in sola lettura; i suoi contenuti cambiano solo durante un aggiornamento OTA.
venditore
Contiene applicazioni e librerie di sistema che non dispongono di codice sorgente disponibile su Android Open Source Project (AOSP). Durante il normale funzionamento, questa partizione è montata in sola lettura; i suoi contenuti cambiano solo durante un aggiornamento OTA.
dati utente
Memorizza i dati salvati dalle applicazioni installate dall'utente, ecc. Questa partizione normalmente non viene toccata dal processo di aggiornamento OTA.
cache
Area di conservazione temporanea utilizzata da alcune applicazioni (l'accesso a questa partizione richiede autorizzazioni speciali per l'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 potrebbero comportare la cancellazione completa di questa partizione. La cache contiene anche i registri di aggiornamento da un aggiornamento OTA.
recupero
Contiene un secondo sistema Linux completo, incluso un kernel e lo speciale binario di ripristino che legge un pacchetto e utilizza il suo contenuto per aggiornare le altre partizioni.
mis
Piccola partizione utilizzata dal ripristino per nascondere alcune informazioni su ciò che sta facendo nel caso in cui il dispositivo venga riavviato mentre viene applicato il pacchetto OTA.

Vita di un aggiornamento OTA

Un tipico aggiornamento OTA contiene i seguenti passaggi:

  1. Il dispositivo esegue un check-in regolare con i server OTA e viene informato 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 in una partizione dati e la sua firma crittografica viene verificata rispetto ai certificati in /system/etc/security/otacerts.zip . All'utente viene richiesto 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 binario di ripristino viene avviato da init. Trova gli argomenti della riga di comando in /cache/recovery/command che lo indirizzano al pacchetto scaricato.
  5. Il ripristino verifica la firma crittografica del pacchetto rispetto 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 avvio, sistema e/o fornitore secondo necessità. Uno dei nuovi file rimasti nella partizione di sistema contiene il contenuto della nuova partizione di ripristino.
  7. Il dispositivo si riavvia normalmente.
    1. La partizione di avvio appena aggiornata viene caricata, monta e avvia l'esecuzione dei file binari nella partizione di sistema appena aggiornata.
    2. Come parte del normale avvio, il sistema controlla il contenuto della partizione di ripristino rispetto al contenuto desiderato (che era stato precedentemente archiviato come file in /system ). Sono diversi, quindi la partizione di ripristino viene aggiornata con i contenuti desiderati. (Agli avvii successivi, la partizione di ripristino contiene già i nuovi contenuti, quindi non è necessario eseguire il reflash.)

L'aggiornamento del sistema è completo! I registri degli aggiornamenti possono essere trovati in /cache/recovery/last_log. # .

Aggiorna pacchetti

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

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

Un pacchetto di aggiornamento può utilizzare qualsiasi file binario collegato staticamente come file binario di aggiornamento. Gli strumenti di costruzione 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 binario in esecuzione sul dispositivo.

Per dettagli sul file binario di aggiornamento, sulla sintassi di modifica e sulle funzioni integrate, consulta All'interno dei pacchetti OTA .

Migrazione dalle versioni precedenti

Durante la migrazione dalla versione Android 2.3/3.0/4.0, la modifica principale è la conversione di tutte le funzionalità specifiche del dispositivo da un insieme di funzioni C con nomi predefiniti in oggetti C++. La tabella seguente elenca le vecchie funzioni e i nuovi metodi che hanno uno scopo più o meno equivalente:

Funzione C Metodo C++
dispositivo_recovery_start() Dispositivo::RecoveryStart()
dispositivo_toggle_display()
dispositivo_reboot_now()
 RecoveryUI::CheckKey()
(anche RecoveryUI::IsKeyPressed())
dispositivo_handle_key() Dispositivo::HandleMenuKey()
dispositivo_perform_action() Dispositivo::InvokeMenuItem()
dispositivo_wipe_data() Dispositivo::WipeData()
dispositivo_ui_init() ScreenRecoveryUI::Init()

La conversione di vecchie funzioni in 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.