OTA per dispositivi A/B senza partizioni dinamiche

Android 10 supporta le partizioni dinamiche , un sistema di partizionamento dello spazio utente in grado di creare, ridimensionare e distruggere le partizioni durante gli aggiornamenti over-the-air (OTA).

Questa pagina descrive come i client OTA ridimensionano le partizioni dinamiche durante un aggiornamento per dispositivi A/B avviati senza supporto per partizioni dinamiche e come i client OTA eseguono l'aggiornamento ad Android 10.

Sfondo

Durante un aggiornamento di un dispositivo A/B per supportare le partizioni dinamiche, la tabella delle partizioni GUID (GPT) sul dispositivo viene preservata, quindi non è presente alcuna super partizione sul dispositivo. I metadati sono archiviati in system_a e system_b , ma questo può essere personalizzato modificando BOARD_SUPER_PARTITION_METADATA_DEVICE .

In ciascuno dei dispositivi a blocchi sono presenti due slot per metadati. Viene utilizzato solo uno slot di metadati in ciascun dispositivo a blocchi. Ad esempio, i metadati 0 in system_a e i metadati 1 in system_b corrispondono rispettivamente alle partizioni negli slot A e B. In fase di esecuzione, non importa quale slot viene aggiornato.

In questa pagina, gli slot dei metadati sono chiamati Metadata S (sorgente) e Metadata T (destinazione). Allo stesso modo, le partizioni vengono chiamate system_s , vendor_t e così via.

Per ulteriori informazioni sulle configurazioni del sistema di build , vedere Aggiornamento dei dispositivi .

Per ulteriori informazioni su come le partizioni appartengono ai gruppi di aggiornamento , vedere Modifiche alla configurazione della scheda per i nuovi dispositivi.

Un esempio di metadati su un dispositivo è:

  • system_a di dispositivi a blocchi fisici_a
    • Metadati 0
      • Gruppo foo_a
        • system_a di partizione logica (dinamica)_a
        • Partizione logica (dinamica) product_services_a
        • Altre partizioni aggiornate da Foo
      • Gruppo bar_a
        • Partizione logica (dinamica) vendor_a
        • Partizione logica (dinamica) product_a
        • Altre partizioni aggiornate da Bar
    • Metadati 1 (non utilizzato)
  • Dispositivo a blocchi fisici system_b
    • Metadati 0 (non utilizzato)
    • Metadati 1
      • Gruppo foo_b
        • Partizione logica (dinamica) system_b
        • Partizione logica (dinamica) product_services_b
        • Altre partizioni aggiornate da Foo
      • Barra del gruppo_b
        • Partizione logica (dinamica) vendor_b
        • Partizione logica (dinamica) product_b
        • Altre partizioni aggiornate da Bar

Puoi utilizzare lo strumento lpdump in system/extras/partition_tools per scaricare i metadati sul tuo dispositivo. Per esempio:

lpdump --slot 0 /dev/block/by-name/system_a
lpdump --slot 1 /dev/block/by-name/system_b

Aggiornare un aggiornamento

Sui dispositivi con Android 9 e versioni precedenti, il client OTA sul dispositivo non supporta la mappatura delle partizioni dinamiche prima dell'aggiornamento. Viene creata una serie aggiuntiva di patch in modo che la mappatura possa essere applicata direttamente alle partizioni fisiche esistenti.

Il generatore OTA crea il file super.img finale che contiene il contenuto di tutte le partizioni dinamiche, quindi divide l'immagine in più immagini corrispondenti alle dimensioni dei dispositivi a blocchi fisici corrispondenti al sistema, al fornitore e così via. Queste immagini sono denominate super_system.img , super_vendor.img e così via. Il client OTA applica queste immagini alle partizioni fisiche, anziché applicare le immagini alle partizioni logiche (dinamiche).

Poiché il client OTA non sa come mappare le partizioni dinamiche, tutti i passaggi post-installazione vengono disabilitati automaticamente per queste partizioni quando viene generato il pacchetto di aggiornamento. Per ulteriori dettagli vedere Configurazione post-installazione .

Il flusso di aggiornamento è lo stesso di Android 9.

Prima dell'aggiornamento:

ro.boot.dynamic_partitions=
ro.boot.dynamic_partitions_retrofit=

Dopo l'aggiornamento:

ro.boot.dynamic_partitions=true
ro.boot.dynamic_partitions_retrofit=true

Aggiornamenti futuri dopo il retrofit

Dopo l'aggiornamento di retrofit, il client OTA viene aggiornato per funzionare con le partizioni dinamiche. Le estensioni per le partizioni di origine non si estendono mai su partizioni fisiche di destinazione.

Flusso di aggiornamento utilizzando un pacchetto di aggiornamento regolare

  1. Inizializza i metadati della super partizione.
    1. Costruisci nuovi metadati M da metadati S (metadati di origine). Ad esempio, se i metadati S utilizzano [ system_s , vendor_s , product_s ] come dispositivi a blocchi, i nuovi metadati M utilizzano [ system_t , vendor_t , product_t ] come dispositivi a blocchi. Tutti i gruppi e le partizioni vengono scartati in M.
    2. Aggiungi gruppi di destinazione e partizioni in base al campo dynamic_partition_metadata nel manifest dell'aggiornamento. La dimensione di ciascuna partizione può essere trovata in new_partition_info .
    3. Scrivi M nei metadati T.
    4. Mappare le partizioni aggiunte sul mappatore del dispositivo come scrivibili.
  2. Applicare l'aggiornamento sui dispositivi a blocchi.
    1. Se necessario, mappare le partizioni di origine sul mappatore del dispositivo come di sola lettura. Ciò è necessario per il sideload perché le partizioni di origine non vengono mappate prima dell'aggiornamento.
    2. Applica un aggiornamento completo o delta a tutti i dispositivi a blocchi nello slot di destinazione.
    3. Montare le partizioni per eseguire lo script post-installazione, quindi smontare le partizioni.
  3. Annulla la mappatura delle partizioni di destinazione.

