Aggiornamenti di sistema non A/B

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

avvio

Contiene il kernel Linux e un filesystem root minimo (caricato in un disco RAM). Monta il sistema e altre partizioni e avvia il runtime che si trova 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 viene 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 viene 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 attesa temporanea utilizzata da alcune applicazioni (l'accesso a questa partizione richiede autorizzazioni app speciali) 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 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 ne usa il contenuto per aggiornare le altre partizioni.

misc

Minuscola partizione utilizzata dal ripristino per riporre alcune informazioni su ciò che sta facendo nel caso in cui il dispositivo venga riavviato mentre viene applicato il pacchetto OTA.

Durata di un aggiornamento OTA

Un tipico aggiornamento OTA contiene i seguenti passaggi:

1. Il dispositivo esegue il 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. L'aggiornamento viene scaricato 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 il kernel e il sistema nella partizione di ripristino vengono avviati 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, di sistema e/o del fornitore, se necessario. Uno dei nuovi file rimasti sulla 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, viene montata e avvia l'esecuzione dei 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 precedentemente archiviato come file in /system ). Sono diversi, quindi la partizione di ripristino viene ripristinata con il contenuto desiderato. (Agli avvii successivi, la partizione di ripristino contiene già il nuovo contenuto, quindi non è necessario il reflash.)

L'aggiornamento del sistema è completo! I log di aggiornamento possono essere trovati in /cache/recovery/last_log. # .

Aggiorna pacchetti

Un pacchetto di aggiornamento è un file .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 all'aggiornamento binario cambiano, questo numero aumenta.
• Descrittore di file della pipe di comando . Il programma di aggiornamento può utilizzare questa pipe per inviare comandi al file binario di ripristino, principalmente per le modifiche dell'interfaccia utente, ad esempio per indicare lo stato di avanzamento all'utente.
• Nome file del file .zip del pacchetto di aggiornamento .

Un pacchetto di aggiornamento può utilizzare qualsiasi binario collegato staticamente come 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 i dettagli sul binario del programma di aggiornamento, sulla sintassi di edify e sulle funzioni integrate, vedere Inside OTA Packages .

Migrazione da versioni precedenti

Quando si esegue la migrazione da 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:

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 tua nuova sottoclasse Device.