Creare pacchetti OTA

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 compilazione Android.

Per i dispositivi con Android 11 o versioni successive, puoi creare un 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 in modo da includere il nome e l'impronta del dispositivo nelle voci di precondizione 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.

Creare aggiornamenti completi

Un aggiornamento completo è un pacchetto OTA che contiene l'intero stato finale del dispositivo (partizioni di sistema, avvio e ripristino). Se il dispositivo è in grado di ricevere e applicare il pacchetto, quest'ultimo 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 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 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 Firma delle build per la release.

Creare 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 in quanto 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 hanno la build di origine utilizzata per la creazione del pacchetto. Per creare un aggiornamento incrementale, hai bisogno del file target_files.zip della build precedente (quella che vuoi aggiornare da) e del file target_files.zip della nuova build. Ad esempio, i seguenti comandi 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 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 build precedente utilizzata come punto di partenza del pacchetto incrementale. Devi flashare le immagini in PREVIOUS-tardis-target_files.zip o PREVIOUS-tardis-img.zip (entrambe create con make dist, da flashare con fastboot update), anziché quelle nella directory PRODUCT_OUT (create con make, che verranno flashate con fastboot flashall). Il tentativo di installare il pacchetto incrementale su un dispositivo con un'altra build genera un errore di installazione. Quando 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 aggiorna prima di modificarli, in modo che il dispositivo non rimanga in uno stato di aggiornamento parziale.

Per un'esperienza utente ottimale, offri un aggiornamento completo ogni 3-4 aggiornamenti incrementali. In questo modo gli utenti possono recuperare l'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 variante dei valori combinati del parametro build 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 e utilizzare 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 esempio Pro, Premium o Plus)
• modifierB è la variante hardware (ad esempio la radio)
• modifierC è la regione, che può essere generale (ad esempio NA, EMEA o CHN) o specifica per paese o lingua (ad esempio JPN, ENG o CHN).

Molti OEM utilizzano una singola immagine per più SKU, quindi derivano il nome del prodotto finale e l'impronta del dispositivo in fase di runtime dopo l'avvio del dispositivo. Questo processo semplifica lo sviluppo della piattaforma, consentendo ai dispositivi con personalizzazioni minori ma nomi di prodotti diversi di condividere immagini comuni (come tardis e tardispro).

Utilizzare le impronte dinamiche

Un'impronta è una concatenazione definita di parametri di build, ad esempio ro.product.brand, ro.product.name e ro.product.device. L'impronta di un dispositivo deriva dall'impronta 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 del bootloader al momento dell'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, aggiorna 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 i valori di nome del dispositivo, impronta e ro.build.fingerprint in base al valore della proprietà ro.boot.product.hardware.sku del bootloader (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, inclusi la precondizione e la postcondizione del pacchetto OTA. Ad esempio, il seguente codice è 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 possa essere installato il pacchetto OTA. I valori post-build-incremental e post-build definiscono lo stato che un dispositivo dovrebbe avere 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à di build ro.product.device.
• I valori pre-build-incremental e post-build-incremental sono derivati dalla proprietà di build ro.build.version.incremental.
• I valori pre-build e post-build derivano dalla proprietà di build ro.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 per creare l'impronta dinamica del dispositivo. I dati vengono quindi 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 pipe | come delimitatore). Il flag --boot_variable_file ha la seguente sintassi e descrizione.

• 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 sostituite dall'istruzione import. Il file prevede una proprietà per riga, dove 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 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, il che consente di riconoscere e riflettere le sostituzioni delle proprietà nei metadati OTA finali.