Implementa A/B virtual: Parches

Selecciona los siguientes parches para abordar los problemas conocidos que se indican a continuación.

Verifica el espacio asignable correctamente durante la transferencia

Transferencia de un paquete inalámbrico completo a un dispositivo A/B virtual que tiene un la partición con un tamaño inferior a *2 * suma(tamaño de grupos de actualización)* puede fallar por lo siguiente 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 ...

Este es 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 encuentras este problema, selecciona CL 1399393, vuelve a compilar y escribe en la partición de inicio o de recuperación si el dispositivo no usa la recuperación como inicio.

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, se realizará una llamada a update_engine_client --cancel hace que CleanupPreviousUpdateAction falle. R También existe un posible error de puntero comodín cuando markSlotSuccessful llega tarde.

Para resolver este problema, se agregó la función StopActionInternal. CleanupPreviousUpdateAction cancela las tareas pendientes en proceso de destrucción. Mantiene una variable que realiza un seguimiento del ID de la tarea pendiente en el bucle de mensajes. En la destrucción, se cancela la tarea pendiente para evitar la falla de segmento.

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 como requisito previo para CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: Cancela las tareas pendientes en la destrucción)
  • CL 1663460 (corregir el posible error de puntero salvaje cuando markSlotSuccessful llegue tarde)

Evita la combinación prematura de update_engine

Cuando se inicia un dispositivo (Android 11 y versiones posteriores) y se completa el inicio, update_engine llama a ScheduleWaitMarkBootSuccessful() y 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 y deja de funcionar.

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

  • CL 1439792 (requisito previo para el CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: Cancela las tareas pendientes en la destrucción)
  • CL 1663460 (corregir el posible error de puntero salvaje cuando markSlotSuccessful llegue tarde)
  • CL 1664859 (opcional - agregar unittest para CleanupPreviousUpdateAction)

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

En Android 11 y versiones posteriores, los dispositivos se pueden configurar por error 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 hace que la partición vbmeta se dañe y que los dispositivos que no son A/B dejen de funcionar. De manera similar, si se inició una combinación, los dispositivos A/B también podrían dejar de funcionar. Usa solo el modo de verificación AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

  1. Configura CONFIG_DM_VERITY_AVB=n en el kernel.
  2. En su lugar, 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 manejar dm-verity Errores

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 A/B virtuales se descarten de forma incorrecta durante el proceso de combinación. Para verificar que las configuraciones de A/B virtual sean correctas en el archivo de destino combinado, aplica los siguientes parches: CL 2084183 (combina pares de clave/valor idénticos en la información de partición dinámica).

Actualiza los componentes necesarios

A partir de Android 13, se movió snapuserd del ramdisk del proveedor al genérico ramdisk Si tu dispositivo se actualiza a Android 13, es posible que el ramdisk del proveedor y 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).