Android 10 supporta le partizioni dinamiche, un sistema di partizione dello spazio utente che può creare, ridimensionare ed eliminare le 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 avviati senza il supporto delle partizioni dinamiche e come i client OTA eseguono l'upgrade 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 conservata, quindi non è presente alcuna partizione super
sul dispositivo. I metadati vengono memorizzati in system_a
e system_b
, ma possono essere personalizzati modificando BOARD_SUPER_PARTITION_METADATA_DEVICE
.
In ogni dispositivo di blocco sono presenti due slot per i metadati. Viene utilizzato un solo
scomparto dei metadati in ogni dispositivo di blocco. 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 denominati Metadata S
(origine) e Metadata T (destinazione). Allo stesso modo, le partizioni vengono indicate come system_s
, vendor_t
e così via.
Per ulteriori informazioni sulle configurazioni del sistema di compilazione, consulta Eseguire l'upgrade dei dispositivi.
Per ulteriori informazioni su come le partizioni appartengono ai gruppi di aggiornamento, consulta Modifiche alla configurazione della scheda 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
- Partizione logica (dinamica)
- 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 utilizzati)
- Metadati 0
- 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
- Partizione logica (dinamica)
- Gruppo bar_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. 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 la mappatura delle partizioni dinamiche prima dell'aggiornamento. Viene creato un insieme aggiuntivo 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 i contenuti di tutte le partizioni dinamiche, quindi suddivide l'immagine in più immagini corrispondenti alle dimensioni dei dispositivi di blocco 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é alle partizioni logiche (dinamiche).
Poiché il client OTA non sa come mappare le partizioni dinamiche, tutti i passaggi di post-installazione vengono disattivati automaticamente per queste partizioni quando viene generato il pacchetto di aggiornamento. Per ulteriori dettagli, consulta 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 del retrofit, il client OTA viene aggiornato in modo da funzionare con le partizioni dinamiche. Le estensioni per le partizioni di origine non si estendono mai sulle partizioni fisiche di destinazione.
Flusso di aggiornamento utilizzando un normale pacchetto di aggiornamento
- Inizializza i metadati della partizione
super
.-
Costruisci nuovi metadati M dai metadati S (metadati di origine).
Ad esempio, se i metadati S utilizzano [
system_s
,vendor_s
,product_s
] come dispositivi di blocco, i nuovi metadati M utilizzano [system_t
,vendor_t
,product_t
] come dispositivi di blocco. Tutti i gruppi e le partizioni vengono ignorati in M. -
Aggiungi gruppi e partizioni di destinazione in base al
campo
dynamic_partition_metadata
nel manifest dell'aggiornamento. Le dimensioni di ogni partizione sono disponibili innew_partition_info
. - Scrivi M in Metadati T.
- Mappa le partizioni aggiunte nel mapper del dispositivo come scrivibili.
-
Costruisci nuovi metadati M dai metadati S (metadati di origine).
Ad esempio, se i metadati S utilizzano [
- Applica l'aggiornamento ai dispositivi bloccati.
- Se necessario, mappa le partizioni di origine nel mappatore del dispositivo come di sola lettura. Questo è necessario per il sideload perché le partizioni di origine non sono mappate prima dell'aggiornamento.
- Applica un aggiornamento completo o delta a tutti i dispositivi di blocco nello slot di destinazione.
- Monta le partizioni per eseguire lo script di post-installazione, quindi smontale.
- Scollega le partizioni di destinazione.
Flusso di aggiornamento utilizzando un pacchetto di aggiornamento retrofit
Se il pacchetto di aggiornamento del retrofit viene applicato a un dispositivo su cui sono già attivate le partizioni dinamiche, il client OTA applica direttamente il file super.img
suddiviso sui dispositivi di blocco. Il flusso di aggiornamento è simile a un aggiornamento di retrofit. Per maggiori dettagli, consulta Eseguire il retrofit di un aggiornamento.
Ad esempio, supponiamo quanto segue:
- Lo slot A è quello attivo.
-
system_a
contiene i metadati attivi nello slot 0. -
system_a
,vendor_a
eproduct_a
vengono utilizzati come dispositivi di blocco.
Quando il client OTA riceve un pacchetto di aggiornamento per il 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 di blocco fisico system_b
contiene i metadati corretti per mappare system_b
, vendor_b
e product_b
logici all'avvio.
Generare pacchetti di aggiornamento
OTA incrementale
Quando vengono generati OTA incrementali per i dispositivi di retrofit, gli aggiornamenti
dipendono dal fatto che la build di base definisce 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 split
super.img
e disattiva il passaggio di post-installazione. - Se la build di base definisce le variabili, si tratta di un aggiornamento tipico con partizioni dinamiche. Il pacchetto di aggiornamento contiene le immagini per le partizioni logiche (dinamiche). È possibile attivare il passaggio di post-installazione.
OTA completa
Per i dispositivi sottoposti a retrofit vengono generati due pacchetti OTA completi.
-
$(PRODUCT)-ota-retrofit-$(TAG).zip
contiene sempre splitsuper.img
e disattiva 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 aggiornamenti futuri.- Applica questa opzione solo alle build con le partizioni dinamiche attivate. Consulta i dettagli di seguito sull'applicazione di questa norma.
Rifiutare l'aggiornamento non retrofit sulle build precedenti
Applica il pacchetto OTA completo standard 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 riescono ad avviarsi. Il client OTA su Android 9 e versioni precedenti non è in grado di distinguere un pacchetto OTA di retrofit da un normale pacchetto OTA completo, pertanto il client non rifiuterà il pacchetto completo.
Per impedire al dispositivo di accettare il pacchetto OTA completo, puoi richiedere un passaggio di post-installazione per controllare la configurazione esistente del dispositivo. 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 le partizioni dinamiche abilitate, il client OTA esegue check_dynamic_partitions
come passaggio di post-installazione e rifiuta l'aggiornamento.