Implementa parches A/B virtuales

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

Verifica el espacio asignable correctamente cuando transfieras contenido lateralmente

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 * suma(tamaño de grupos de actualización)* puede fallar y mostrar 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 te encuentras con este problema, selecciona CL 1399393, vuelve a compilar e instala la partición de inicio o la partición de recuperación en la memoria flash 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 inalámbrica, 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 salvaje cuando markSlotSuccessful llega tarde.

Para resolverlo, se agregó la función StopActionInternal. CleanupPreviousUpdateAction cancela las tareas pendientes en la 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 (requisito previo para el CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancelar tareas pendientes en 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 se inició, el dispositivo no se inicia y deja de funcionar.

Agrega los siguientes cambios al árbol de fuentes. Ten en cuenta que CL 1664859 es opcional.

  • CL 1439792 (requisito previo para el CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancelar tareas pendientes en destrucción)
  • CL 1663460 (se corrigió el posible error de puntero no válido cuando markSlotSuccessful llega tarde)
  • CL 1664859 (opcional; agrega 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 no se puedan usar. Del mismo modo, si comenzó una combinación, es posible que los dispositivos A/B también dejen de funcionar. Usa solo el modo de verificación AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

  1. Establece 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 errores de dm-verity.

Confirma que el archivo combinado esté configurado correctamente

Si compilas imágenes del sistema y del proveedor por separado y 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 A/B virtuales sean correctas en el archivo de destino combinado, aplica los siguientes parches: CL 2084183 (fusiona pares clave-valor idénticos en información de partición dinámica).

Actualiza los componentes necesarios

A partir de Android 13, snapuserd se trasladó del ramdisk del proveedor al 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 esté en su lugar la copia correcta de snapuserd, aplica CL 2031243 (copia snapuserd a first_stage_ramdisk).