Puoi utilizzare lo strumento ota_from_target_files
fornito in build/make/tools/releasetools
per creare pacchetti OTA completi e incrementali per i dispositivi che utilizzano aggiornamenti di sistema A/B o
aggiornamenti di sistema non A/B. Lo strumento prende come input il
target-files.zip
file prodotto dal sistema di compilazione Android.
Per i dispositivi con Android 11 o versioni successive, puoi creare un unico pacchetto OTA per più dispositivi con SKU diversi. Per farlo, è necessario configurare i dispositivi di destinazione in modo che utilizzino le impronte digitali dinamiche e aggiornare i metadati OTA in modo da includere il nome e l'impronta del dispositivo nelle voci di pre e postcondizione.
Android 8.0 ha ritirato i pacchetti OTA basati su file per i dispositivi non A/B, che devono invece utilizzare pacchetti OTA basati su blocchi. Per
generare pacchetti OTA basati su blocchi o dispositivi con sistema operativo Android 7.x o versioni precedenti, passa
l'opzione --block
al parametro ota_from_target_files
.
Crea aggiornamenti completi
Un aggiornamento completo è un pacchetto OTA che contiene l'intero stato finale del dispositivo (partizioni di sistema, di avvio e di ripristino). Se il dispositivo è in grado di ricevere e applicare il pacchetto, può installare la build indipendentemente dallo stato corrente del dispositivo. Ad esempio, i comandi riportati di seguito utilizzano gli strumenti di release per creare l'archivio target-files.zip
per il dispositivo tardis
.
. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output
make dist
crea un pacchetto OTA completo (in $OUT
). Il file .zip
risultante contiene tutto il necessario per creare pacchetti OTA per il dispositivo tardis
.
Puoi anche compilare ota_from_target_files
come file binario Python e chiamarlo per compilare pacchetti completi o incrementali.
ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip
Il percorso ota_from_target_files
è configurato in $PATH
e il file binario Python risultante si trova nella directory out/
.
ota_update.zip
è ora pronto per essere inviato ai dispositivi di test (tutto è firmato con la chiave di test). Per i dispositivi degli utenti, genera e utilizza le tue chiavi private come descritto in Firmare le build per la release.
Crea aggiornamenti incrementali
Un aggiornamento incrementale è un pacchetto OTA che contiene patch binarie per i dati già presenti sul dispositivo. I pacchetti con aggiornamenti incrementali sono in genere più piccoli poiché non devono includere file invariati. Inoltre, poiché i file modificati sono spesso molto simili alle versioni precedenti, il pacchetto deve includere solo una codifica delle differenze tra i due file.
Puoi installare un pacchetto di aggiornamento incrementale solo sui dispositivi che dispongono della compilazione di origine utilizzata per la creazione del pacchetto. Per creare un aggiornamento incrementale,
devi avere il file target_files.zip
della build precedente (quella da cui vuoi
effettuare l'aggiornamento) e il file target_files.zip
della nuova build. Ad esempio, i comandi riportati di seguito utilizzano gli strumenti di release per creare un aggiornamento incrementale per il dispositivo tardis
.
ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip
Questa build è molto simile alla build precedente e il pacchetto di aggiornamento incrementale (incremental_ota_update.zip
) è molto più piccolo dell'aggiornamento completo corrispondente (circa 1 MB anziché 60 MB).
Distribuisci un pacchetto incrementale solo ai dispositivi che eseguono esattamente la stessa compilazione precedente utilizzata come punto di partenza del pacchetto incrementale. Devi eseguire il flashing
delle immagini in PREVIOUS-tardis-target_files.zip
o PREVIOUS-tardis-img.zip
(entrambe create con make dist
, da eseguire con fastboot update
), anziché
quelle nella directory PRODUCT_OUT
(create con make
, che verrà
eseguito con fastboot flashall
). Il tentativo di installare il pacchetto incrementale
su un dispositivo con un'altra build genera un errore di installazione. Se l'installazione non va a buon fine, il dispositivo rimane nello stesso stato di funzionamento (esegue il vecchio sistema). Il pacchetto verifica lo stato precedente di tutti i file che aggiorna prima di toccarli, quindi il dispositivo non rimane bloccato in uno stato di aggiornamento incompleto.
Per un'esperienza utente ottimale, offri un aggiornamento completo ogni 3-4 aggiornamenti incrementali. In questo modo, gli utenti possono aggiornarsi all'ultima release ed evitare una lunga sequenza di installazione di aggiornamenti incrementali.
Creare pacchetti OTA per più SKU
Android 11 o versioni successive supporta l'utilizzo di un singolo pacchetto OTA per più dispositivi con SKU diversi. Per farlo, devi configurare i dispositivi di destinazione in modo che utilizzino impronte dinamiche e aggiornare i metadati OTA (utilizzando gli strumenti OTA) in modo da includere il nome e l'impronta del dispositivo nelle voci delle condizioni pre e post.
Informazioni sugli SKU
Il formato di uno SKU è una variazione dei valori combinati del parametro di compilazione ed è in genere un sottoinsieme non dichiarato dei parametri build_fingerprint
attuali.
Gli OEM possono utilizzare qualsiasi combinazione di parametri di compilazione approvati dal CDD per uno SKU, utilizzando anche una singola immagine per questi SKU. Ad esempio, il seguente SKU ha più varianti:
SKU = <product><device><modifierA><modifierB><modifierC>
modifierA
è il livello del dispositivo (ad es. Pro, Premium o Plus)modifierB
è la variazione hardware (ad esempio la radio)modifierC
è la regione, che può essere generica (ad es. NA, EMEA o CHN) o specifica per paese o lingua (ad es. JPN, ENG o CHN)
Molti OEM utilizzano una singola immagine per più SKU, quindi ricavano il nome del prodotto finale e l'impronta del dispositivo in fase di esecuzione dopo l'avvio del dispositivo. Questa procedura
simplifica il processo di sviluppo della piattaforma, consentendo ai dispositivi con personalizzazioni minime, ma nomi di prodotti diversi, di condividere immagini comuni (ad esempio
tardis
e tardispro
).
Utilizzare impronte dinamiche
Un'impronta è una concatenazione definita di parametri di compilazione come ro.product.brand
, ro.product.name
e ro.product.device
. La fingerprint
di un dispositivo è ricavata dalla fingerprint della partizione di sistema e viene utilizzata come
identificatore univoco delle immagini (e dei byte) in esecuzione sul dispositivo. Per creare un'impronta dinamica, utilizza la logica dinamica nel file build.prop
del dispositivo per recuperare il valore delle variabili del bootloader all'avvio del dispositivo, quindi utilizza questi dati per creare un'impronta dinamica per il dispositivo.
Ad esempio, per utilizzare le impronte dinamiche per i dispositivi tardis
e tardispro
, aggiornate i seguenti file come mostrato di seguito.
Aggiorna il file
odm/etc/build_std.prop
in modo che contenga la seguente riga.ro.odm.product.device=tardis
Aggiorna il file
odm/etc/build_pro.prop
in modo che contenga la seguente riga.ro.odm.product.device=tardispro
Aggiorna il file
odm/etc/build.prop
in modo che contenga le seguenti righe.ro.odm.product.device=tardis import /odm/etc/build_${ro.boot.product.hardware.sku}.prop
Queste righe impostano dinamicamente il nome, l'impronta e i valori ro.build.fingerprint
del dispositivo in base al valore della proprietà bootloaderro.boot.product.hardware.sku
(di sola lettura).
Aggiornare i metadati del pacchetto OTA
Un pacchetto OTA contiene un file di metadati (META-INF/com/android/metadata
) che descrive il pacchetto, inclusi i prerequisiti e i postrequisiti del pacchetto OTA. Ad esempio, il seguente codice è il file di metadati di un pacchetto OTA rivolto al dispositivo tardis
.
post-build=google/tardis/tardis:11/RP1A.200521.001/6516341:userdebug/dev-keys
post-build-incremental=6516341
post-sdk-level=30
post-security-patch-level=2020-07-05
post-timestamp=1590026334
pre-build=google/tardis/tardis:11/RP1A.200519.002.A1/6515794:userdebug/dev-keys
pre-build-incremental=6515794
pre-device=tardis
I valori pre-device
, pre-build-incremental
e pre-build
definiscono lo stato che deve avere un dispositivo prima che il pacchetto OTA possa essere installato. I valori post-build-incremental
e post-build
definiscono lo stato che dovrebbe avere un dispositivo dopo l'installazione del pacchetto OTA. I valori dei campi pre-
e
post-
sono ricavati dalle seguenti proprietà di build corrispondenti.
- Il valore
pre-device
è dedotto dalla proprietà di compilazionero.product.device
. - I valori
pre-build-incremental
epost-build-incremental
derivano dalla proprietà di compilazionero.build.version.incremental
. - I valori
pre-build
epost-build
derivano dalla proprietà di compilazionero.build.fingerprint
.
Sui dispositivi con Android 11 o versioni successive, puoi utilizzare il flag --boot_variable_file
negli strumenti OTA per specificare il percorso di un file contenente i valori delle variabili di runtime utilizzate per creare l'impronta dinamica del dispositivo. I dati vengono poi utilizzati per aggiornare i metadati OTA in modo da includere il nome e l'impronta del dispositivo nelle condizioni pre-
e post-
(utilizzando il carattere barra verticale | come delimitatore). Il flag --boot_variable_file
ha la seguente sintassi e descrizione.
- Sintassi:
--boot_variable_file <path>
- Descrizione: specifica il percorso di un file contenente i possibili valori delle proprietà
ro.boot.*
. Utilizzato per calcolare le possibili impronte di runtime quando alcune proprietàro.product.*
vengono sostituite dall'istruzione di importazione. Il file prevede una proprietà per riga, ciascuna con il seguente formato:prop_name=value1,value2
.
Ad esempio, quando la proprietà è ro.boot.product.hardware.sku=std,pro
, i metadati OTA per i dispositivi tardis
e tardispro
sono come mostrato di seguito.
post-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-device=tardis|tardispro
Per supportare questa funzionalità sui dispositivi con Android 10, consulta l'implementazione di riferimento.
Questo elenco di modifiche analizza in modo condizionale le istruzioni import
nel file build.prop
, il che consente di riconoscere e applicare le sostituzioni delle proprietà nei metadati OTA finali.