Aggiornamento over-the-air per dispositivi A/B senza partizioni dinamiche

Android 10 supporta le partizioni dinamiche, un sistema di partizionamento dello spazio utente che può creare, ridimensionare ed eliminare partizioni durante gli aggiornamenti over-the-air (OTA).

Questa pagina descrive come i client OTA ridimensionano le partizioni dinamiche durante un aggiornamento per i dispositivi A/B che sono stati lanciati senza il supporto delle partizioni dinamiche e come i client OTA eseguono l'upgrade ad Android 10.

Sfondo

Durante l'aggiornamento di un dispositivo A/B per supportare le partizioni dinamiche, la tabella delle partizioni GUID (GPT) sul dispositivo viene mantenuta, quindi non è presente alcuna super partizione sul dispositivo. I metadati vengono archiviati in system_a e system_b, ma possono essere personalizzati modificando BOARD_SUPER_PARTITION_METADATA_DEVICE.

In ognuno dei dispositivi a blocchi sono presenti due slot di metadati. In ogni dispositivo a blocchi viene utilizzato un solo slot di metadati. 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 runtime, non ha importanza quale slot viene aggiornato.

In questa pagina, gli slot di metadati sono chiamati Metadati S (origine) e Metadati T (target). Allo stesso modo, le partizioni vengono chiamate system_s, vendor_t, e così via.

Per ulteriori informazioni sulle configurazioni del sistema di compilazione, vedi Eseguire l'upgrade dei dispositivi.

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

Di seguito è riportato un esempio di metadati su un dispositivo:

• Dispositivo a blocchi fisici system_a
  • Metadati 0
    • Gruppo foo_a
      • Partizione logica (dinamica) system_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 utilizzati)
• Dispositivo a blocchi fisici system_b
  • Metadati 0 (non utilizzati)
  • Metadati 1
    • Gruppo foo_b
      • Partizione logica (dinamica) system_b
      • Partizione logica (dinamica) product_services_b
      • Altre partizioni aggiornate da Foo
    • Gruppo bar_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 eseguire il dump dei metadati sul dispositivo. Ad esempio:

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

Eseguire il retrofit di un aggiornamento

Sui dispositivi con Android 9 e versioni precedenti, il client OTA sul dispositivo non supporta il mapping delle partizioni dinamiche prima dell'aggiornamento. Viene creato un set aggiuntivo di patch in modo che il mapping possa essere applicato direttamente alle partizioni fisiche esistenti.

Il generatore OTA crea il file super.img finale che contiene il contenuto di tutte le partizioni dinamiche, quindi suddivide l'immagine in più immagini corrispondenti alle dimensioni dei dispositivi a blocchi fisici corrispondenti a sistema, 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 per le partizioni logiche (dinamiche).

Poiché il client OTA non sa come mappare le partizioni dinamiche, tutti i passaggi post-installazione vengono disattivati automaticamente per queste partizioni quando viene generato il pacchetto di aggiornamento. Per maggiori dettagli, vedi Configurare la 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 alle partizioni fisiche di destinazione.

Flusso di aggiornamento utilizzando un pacchetto di aggiornamento normale

1. Inizializza i metadati della partizione super.
   1. Crea nuovi metadati M dai metadati di origine S. Ad esempio, se i metadati di origine 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 eliminati in M.
   2. Aggiungi i gruppi e le partizioni di destinazione in base al dynamic_partition_metadata campo nel manifest di aggiornamento. Le dimensioni di ogni partizione sono disponibili in new_partition_info.
   3. Scrivi M in Metadati T.
   4. Mappa le partizioni aggiunte sul mapper dei dispositivi come scrivibili.
2. Applica l'aggiornamento ai dispositivi a blocchi.
   1. Se necessario, mappa le partizioni di origine sul mapper dei dispositivi come di sola lettura. Questa operazione è necessaria per il sideloading 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. Monta le partizioni per eseguire lo script post-installazione, quindi smontale.
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 a un dispositivo che ha già attivato le partizioni dinamiche, il client OTA applica direttamente il file suddiviso super.img sui dispositivi a blocchi. Il flusso di aggiornamento è simile a un aggiornamento di retrofit. Per maggiori dettagli, vedi Eseguire il retrofit di un aggiornamento.

Ad esempio, supponiamo che:

• 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 a system_b fisico, super_vendor.img a vendor_b fisico e super_product.img a product_b fisico. Il dispositivo a blocchi fisici system_b contiene i metadati corretti per mappare le partizioni logiche system_b, vendor_b e product_b al momento dell'avvio.

Generare pacchetti di aggiornamento

OTA incrementale

Quando generi OTA incrementali per i 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 suddiviso super.img e disattiva il passaggio post-installazione.
• Se la build di base definisce le variabili, si tratta dello stesso aggiornamento tipico con partizioni dinamiche. Il pacchetto di aggiornamento contiene le immagini per le partizioni logiche (dinamiche). Il passaggio post-installazione può essere attivato.

OTA completo

Per i dispositivi di retrofit vengono generati due pacchetti OTA completi.

• $(PRODUCT)-ota-retrofit-$(TAG).zip contiene sempre suddiviso super.img e disattiva il passaggio post-installazione per l'aggiornamento di retrofit.
  • Viene generato con un argomento aggiuntivo --retrofit_dynamic_partitions allo ota_from_target_files script.
  • Può essere applicato a tutte le build.
• $(PRODUCT)-ota-$(TAG).zip contiene immagini logiche per aggiornamenti futuri.
  • Applica questo solo alle build con le partizioni dinamiche attivate. Per i dettagli su come applicare questa impostazione, vedi di seguito.

Rifiutare l'aggiornamento non di retrofit sulle build precedenti

Applica il pacchetto OTA completo normale solo alle build con le partizioni dinamiche attivate. 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 di retrofit e un pacchetto OTA completo normale, pertanto il client non rifiuterà il pacchetto completo.

Per impedire al dispositivo di accettare il pacchetto OTA completo, puoi richiedere un passaggio post-installazione per controllare la configurazione del dispositivo esistente. Ad 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 pacchetto OTA normale viene applicato a un dispositivo senza partizioni dinamiche attivate, il client OTA esegue check_dynamic_partitions come passaggio post-installazione e rifiuta l'aggiornamento.