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
- Partizione logica (dinamica)
- Gruppo
- Metadati 1 (non utilizzato)
- Metadati 0
- 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
- Partizione logica (dinamica)
- Barra del gruppo_b
- Partizione logica (dinamica)
vendor_b
- Partizione logica (dinamica)
product_b
- Altre partizioni aggiornate da Bar
- Partizione logica (dinamica)
- Gruppo foo_b
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
- Inizializza i metadati della
super
partizione.- 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. - 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 innew_partition_info
. - Scrivi M nei metadati T.
- Mappare le partizioni aggiunte sul mappatore del dispositivo come scrivibili.
- Costruisci nuovi metadati M da metadati S (metadati di origine). Ad esempio, se i metadati S utilizzano [
- Applicare l'aggiornamento sui dispositivi a blocchi.
- 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.
- Applica un aggiornamento completo o delta a tutti i dispositivi a blocchi nello slot di destinazione.
- Montare le partizioni per eseguire lo script post-installazione, quindi 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 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
eproduct_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 sempresuper.img
diviso e disabilita il passaggio post-installazione per l'aggiornamento del retrofit.- Viene generato con un argomento aggiuntivo
--retrofit_dynamic_partitions
allo scriptota_from_target_files
. - Può essere applicato a tutte le build.
- Viene generato con un argomento aggiuntivo
-
$(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.