Implementa A/B virtual: Parches

Selecciona los siguientes parches para abordar los siguientes problemas conocidos.

Verifica el espacio asignable correctamente durante la transferencia local

La transferencia de un paquete inalámbrico completo en un dispositivo A/B virtual que tiene una superpartición con un tamaño inferior a *2 * sum(tamaño de los grupos de actualización) puede fallar con el siguiente mensaje en el registro de recuperación /tmp/recovery.log:

The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...

A continuación, se muestra un ejemplo del registro:

[INFO:dynamic_partition_control_android.cc(1020)] Will overwrite existing partitions. Slot A may be unbootable until update finishes!
[...]
[ERROR:dynamic_partition_control_android.cc(803)] The maximum size of all groups with suffix _b (2147483648) has exceeded half of allocatable space for dynamic partitions 1073741824.

Si te encuentras con este problema, selecciona CL 1399393, vuelve a compilar y escribe en la partición de arranque o en la partición de recuperación si el dispositivo no usa la recuperación como arranque.

Se corrigió una falla de segmentación durante la combinación

Después de aplicar una actualización OTA, durante el proceso de combinación de VAB, una llamada a update_engine_client --cancel hace que CleanupPreviousUpdateAction falle. También existe un posible error de puntero no controlado cuando markSlotSuccessful llega tarde.

Esto se resolvió agregando la función StopActionInternal. CleanupPreviousUpdateAction cancela las tareas pendientes cuando se destruye. Mantiene una variable que hace un seguimiento del ID de la tarea pendiente en el bucle de mensajes. En onDestroy, se cancela la tarea pendiente para evitar un error de segmentación.

Asegúrate de que los siguientes cambios estén en tu árbol de origen de Android 11 para corregir las fallas de SIGSEGV en update_engine durante la combinación:

  • CL 1439792 (un requisito previo para la CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (corrige el posible error de puntero no controlado cuando markSlotSuccessful llega tarde)

Evita la combinación prematura de update_engine

Cuando un dispositivo arranca (Android 11 y versiones posteriores) y se completa el arranque, update_engine llama a ScheduleWaitMarkBootSuccessful() y a WaitForMergeOrSchedule(). Esto inicia el proceso de combinación. Sin embargo, el dispositivo se reinicia en la ranura anterior. Como la combinación ya comenzó, el dispositivo no puede iniciarse y deja de funcionar.

Agrega los siguientes cambios a tu árbol de origen. Ten en cuenta que el CL 1664859 es opcional.

  • CL 1439792 (un requisito previo para la CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (corrige el posible error de puntero no controlado cuando markSlotSuccessful llega tarde)
  • CL 1664859 (opcional: agrega unittest para CleanupPreviousUpdateAction)

Asegúrate de que la configuración de dm-verity sea la correcta

En Android 11 y versiones posteriores, los dispositivos se pueden configurar de forma inadvertida con las siguientes opciones de dm-verity:

  • CONFIG_DM_VERITY_AVB=y en el kernel
  • El bootloader configurado para usar cualquier modo de verity (como AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE) sin AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

Con esta configuración del dispositivo, cualquier error de verity daña la partición vbmeta y hace que los dispositivos que no son A/B queden inoperables. Del mismo modo, si se inició una combinación, es posible que los dispositivos A/B también dejen de funcionar. Solo usa el modo de verificación AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

  1. Establece CONFIG_DM_VERITY_AVB=n en el kernel.
  2. Configura los dispositivos para que usen el modo AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

Para obtener más información, consulta la documentación de verity: Cómo controlar errores de dm-verity.

Confirma que el archivo combinado esté configurado correctamente

Si compilas imágenes del sistema y del proveedor por separado, y luego usas merge_target_files para combinarlas, es posible que las configuraciones de Virtual A/B se descarten de forma incorrecta durante el proceso de combinación. Para verificar que las configuraciones de Virtual A/B sean correctas en el archivo de destino combinado, aplica los siguientes parches: CL 2084183 (combina pares clave/valor idénticos en la información de partición dinámica).

Actualiza los componentes necesarios

A partir de Android 13, snapuserd se trasladó del ramdisk del proveedor al ramdisk genérico. Si tu dispositivo se actualiza a Android 13, es posible que tanto el ramdisk del proveedor como el ramdisk genérico contengan una copia de snapuserd. En esta situación, Virtual A/B requiere la copia del sistema de snapuserd. Para asegurarte de que la copia correcta de snapuserd esté en su lugar, aplica CL 2031243 (copia snapuserd en first_stage_ramdisk).