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 target-files.zip file prodotto dal sistema di compilazione Android come input.

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 dei pre e postcondizioni.

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 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, usano gli strumenti di rilascio per creare l'archivio target-files.zip per tardis dispositivo.

. 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/.

Il documento ota_update.zip è ora 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 Firmare le build per la release.

Crea aggiornamenti incrementali

Un aggiornamento incrementale è un pacchetto OTA che contiene patch binarie per i dati. sono già presenti sul dispositivo. I pacchetti con aggiornamenti incrementali sono in genere più piccoli dato che non è necessario includere file non modificati. 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 con build del codice sorgente utilizzata per creare il pacchetto. Per creare un aggiornamento incrementale, devi avere il file target_files.zip della build precedente (quella da cui vuoi aggiornare) 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 su dispositivi che funzionano esattamente nello stesso modo la build precedente usata 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 (con il vecchio sistema in esecuzione); il pacchetto verifica lo stato precedente di tutti i file che aggiorna prima di toccarli, in modo che il dispositivo non rimanga bloccato in uno stato di aggiornamento incompleto.

Per una migliore esperienza utente, offri un aggiornamento completo ogni 3-4 volte aggiornamenti. In questo modo gli utenti possono recuperare l'ultima release ed evitare una 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 è necessario configurare ai dispositivi target di usare fingerprint dinamiche e aggiornare i metadati OTA. (con strumenti OTA) per includere il nome del dispositivo e l'impronta nel pre e nel post le voci delle condizioni.

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 build approvati CDD per uno SKU, mentre utilizzando 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 variante hardware (ad esempio radio)
  • modifierC è la regione, che può essere generica (ad esempio NA, EMEA o CHN ) o specifiche per paese o lingua (come JPN, ENG o CHN)

Molti OEM utilizzano una singola immagine per più SKU, poi ottengono il prodotto finale il nome e l'impronta digitale del dispositivo in fase di runtime, dopo l'avvio. Questa procedura semplifica 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 build come parametri ro.product.brand, ro.product.name e ro.product.device. L'impronta 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 dinamica, utilizza la logica dinamica nel file build.prop del dispositivo per ottenere il valore delle variabili bootloader al momento dell'avvio del dispositivo, quindi utilizzare questi dati per creare un'impronta dinamica per il dispositivo.

Ad esempio, per usare fingerprint dinamiche per i dispositivi tardis e tardispro, aggiorna i 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 righe seguenti.

    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).

Aggiorna i metadati del pacchetto OTA

Un pacchetto OTA contiene un file di metadati (META-INF/com/android/metadata) che descriva il pacco, includendo informazioni preliminari e postcondizione dell'OTA pacchetto. 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. La I valori post-build-incremental e post-build definiscono lo stato di un dispositivo che si prevede avrà dopo l'installazione del pacchetto OTA. I valori di pre- e I campi post- derivano dalle seguenti proprietà di build corrispondenti.

  • Il valore pre-device è dedotto dalla proprietà di compilazione ro.product.device.
  • I valori pre-build-incremental e post-build-incremental sono derivati dalla proprietà build ro.build.version.incremental.
  • I valori pre-build e post-build derivano dal Proprietà build ro.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 barra verticale | come delimitatore). Il flag --boot_variable_file ha le seguenti sintassi e descrizione.

  • Sintassi: --boot_variable_file <path>
  • Descrizione: specifica un percorso di un file che contiene i possibili valori di ro.boot.* proprietà. Utilizzata 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, con il seguente formato: prop_name=value1,value2.

Ad esempio, se la proprietà è ro.boot.product.hardware.sku=std,pro, la proprietà Di seguito sono riportati i metadati OTA per dispositivi tardis e tardispro.

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 la documentazione di riferimento implementazione. 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.