Flusso di aggiornamento utilizzando un pacchetto di aggiornamento di retrofit

Se il pacchetto di aggiornamento di retrofit viene applicato su un dispositivo che abilita già le partizioni dinamiche, il client OTA applica il file super.img diviso direttamente sui dispositivi a blocchi. Il flusso di aggiornamento è simile a un aggiornamento di retrofit. Per i dettagli vedere Adattamento di un aggiornamento .

Ad esempio, supponiamo quanto segue:

  • Lo slot A è lo slot attivo.
  • system_a contiene i metadati attivi nello slot 0.
  • system_a , vendor_a e product_a vengono utilizzati come dispositivi a blocchi.

Quando il client OTA riceve un pacchetto di aggiornamento di retrofit, applica super_system.img su system_b fisico, super_vendor.img su vendor_b fisico e super_product.img su product_b fisico. Il dispositivo a blocchi fisico system_b contiene i metadati corretti per mappare il sistema logico system_b , vendor_b e product_b al momento dell'avvio.

Genera pacchetti di aggiornamento

OTA incrementale

Quando si generano OTA incrementali per dispositivi di retrofit, gli aggiornamenti dipendono dal fatto che la build di base definisca o meno PRODUCT_USE_DYNAMIC_PARTITIONS e PRODUCT_RETROFIT_DYNAMIC_PARTITIONS .

  • Se la build di base non definisce le variabili, si tratta di un aggiornamento di retrofit. Il pacchetto di aggiornamento contiene il file super.img diviso e disabilita la fase di post-installazione.
  • Se la build di base definisce le variabili, equivale a un tipico aggiornamento con partizioni dinamiche. Il pacchetto di aggiornamento contiene le immagini per le partizioni logiche (dinamiche). È possibile abilitare la fase post-installazione.

OTA completo

Vengono generati due pacchetti OTA completi per i dispositivi di retrofit.

  • $(PRODUCT)-ota-retrofit-$(TAG).zip contiene sempre super.img diviso e disabilita il passaggio post-installazione per l'aggiornamento del retrofit.
    • Viene generato con un argomento aggiuntivo --retrofit_dynamic_partitions allo script ota_from_target_files .
    • Può essere applicato a tutte le build.
  • $(PRODUCT)-ota-$(TAG).zip contiene immagini logiche per futuri aggiornamenti.
    • Applicalo solo alle build con partizioni dinamiche abilitate. Vedi i dettagli di seguito su come applicarlo.

Rifiuta l'aggiornamento non retrofit su vecchie build

Applicare il normale pacchetto OTA completo solo alle build con partizioni dinamiche abilitate. Se il server OTA è configurato in modo errato e invia questi pacchetti ai dispositivi con Android 9 o versioni precedenti, i dispositivi non si avviano. Il client OTA su Android 9 e versioni precedenti non è in grado di distinguere tra un pacchetto OTA retrofit e un normale pacchetto OTA completo, quindi il client non rifiuterà il pacchetto completo.

Per impedire al dispositivo di accettare il pacchetto OTA completo, è possibile richiedere un passaggio post-installazione per verificare la configurazione del dispositivo esistente. Per esempio:

device/ device_name /dynamic_partitions/check_dynamic_partitions

#!/system/bin/sh
DP_PROPERTY_NAME="ro.boot.dynamic_partitions"
DP_RETROFIT_PROPERTY_NAME="ro.boot.dynamic_partitions_retrofit"

DP_PROPERTY=$(getprop ${DP_PROPERTY_NAME})
DP_RETROFIT_PROPERTY=$(getprop ${DP_RETROFIT_PROPERTY_NAME})

if [ "${DP_PROPERTY}" != "true" ] || [ "${DP_RETROFIT_PROPERTY}" != "true" ] ; then
    echo "Error: applied non-retrofit update on build without dynamic" \
         "partitions."
    echo "${DP_PROPERTY_NAME}=${DP_PROPERTY}"
    echo "${DP_RETROFIT_PROPERTY_NAME}=${DP_RETROFIT_PROPERTY}"
    exit 1
fi

device/ device_name /dynamic_partitions/Android.mk

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE:= check_dynamic_partitions
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_CLASS := EXECUTABLES
LOCAL_SRC_FILES := check_dynamic_partitions
LOCAL_PRODUCT_MODULE := true
include $(BUILD_PREBUILT)

device/ device_name /device.mk

PRODUCT_PACKAGES += check_dynamic_partitions

# OPTIONAL=false so that the error in check_dynamic_partitions will be
# propagated to OTA client.
AB_OTA_POSTINSTALL_CONFIG += \
    RUN_POSTINSTALL_product=true \
    POSTINSTALL_PATH_product=bin/check_dynamic_partitions \
    FILESYSTEM_TYPE_product=ext4 \
    POSTINSTALL_OPTIONAL_product=false \

Quando il normale pacchetto OTA viene applicato su un dispositivo senza partizioni dinamiche abilitate, il client OTA esegue check_dynamic_partitions come passaggio post-installazione e rifiuta l'aggiornamento.