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. Per fare ciò è necessario configurare i dispositivi di destinazione per utilizzare le impronte digitali dinamiche e aggiornare i metadati OTA per includere il nome del dispositivo e l'impronta digitale nelle voci pre e postcondizione.
Android 8.0 ha deprecato 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, di avvio e di ripristino). Finché il dispositivo è in grado di ricevere e applicare il pacchetto, il pacchetto può installare la build indipendentemente dallo stato corrente del dispositivo. Ad esempio, i seguenti comandi utilizzano 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 costruire pacchetti OTA per il dispositivo tardis
. Puoi anche creare ota_from_target_files
come 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
è impostato 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 utente, genera e utilizza le tue chiavi private come descritto in dettaglio in Firma delle build per il rilascio .
Crea aggiornamenti incrementali
Un aggiornamento incrementale è un pacchetto OTA che contiene patch binarie ai dati già presenti sul dispositivo. I pacchetti con aggiornamenti incrementali sono in genere più piccoli poiché non è necessario che includano file non modificati. Inoltre, poiché i file modificati sono spesso molto simili alle versioni precedenti, è sufficiente che il pacchetto contenga una codifica delle differenze tra i due file.
È possibile installare un pacchetto di aggiornamento incrementale solo sui dispositivi in cui è stata utilizzata la build di origine nella creazione del pacchetto. Per creare un aggiornamento incrementale, è necessario il file target_files.zip
della build precedente (quella da cui si desidera aggiornare ) nonché il file target_files.zip
della nuova build. Ad esempio, i seguenti comandi utilizzano 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 del corrispondente aggiornamento completo (circa 1 MB invece di 60 MB).
Distribuire un pacchetto incrementale solo ai 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
(entrambi creati con make dist
, da flashare con fastboot update
), invece di quelle nella directory PRODUCT_OUT
(creata con make
, che verrà flashato con fastboot flashall
). Il tentativo di installare il pacchetto incrementale su un dispositivo con qualche altra build genera un errore di installazione. Quando l'installazione fallisce, il dispositivo rimane nello stesso stato di funzionamento (eseguendo 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 aggiornato a metà.
Per la migliore esperienza utente, offri un aggiornamento completo ogni 3-4 aggiornamenti incrementali. Ciò aiuta gli utenti a aggiornarsi con l'ultima versione ed evitare una lunga sequenza di installazione di aggiornamenti incrementali.
Crea 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 fare ciò è necessario configurare i dispositivi di destinazione per utilizzare le impronte digitali dinamiche e aggiornare i metadati OTA (utilizzando gli strumenti OTA) per includere il nome del dispositivo e l'impronta digitale nelle voci pre e post condizione.
Informazioni sugli SKU
Il formato di uno SKU è una variazione dei valori dei parametri di build combinati ed è in genere un sottoinsieme non dichiarato dei parametri build_fingerprint
correnti. Gli OEM possono utilizzare qualsiasi combinazione di parametri di build approvati da CDD per uno SKU utilizzando anche una singola immagine per tali SKU. Ad esempio, il seguente SKU ha più varianti:
SKU = <product><device><modifierA><modifierB><modifierC>
-
modifierA
è il livello del dispositivo (come Pro, Premium o Plus) -
modifierB
è la variazione hardware (come la radio) -
modifierC
è la regione, che può essere generale (come NA, EMEA o CHN) o specifica per paese o lingua (come JPN, ENG o CHN)
Molti OEM utilizzano una singola immagine per più SKU, quindi ricavano il nome del 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 personalizzazioni minori ma nomi di prodotto diversi di condividere immagini comuni (come tardis
e tardispro
).
Utilizza impronte digitali dinamiche
Un'impronta digitale è una concatenazione definita di parametri di build come ro.product.brand
, ro.product.name
e ro.product.device
. L'impronta digitale di un dispositivo deriva dall'impronta digitale della partizione di sistema e viene utilizzata come identificatore univoco delle immagini (e dei byte) in esecuzione sul dispositivo. Per creare un'impronta digitale dinamica , utilizza la logica dinamica nel file build.prop
del dispositivo per ottenere il valore delle variabili del bootloader al momento dell'avvio del dispositivo, quindi utilizza tali dati per creare un'impronta digitale dinamica per quel dispositivo.
Ad esempio, per utilizzare le impronte digitali dinamiche per i dispositivi tardis
e tardispro
, aggiorna i seguenti file come mostrato di seguito.
Aggiorna il file
odm/etc/build_std.prop
per contenere la seguente riga.ro.odm.product.device=tardis
Aggiorna il file
odm/etc/build_pro.prop
per contenere la seguente riga.ro.odm.product.device=tardispro
Aggiorna il file
odm/etc/build.prop
per contenere le seguenti righe.ro.odm.product.device=tardis import /odm/etc/build_${ro.boot.product.hardware.sku}.prop
Queste righe impostano dinamicamente il nome del dispositivo, l'impronta digitale e i valori ro.build.fingerprint
in base al valore della proprietà del 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 la precondizione e la postcondizione del pacchetto OTA. Ad esempio, il codice seguente è il file di metadati per un pacchetto OTA destinato 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 un dispositivo deve avere 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-
derivano dalle seguenti proprietà di compilazione corrispondenti.
- Il valore
pre-device
deriva dalla proprietà di 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 un percorso a un file che contiene i valori delle variabili di runtime utilizzate nella creazione dell'impronta digitale dinamica del dispositivo. I dati vengono quindi utilizzati per aggiornare i metadati OTA per includere il nome del dispositivo e l'impronta digitale nelle condizioni pre-
e post-
(utilizzando il carattere pipe | come delimitatore). Il flag --boot_variable_file
ha la sintassi e la descrizione seguenti.
- Sintassi:
--boot_variable_file <path>
- Descrizione: specifica un percorso a un file che contiene i possibili valori delle proprietà
ro.boot.*
. Utilizzato per calcolare le possibili impronte di runtime quando alcune proprietàro.product.*
vengono sovrascritte dall'istruzione import. Il file prevede una proprietà per riga in cui ogni riga ha 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 quelli mostrati 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
, consentendo il riconoscimento e l'inclusione delle modifiche delle proprietà nei metadati OTA finali.