Questa pagina è stata tradotta dall'API Cloud Translation.

OTA per dispositivi A/B senza partizioni dinamiche

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

In questa pagina viene descritto come i client OTA ridimensionano le partizioni dinamiche durante un aggiornamento dei dispositivi A/B. è stata lanciata senza le partizioni dinamiche e come i client OTA eseguono l'upgrade ad Android 10.

Premessa

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

In ognuno dei dispositivi a blocchi sono presenti due slot di metadati. Solo uno di metadati in ogni dispositivo a blocchi utilizzato. Ad esempio, Metadata 0 at system_a e Metadata 1 all'indirizzo system_b corrispondono, rispettivamente, alle partizioni negli slot A e B. Alle ore il runtime, indipendentemente dallo slot viene aggiornato.

In questa pagina, le aree di metadati sono chiamate Metadata S (origine) e Metadata T (destinazione). Analogamente, le partizioni sono come system_s, vendor_t e così via.

Per ulteriori informazioni sulle configurazioni del sistema di compilazione, consulta Upgrade dei dispositivi.

Per ulteriori informazioni su come le partizioni appartengono agli gruppi, vedi Da tavolo modifiche alla configurazione per i nuovi dispositivi.

Un esempio di metadati su un dispositivo è:

Dispositivo di blocco fisico 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 barra
- Metadati 1 (non utilizzati)
Dispositivo di blocco fisico 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
  - Barra del gruppo_b
    - Partizione logica (dinamica) vendor_b
    - Partizione logica (dinamica) product_b
    - Altre partizioni aggiornate da barra

Puoi utilizzare lo strumento lpdump in system/extras/partition_tools per eseguire il dump dei metadati il tuo dispositivo. Ad esempio:

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

Adattare un aggiornamento

Sui dispositivi con Android 9 e versioni precedenti, il client OTA presente sul dispositivo non supporta la mappatura delle partizioni dinamiche prima dell'aggiornamento. Un vengono creati ulteriori set di patch per applicare la mappatura direttamente alle partizioni fisiche esistenti.

Il generatore OTA crea il file super.img finale che include i contenuti di tutte le partizioni dinamiche, quindi divide l'immagine in più immagini con le stesse dimensioni dei dispositivi a blocchi fisici corrispondenti a sistema, fornitore e così via. Queste immagini hanno il nome super_system.img, super_vendor.img e così via. Il client OTA applica queste immagini alle partizioni fisiche, anziché che 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 disabilitati automaticamente per queste partizioni quando viene generato il pacchetto di aggiornamento. Consulta Configurare l'installazione post-installazione per ulteriori dettagli.

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 partizioni dinamiche. Gli estremi delle partizioni di origine non si estendono mai tra le partizioni fisiche di destinazione.

Flusso di aggiornamento utilizzando un pacchetto di aggiornamento regolare

Inizializza i metadati della partizione super.
1. Costruire nuovi metadati M da Metadata S (metadati di origine). Ad esempio, se Metadata S utilizza [system_s, vendor_s, product_s] come blocco dispositivi, il nuovo metadato M utilizza [system_t, vendor_t, product_t] come blocco dispositivi mobili. Tutti i gruppi e le partizioni vengono eliminati in M.
2. Aggiungi partizioni e gruppi di destinazione in base al Campo dynamic_partition_metadata nell'aggiornamento del file manifest. La dimensione di ogni partizione è indicata in new_partition_info.
3. Scrivi M in Metadata T.
4. Mappa le partizioni aggiunte sul mapping dei dispositivi come scrivibili.
Applica l'aggiornamento ai dispositivi di blocco.
1. Se necessario, mappa le partizioni di origine sul mapping dei dispositivi di sola lettura. Questa operazione è necessaria 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 nel nell'area annuncio target.
3. Monta le partizioni per eseguire lo script post-installazione, quindi e smontare le partizioni.
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 le partizioni dinamiche, il client OTA applica la suddivisione super.img direttamente sui dispositivi a blocchi. Aggiornamento è simile a un aggiornamento di retrofit. Consulta Retrofit di un aggiornamento per maggiori dettagli.

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 di blocco.

Quando il client OTA riceve un pacchetto di aggiornamento di retrofit, si applica super_system.img con system_b fisico, super_vendor.img sul vendor_b fisico e super_product.img su product_b fisico. Il dispositivo di blocco fisico system_b contiene il token corretto metadati per mappare l'elemento logico system_b, vendor_b e product_b al momento dell'avvio.

Genera pacchetti di aggiornamento

OTA incrementale

Durante la generazione di OTA incrementali per i dispositivi di retrofit, gli aggiornamenti dipende dal fatto che la build di base abbia definito PRODUCT_USE_DYNAMIC_PARTITIONS e PRODUCT_RETROFIT_DYNAMIC_PARTITIONS.

Se la build di base non definisce le variabili, si tratta di un dell'aggiornamento a posteriori. Il pacchetto di aggiornamento contiene la suddivisione super.img e disattiva il passaggio post-installazione.
Se la build di base definisce le variabili, equivale a un tipico con le partizioni dinamiche. Pacchetto di aggiornamento contiene le immagini per le partizioni logiche (dinamiche). La il passaggio post-installazione.

OTA completa

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

$(PRODUCT)-ota-retrofit-$(TAG).zip contiene sempre dividi super.img e disattiva il passaggio post-installazione per l'aggiornamento successivo.
- Viene generato con un argomento aggiuntivo --retrofit_dynamic_partitions alla Script ota_from_target_files.
- Può essere applicato a tutte le build.
$(PRODUCT)-ota-$(TAG).zip contiene immagini logiche per per gli aggiornamenti futuri.
- Applicala solo alle build con partizioni dinamiche in un bucket in cui è abilitato il controllo delle versioni. Consulta i dettagli di seguito per l'applicazione forzata.

Rifiuta l'aggiornamento senza retrofit sulle vecchie build

Applica il pacchetto OTA completo normale solo alle build con partizioni dinamiche abilitate. Se il server OTA è configurato in modo errato ed esegue il push di questi pacchetti su dispositivi con Android 9 o in meno, i dispositivi non si avviano. Il client OTA su Android 9 e in meno non riesce a distinguere un pacchetto OTA di aggiornamento pacchetto OTA completo normale, quindi il client non rifiuterà il pacchetto completo.

Per evitare che il dispositivo accetti il pacchetto OTA completo, puoi: richiedono un passaggio post-installazione per verificare il dispositivo esistente configurazione. 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 abilitate, il client OTA esegue check_dynamic_partitions come passaggio post-installazione rifiuta l'aggiornamento.