Esta página se ha traducido con Cloud Translation API.

OTA para dispositivos A/B sin particiones dinámicas

Android 10 admite particiones dinámicas , un sistema de partición del espacio de usuario que puede crear, cambiar el tamaño y destruir particiones durante las actualizaciones inalámbricas (OTA).

Esta página describe cómo los clientes OTA cambian el tamaño de las particiones dinámicas durante una actualización para dispositivos A/B que se iniciaron sin soporte para particiones dinámicas y cómo los clientes OTA se actualizan a Android 10.

Fondo

Durante una actualización de un dispositivo A/B para admitir particiones dinámicas, la tabla de particiones GUID (GPT) del dispositivo se conserva, por lo que no hay ninguna super en el dispositivo. Los metadatos se almacenan en system_a y system_b , pero esto se puede personalizar cambiando BOARD_SUPER_PARTITION_METADATA_DEVICE .

En cada uno de los dispositivos de bloque, hay dos ranuras para metadatos. Sólo se utiliza una ranura de metadatos en cada dispositivo de bloque. Por ejemplo, los metadatos 0 en system_a y los metadatos 1 en system_b corresponden a particiones en las ranuras A y B, respectivamente. En tiempo de ejecución, no importa qué ranura se esté actualizando.

En esta página, las ranuras de metadatos se denominan Metadatos S (fuente) y Metadatos T (destino). De manera similar, las particiones se denominan system_s , vendor_t , etc.

Para obtener más información sobre las configuraciones del sistema de compilación , consulte Actualización de dispositivos .

Para obtener más información sobre cómo las particiones pertenecen a los grupos de actualización , consulte Cambios en la configuración de la placa para nuevos dispositivos.

Un ejemplo de metadatos en un dispositivo es:

Dispositivo de bloqueo físico system_a
- Metadatos 0
  - Grupo foo_a
    - system_a de partición lógica (dinámica)_a
    - Partición lógica (dinámica) product_services_a
    - Otras particiones actualizadas por Foo
  - Grupo bar_a
    - Partición lógica (dinámica) vendor_a
    - Partición lógica (dinámica) product_a
    - Otras particiones actualizadas por Bar
- Metadatos 1 (no utilizado)
Dispositivo de bloque físico system_b
- Metadatos 0 (no utilizado)
- Metadatos 1
  - Grupo foo_b
    - system_b de partición lógica (dinámica)_b
    - Partición lógica (dinámica) product_services_b
    - Otras particiones actualizadas por Foo
  - grupo bar_b
    - Partición lógica (dinámica) vendor_b
    - Partición lógica (dinámica) product_b
    - Otras particiones actualizadas por Bar

Puede utilizar la herramienta lpdump en system/extras/partition_tools para volcar los metadatos en su dispositivo. Por ejemplo:

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

Actualizar una actualización

En dispositivos con Android 9 y versiones anteriores, el cliente OTA del dispositivo no admite la asignación de particiones dinámicas antes de la actualización. Se crea un conjunto adicional de parches para que la asignación se pueda aplicar directamente a las particiones físicas existentes.

El generador OTA crea el archivo super.img final que contiene el contenido de todas las particiones dinámicas y luego divide la imagen en varias imágenes que coinciden con los tamaños de los dispositivos de bloques físicos correspondientes al sistema, proveedor, etc. Estas imágenes se denominan super_system.img , super_vendor.img , etc. El cliente OTA aplica estas imágenes a las particiones físicas, en lugar de aplicar las imágenes a las particiones lógicas (dinámicas).

Debido a que el cliente OTA no sabe cómo asignar particiones dinámicas, todos los pasos posteriores a la instalación se desactivan automáticamente para estas particiones cuando se genera el paquete de actualización. Consulte Configuración posterior a la instalación para obtener más detalles.

El flujo de actualización es el mismo que en Android 9.

Antes de la actualización:

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

Después de la actualización:

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

Actualizaciones futuras después de la modernización

Después de la actualización, el cliente OTA se actualiza para funcionar con particiones dinámicas. Las extensiones de las particiones de origen nunca abarcan las particiones físicas de destino.

Flujo de actualización mediante un paquete de actualización regular

