Creare pacchetti OTA

Puoi utilizzare la ota_from_target_files fornito in build/make/tools/releasetools per creare soluzioni complete e incrementali Pacchetti OTA per 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 pacchetto OTA per più dispositivi con SKU diversi. Questa operazione richiede Configurazione dei dispositivi di destinazione per l'uso delle impronte dinamiche e l'aggiornamento dei metadati OTA per includere il dispositivo e l'impronta digitale nelle voci pre e postcondition.

Android 8.0 ha ritirato i pacchetti OTA basati su file per i dispositivi non A/B, che devono Utilizza invece pacchetti OTA basati su blocchi. A generare pacchetti OTA basati su blocchi o dispositivi con Android 7.x o versioni precedenti, 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). Purché il dispositivo sia in grado di ricezione e applicazione del pacchetto, il pacchetto può installare a prescindere dallo stato attuale 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 creare ota_from_target_files come file binario Python e chiamarlo a 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 Python risultante il file binario 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 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. 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 vengono spesso molto simili alle versioni precedenti, il pacchetto deve includere 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, ti serve il file target_files.zip della build precedente (quella che vuoi da aggiornare da) e il file target_files.zip della nuova build. Per Ad esempio, i comandi seguenti usano 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 l'aggiornamento incrementale pacchetto (incremental_ota_update.zip) è molto più piccolo del corrispondente aggiornamento completo (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 le immagini in PREVIOUS-tardis-target_files.zip o PREVIOUS-tardis-img.zip (entrambi creati con make dist, da flashare con fastboot update), anziché quelli contenuti nella directory PRODUCT_OUT (creati con make, che verranno lampeggiare con fastboot flashall). Tentativo di installare il pacchetto incrementale su un dispositivo con altre build comporta un errore di installazione. Quando l'installazione non va a buon fine, il dispositivo rimane nello stesso stato di funzionamento (con il precedente di sistema); il pacchetto verifica lo stato precedente di tutti i file che aggiorna prima di toccarli, in modo che il dispositivo non sia bloccato in uno stato di metà upgrade.

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 una singola OTA per più dispositivi con SKU diversi. Per farlo è necessario configurare ai dispositivi target di usare fingerprint dinamiche e aggiornare i metadati OTA. (con gli 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 variante della creazione combinata parametro e è generalmente un sottoinsieme non dichiarato degli attuali parametri build_fingerprint. 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 esempio 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 nome e impronta del dispositivo in fase di runtime, dopo l'avvio. Questo processo semplifica il processo di sviluppo della piattaforma, consentendo ai dispositivi con ma diversi nomi di prodotti per condividere immagini comuni (come tardis e tardispro).

Utilizzo di fingerprint 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 ottieni il valore delle variabili bootloader al momento dell'avvio del dispositivo, quindi utilizza quei 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 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 in modo dinamico il nome, l'impronta e ro.build.fingerprint in base al valore dell'attributo ro.boot.product.hardware.sku proprietà bootloader (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 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 stato che un dispositivo deve avere per l'installazione del pacchetto OTA. 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 deriva dalla proprietà build 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 contiene i valori delle variabili di runtime utilizzate per creare il parametro impronta dinamica. 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 in cui ogni riga presenta quanto segue: 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 in build.prop che consente di riconoscere le sostituzioni delle proprietà e applicarle nel metadati finali OTA.