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
file target-files.zip
prodotto dal sistema di build Android.
Per i dispositivi con Android 11 o versioni successive, puoi creare un pacchetto OTA per più dispositivi con SKU diversi. A questo scopo, è necessario configurare i dispositivi di destinazione in modo che utilizzino le fingerprint dinamiche e aggiornare i metadati OTA in modo da includere il nome e l'impronta del dispositivo nelle voci 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 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, avvio e ripristino). Finché il dispositivo è in grado di ricevere e applicare il pacchetto, il pacchetto può installare la build indipendentemente dallo stato attuale del dispositivo. Ad esempio, i seguenti comandi utilizzano gli strumenti di rilascio 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 creare ota_from_target_files
come file binario Python e chiamarlo per creare 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/
.
Ora ota_update.zip
è pronto per essere inviato ai dispositivi di test (tutti i dati sono firmati con la chiave di test). Per i dispositivi degli utenti, genera e utilizza le tue chiavi private come descritto in dettaglio 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 generalmente più piccoli, in quanto non è necessario 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 in cui è utilizzata la build di origine nella creazione del pacchetto. Per creare un aggiornamento incrementale,
hai bisogno del file target_files.zip
della build precedente (quella da cui
vuoi eseguire l'aggiornamento da) e del file target_files.zip
della nuova build. Ad
esempio, i comandi seguenti utilizzano gli strumenti di rilascio 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 invece di 60 MB).
Distribuisci un pacchetto incrementale solo su dispositivi che eseguono esattamente la stessa build 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
(creata con make
, che verrà eseguita con fastboot flashall
). Il tentativo di installare il pacchetto incrementale su un dispositivo con qualche altra build genera un errore di installazione. Se l'installazione non va a buon fine, il dispositivo rimane nello stesso stato di funzionamento (con il vecchio sistema); il pacchetto verifica lo stato precedente di tutti i file che vengono aggiornati prima di toccarli, in modo che il dispositivo non si trovi in uno stato di metà upgrade.
Per una migliore esperienza utente, offri un aggiornamento completo ogni 3-4 aggiornamenti incrementali. In questo modo gli utenti possono recuperare la release più recente 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 unico pacchetto OTA per più dispositivi con SKU diversi. A tale scopo, devi configurare i dispositivi di destinazione per l'utilizzo delle impronte dinamiche e aggiornare i metadati OTA (utilizzando gli strumenti OTA) in modo da includere il nome e l'impronta del dispositivo nelle voci pre e post-condizione.
Informazioni sugli SKU
Il formato di uno SKU è una variante dei valori combinati dei parametri di build ed è in genere un sottoinsieme non dichiarato degli attuali parametri build_fingerprint
.
Gli OEM possono utilizzare qualsiasi combinazione di parametri di build approvati da CDD per uno SKU e
un'unica immagine per questi SKU. Ad esempio, il seguente SKU ha più varianti:
SKU = <product><device><modifierA><modifierB><modifierC>
modifierA
è il livello del dispositivo (ad esempio Pro, Premium o Plus)modifierB
è la variante 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 di prodotto finale e l'impronta digitale del dispositivo in fase di runtime, dopo l'avvio del dispositivo. Questo processo semplifica il processo di sviluppo della piattaforma, consentendo ai dispositivi con piccole personalizzazioni ma nomi di prodotti diversi di condividere immagini comuni (ad esempio tardis
e tardispro
).
Utilizzo di fingerprint dinamiche
Un'impronta è una concatenazione definita di parametri di build come ro.product.brand
, ro.product.name
e ro.product.device
. L'impronta digitale di un dispositivo viene 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 ottenere il valore delle variabili di bootloader al momento dell'avvio del dispositivo, quindi utilizza i dati per creare un'impronta dinamica per il dispositivo.
Ad esempio, per utilizzare le impronte dinamiche per i dispositivi tardis
e tardispro
,
aggiorna i file riportati di seguito, come illustrato di seguito.
Aggiorna il file
odm/etc/build_std.prop
in modo che contenga la riga seguente.ro.odm.product.device=tardis
Aggiorna il file
odm/etc/build_pro.prop
in modo che contenga la riga seguente.ro.odm.product.device=tardispro
Aggiorna il file
odm/etc/build.prop
in modo che contenga le righe seguenti.ro.odm.product.device=tardis import /odm/etc/build_${ro.boot.product.hardware.sku}.prop
Queste righe impostano dinamicamente i valori del nome del dispositivo, dell'impronta e di ro.build.fingerprint
in base al valore della proprietà bootloader ro.boot.product.hardware.sku
(che è di sola lettura).
Aggiorna i metadati del pacchetto OTA
Un pacchetto OTA contiene un file di metadati (META-INF/com/android/metadata
) che
descrive il pacchetto, incluse le informazioni di precondizione e postcondizione del pacchetto OTA. Ad esempio, il seguente codice è il file di metadati per un pacchetto OTA che ha come target il 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 un dispositivo deve avere prima dell'installazione del pacchetto OTA. I valori post-build-incremental
e post-build
definiscono lo stato che si prevede avrà un dispositivo dopo l'installazione del pacchetto OTA. I valori dei campi pre-
e
post-
derivano dalle seguenti proprietà di build corrispondenti.
- Il valore
pre-device
deriva dalla proprietà buildro.product.device
. - I valori
pre-build-incremental
epost-build-incremental
derivano dalla proprietà buildro.build.version.incremental
. - I valori
pre-build
epost-build
derivano dalla proprietà buildro.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 nella creazione dell'impronta dinamica del dispositivo. I dati vengono quindi utilizzati per aggiornare i metadati OTA in modo da includere il nome del dispositivo e l'impronta nelle condizioni pre-
e post-
(utilizzando il carattere barra verticale | come delimitatore). Il flag --boot_variable_file
ha la
sintassi e la descrizione riportate di seguito.
- 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 fingerprint di runtime quando alcune proprietàro.product.*
vengono sostituite dall'istruzione di importazione. Il file prevede una proprietà per riga in cui ogni riga ha il seguente formato:prop_name=value1,value2
.
Ad esempio, se la proprietà è ro.boot.product.hardware.sku=std,pro
, i
metadati OTA per i dispositivi tardis
e tardispro
sono riportati 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 dei riferimenti.
Questo elenco di modifiche analizza in modo condizionale le istruzioni import
nel file build.prop
, consentendo il riconoscimento delle sostituzioni delle proprietà e la loro applicazione nei
metadati OTA finali.