Inicialice los metadatos de la super .
1. Construya nuevos metadatos M a partir de Metadatos S (metadatos de origen). Por ejemplo, si los metadatos S usan [ system_s , vendor_s , product_s ] como dispositivos de bloque, entonces los nuevos metadatos M usan [ system_t , vendor_t , product_t ] como dispositivos de bloque. Todos los grupos y particiones se descartan en M.
2. Agregue grupos de destino y particiones de acuerdo con el dynamic_partition_metadata en el manifiesto de actualización. El tamaño de cada partición se puede encontrar en new_partition_info .
3. Escriba M en metadatos T.
4. Asigne las particiones agregadas en el asignador de dispositivos como escribibles.
Aplique la actualización en los dispositivos bloqueados.
1. Si es necesario, asigne las particiones de origen en el asignador de dispositivos como de solo lectura. Esto es necesario para la descarga porque las particiones de origen no están asignadas antes de la actualización.
2. Aplique una actualización completa o delta a todos los dispositivos de bloque en la ranura de destino.
3. Monte las particiones para ejecutar el script posterior a la instalación y luego desmonte las particiones.
Desasignar las particiones de destino.

Flujo de actualización mediante un paquete de actualización de actualización

Si el paquete de actualización de actualización se aplica en un dispositivo que ya habilita particiones dinámicas, el cliente OTA aplica el archivo super.img dividido en dispositivos de bloque directamente. El flujo de actualización es similar a una actualización de actualización. Consulte Modernización de una actualización para obtener más detalles.

Por ejemplo, suponga lo siguiente:

La ranura A es la ranura activa.
system_a contiene los metadatos activos en la ranura 0.
system_a , vendor_a y product_a se utilizan como dispositivos de bloque.

Cuando el cliente OTA recibe un paquete de actualización de actualización, aplica super_system.img en system_b físico, super_vendor.img en vendor_b físico y super_product.img en product_b físico. El dispositivo de bloque físico system_b contiene los metadatos correctos para asignar el system_b lógico, vendor_b y product_b en el momento del arranque.

Generar paquetes de actualización

OTA incremental

Al generar OTA incrementales para dispositivos modernizados, las actualizaciones dependen de si la compilación base define o no PRODUCT_USE_DYNAMIC_PARTITIONS y PRODUCT_RETROFIT_DYNAMIC_PARTITIONS .

Si la compilación base no define las variables, se trata de una actualización de actualización. El paquete de actualización contiene el archivo super.img dividido y desactiva el paso posterior a la instalación.
Si la compilación base define las variables, esto es lo mismo que una actualización típica con particiones dinámicas. El paquete de actualización contiene las imágenes de las particiones lógicas (dinámicas). El paso posterior a la instalación se puede habilitar.

OTA completa

Se generan dos paquetes OTA completos para dispositivos modernizados.

$(PRODUCT)-ota-retrofit-$(TAG).zip siempre contiene split super.img y desactiva el paso posterior a la instalación para la actualización de actualización.
- Se genera con un argumento adicional --retrofit_dynamic_partitions al script ota_from_target_files .
- Se puede aplicar a todas las construcciones.
$(PRODUCT)-ota-$(TAG).zip contiene imágenes lógicas para futuras actualizaciones.
- Aplique esto solo a compilaciones con particiones dinámicas habilitadas. Consulte los detalles a continuación sobre cómo hacer cumplir esto.

Rechazar actualización sin modernización en compilaciones antiguas

Aplique el paquete OTA completo normal solo a compilaciones con particiones dinámicas habilitadas. Si el servidor OTA está configurado incorrectamente y envía estos paquetes a dispositivos con Android 9 o inferior, los dispositivos no arrancan. El cliente OTA en Android 9 y versiones anteriores no puede distinguir entre un paquete OTA actualizado y un paquete OTA completo normal, por lo que el cliente no rechazará el paquete completo.

Para evitar que el dispositivo acepte el paquete OTA completo, puede requerir un paso posterior a la instalación para verificar la configuración existente del dispositivo. Por ejemplo:

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 \

Cuando el paquete OTA normal se aplica en un dispositivo sin particiones dinámicas habilitadas, el cliente OTA ejecuta check_dynamic_partitions como paso posterior a la instalación y rechaza la actualización.