Creazione di pacchetti OTA

È possibile utilizzare ota_from_target_files strumento fornito in build/make/tools/releasetools per costruire pacchetti completi e incrementali OTA per i dispositivi che utilizzano gli aggiornamenti del sistema A / B o aggiornamenti di sistema non-A / B . Lo strumento prende il target-files.zip file prodotto dal sistema di compilazione di Android come input.

Per i dispositivi con Android 11 o versioni successive, puoi creare un pacchetto OTA per più dispositivi con SKU diversi. In questo modo richiede la configurazione dei dispositivi di destinazione a uso impronte digitali dinamici e aggiornando i metadati OTA per includere il nome del dispositivo e le impronte digitali nelle voci pre e post-condizione.

Android 8.0 deprecato pacchetti OTA basate su file per dispositivi / B non-A, che devono invece utilizzare pacchetti OTA basati su blocchi . Per generare i pacchetti o dispositivi OTA basati su blocchi eseguono 7.x Android o abbassare, passare la --block opzione al ota_from_target_files parametro.

Costruire aggiornamenti completi

Un aggiornamento completo è un pacchetto OTA contenente l'intero stato finale del dispositivo (sistema, di avvio, e pareti di recupero). 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 costruire il target-files.zip archivio per il tardis dispositivo.

. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output

make dist costruisce un pacchetto OTA completo (in $OUT ). La risultante .zip file contiene tutto il necessario per la costruzione di pacchetti OTA per il tardis dispositivo. È inoltre possibile creare le ota_from_target_files come un binario di pitone e chiamarla per costruire sia pacchetti completi o incrementali.

ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip

ota_from_target_files percorso è impostato in $PATH , e il binario pitone risultante si trova nella out/ directory.

ota_update.zip è ora pronto per essere inviato a dispositivi di prova (tutto è firmato con la chiave di prova). Per i dispositivi degli utenti, generare e utilizzare le proprie chiavi private come dettagliato nella firma costruisce per il rilascio .

Creazione di aggiornamenti incrementali

Un aggiornamento incrementale è un pacchetto OTA contenente patch binarie ai dati già sul dispositivo. I pacchetti con aggiornamenti incrementali sono in genere più piccoli in quanto 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.

È possibile installare un pacchetto di aggiornamento incrementale solo su dispositivi che hanno la build di origine utilizzata nella creazione del pacchetto. Per costruire un aggiornamento incrementale, è necessario il target_files.zip file dalla precedente build (quella che si desidera aggiornare da), così come il target_files.zip file dalla nuova costruzione. Ad esempio, i seguenti comandi utilizzano strumenti di rilascio per costruire un aggiornamento incrementale per il tardis dispositivo.

ota_from_target files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip

Questa generazione è molto simile alla configurazione precedente, e il pacchetto di aggiornamento incrementale ( incremental_ota_update.zip ) è molto più piccola della 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. È necessario lampeggiare le immagini in PREVIOUS-tardis-target_files.zip o PREVIOUS-tardis-img.zip (entrambi costruiti con make dist , per essere balenato con fastboot update ), al posto di quelli sotto il PRODUCT_OUT directory (costruito con make , che verrà illuminato 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 è bloccato in uno stato mezzo aggiornato.

Per la migliore esperienza utente, offri un aggiornamento completo ogni 3-4 aggiornamenti incrementali. Ciò consente agli utenti di aggiornarsi sull'ultima versione ed evitare una lunga sequenza di installazione di aggiornamenti incrementali.

Creazione di pacchetti OTA per più SKU

Android 11 o versioni successive supporta l'utilizzo di un singolo pacchetto OTA per più dispositivi con SKU diversi. Ciò richiede la configurazione dei dispositivi di destinazione per l'utilizzo delle impronte digitali dinamiche e l'aggiornamento dei 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 combinata dei parametri di generazione dei valori ed è tipicamente un sottoinsieme sommerso degli attuali build_fingerprint parametri. Gli OEM possono utilizzare qualsiasi combinazione di parametri di compilazione 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 di dispositivo (ad esempio Pro, Premium o Plus)
  • modifierB è la variazione hardware (ad esempio radio)
  • modifierC è la regione, che può essere generale (ad esempio NA, EMEA o CHN) o Paese o linguaggio specifico (come JPN, ENG, o CHN)

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

Utilizzo delle impronte digitali dinamiche

Un'impronta digitale è una concatenazione definita di parametri di costruzione come ro.product.brand , ro.product.name e ro.product.device . L'impronta digitale di un dispositivo è derivata dall'impronta digitale della partizione di sistema e viene utilizzata come identificatore univoco delle immagini (e dei byte) in esecuzione sul dispositivo. Per creare una dinamica di impronte digitali, usa la logica dinamica del dispositivo build.prop file per ottenere il valore delle variabili bootloader al momento del boot del dispositivo, quindi utilizzare i dati per creare un'impronta digitale dinamico per quel dispositivo.

Ad esempio, per utilizzare le impronte digitali dinamici per tardis e tardispro dispositivi, aggiornare i seguenti file come mostrato sotto.

  • Update l' odm/etc/build_std.prop file per contenere la seguente riga.

    ro.odm.product.device=tardis
    
  • Aggiornare il odm/etc/build_pro.prop file per contenere la seguente riga.

    ro.odm.product.device=tardispro
    
  • Aggiornare il odm/etc/build.prop file 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, impronte digitali, e ro.build.fingerprint valori in base al valore della ro.boot.product.hardware.sku struttura bootloader (che è di sola lettura).

Aggiornamento dei metadati del pacchetto OTA

Pacchetto di un OTA contiene un file di metadati ( META-INF/com/android/metadata ) che descrive il pacchetto, compresa la precondizione e postcondizione del pacchetto OTA. Ad esempio, il codice seguente è il file di metadati per un pacchetto OTA mira il tardis dispositivo.

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

Il pre-device , pre-build-incremental , e pre-build valori definiscono lo stato di un dispositivo deve avere prima che il pacchetto OTA possibile installare. I post-build-incremental e post-build valori definiscono lo stato di un dispositivo dovrebbe avere dopo le installazioni pacchetto OTA. I valori di pre- e post- campi sono derivati dai seguenti corrispondenti proprietà di compilazione.

  • Il pre-device valore è derivato dal ro.product.device immobiliare Costruire.
  • I pre-build-incremental e post-build-incremental valori sono derivati dal ro.build.version.incremental immobiliare Costruire.
  • I pre-build e post-build i valori sono derivati dal ro.build.fingerprint immobiliare Costruire.

Su dispositivi con Android 11 o superiore, è possibile utilizzare il --boot_variable_file bandiera strumenti OTA per specificare un percorso di un file che contiene i valori delle variabili di runtime utilizzati nella creazione di impronte digitali dinamica del dispositivo. I dati vengono quindi utilizzati per aggiornare i metadati OTA per includere il nome del dispositivo e l'impronta digitale nel pre- e post- condizioni (utilizzando il carattere pipe | come delimitatore). Il --boot_variable_file bandiera ha la seguente sintassi e descrizione.

  • Sintassi: --boot_variable_file <path>
  • Descrizione: specifica un percorso di un file che contiene i possibili valori di ro.boot.* Proprietà. Utilizzato per calcolare i possibili impronte digitali di runtime quando alcuni ro.product.* Proprietà prevalga la dichiarazione di importazione. Il file si aspetta una proprietà per riga in cui ogni riga ha il formato seguente: prop_name=value1,value2 .

Ad esempio, quando la struttura è ro.boot.product.hardware.sku=std,pro , i metadati OTA per tardis e tardispro dispositivi è il seguente.

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à su dispositivi con Android 10, vedere l' implementazione di riferimento . Questo elenco modifiche analizza condizionalmente le import istruzioni nel build.prop file, che permette modifiche locali delle proprietà per essere riconosciuti e riflesse nei metadati OTA finale.