Implementar Virtual A/B - parches

Seleccione los siguientes parches para solucionar los siguientes problemas conocidos.

Verifique el espacio asignable correctamente al realizar la carga lateral

La descarga de un paquete OTA completo en un dispositivo virtual A/B que tiene una superpartición con un tamaño menor que *2 * suma (tamaño de los grupos de actualización)* puede fallar con 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 ...

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 encuentra este problema, seleccione CL 1399393 , reconstruya y actualice la partición de inicio o la partición de recuperación si el dispositivo no utiliza la recuperación como inicio.

Corregir error de segmentación durante la fusión

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

Esto se resolvió agregando la función StopActionInternal . CleanupPreviousUpdateAction cancela las tareas pendientes al destruirlas. Mantiene una variable que rastrea el ID de la tarea pendiente en el bucle de mensajes. Al destruirse, la tarea pendiente se cancela para evitar un error de segmentación.

Asegúrese de que los siguientes cambios estén en su árbol de fuentes de Android 11 para corregir fallas SIGSEGV en update_engine durante la fusión:

  • CL 1439792 (un requisito previo para CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : cancelar tareas pendientes al destruir)
  • CL 1663460 (corrige el posible error de puntero salvaje cuando markSlotSuccessful llega tarde)

Corrija el cambio de ranura incorrecto de VAB, publique la actualización de OTA

En Android 11 y versiones posteriores, no sincronizar un interruptor de ranura en un dispositivo después de una actualización OTA puede dejar el dispositivo en un estado inutilizable. Si la implementación de cambio de ranura de su IBootControl HAL realiza escrituras, debe eliminar esas escrituras inmediatamente. Si las escrituras no se vacían y el dispositivo se reinicia después de que comienza la fusión, pero antes de que el hardware pueda borrar la escritura del interruptor de ranura, el dispositivo puede volver a la ranura anterior y no arrancar.

Para obtener una solución de código de ejemplo, consulte este CL: CL 1535570 .

Evitar la fusión prematura de update_engine

Cuando se inicia un dispositivo (Android 11 y superior) y se completa el inicio, update_engine llama a ScheduleWaitMarkBootSuccessful() y WaitForMergeOrSchedule() . Esto inicia el proceso de fusión. Sin embargo, el dispositivo se reinicia en la ranura anterior. Debido a que la fusión ya comenzó, el dispositivo no arranca y deja de funcionar.

Agregue los siguientes cambios a su árbol de fuentes. Tenga en cuenta que CL 1664859 es opcional.

  • CL 1439792 (un requisito previo para CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : cancelar tareas pendientes al destruir)
  • CL 1663460 (corrige el posible error de puntero salvaje cuando markSlotSuccessful llega tarde)
  • CL 1664859 (opcional: agregue unittest para CleanupPreviousUpdateAction )

Evite la pérdida o corrupción de datos debido a metadatos omitidos

En Android 11 y versiones posteriores, si un dispositivo de almacenamiento tiene una caché de reescritura volátil, bajo ciertas condiciones, los metadatos de una combinación completa se omiten, lo que resulta en pérdida o corrupción de datos.

Condiciones:

  1. Después de finalizar una operación de fusión de un conjunto de excepciones, se invocó merge_callback() .
  2. Los metadatos se actualizaron en el dispositivo COW que rastrea la finalización de la fusión. (Esta actualización del dispositivo COW se descarga limpiamente).

Resultado: el sistema falló debido a que la memoria caché del dispositivo de almacenamiento de la fusión reciente no se vació.

Consulte lo siguiente para implementar una resolución:

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

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

  • CONFIG_DM_VERITY_AVB=y en el kernel
  • El gestor de arranque configurado para usar cualquier modo de verdad (como AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE ), sin AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

Con esta configuración de dispositivo, cualquier error de verdad hace que la partición vbmeta se corrompa y deje inoperables los dispositivos que no son A/B. De manera similar, si se ha iniciado una fusión, los dispositivos A/B también podrían dejar de funcionar. Utilice únicamente el modo de verdad AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

  1. Establezca CONFIG_DM_VERITY_AVB=n en el kernel
  2. Configure los dispositivos para usar el modo AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO en su lugar.

Para obtener más información y como cuestión de práctica, consulte la documentación de verity: Manejo de errores de dm-verity .

Omitir el trabajo real en respuesta a un error de E/S durante el apagado de emergencia del sistema

En Android 11 y versiones posteriores, si se solicita un apagado de emergencia del sistema (como en el caso de un apagado térmico), un dispositivo dm puede estar activo mientras que el dispositivo de bloqueo ya no puede procesar solicitudes de E/S. En este estado, los errores de E/S manejados por nuevas solicitudes de E/S de dm, o por aquellas que ya están en proceso, pueden llevar a un estado de corrupción de verdad, lo cual es un error de cálculo.

Para omitir el trabajo real en respuesta a un error de E/S cuando el sistema se está apagando, utilice lo siguiente:

CL 1847875 (omite el trabajo real en respuesta a un error de E/S durante el apagado)

Asegúrese de que DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED esté desactivado

Los dispositivos Android Go que ejecutan el kernel 4.19 o anterior pueden tener DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y en su configuración del kernel. Esta configuración no es compatible con Virtual A/B y se sabe que causa problemas poco comunes de corrupción de páginas cuando ambos se habilitan juntos.

Para los kernels 4.19 y anteriores, deshabilítelo configurando CONFIG_DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=n en la configuración del kernel.

Para los kernels 5.4 y posteriores, el código se eliminó y la opción de configuración no está disponible.

Confirme que el archivo combinado esté configurado correctamente

Si está creando imágenes del sistema y de proveedores por separado y luego utiliza merge_target_files para fusionarlas, es posible que las configuraciones virtuales A/B se eliminen incorrectamente durante el proceso de fusión. Para verificar que las configuraciones virtuales A/B sean correctas en el archivo de destino combinado, aplique los siguientes parches: CL 2084183 (combina pares clave/valor idénticos en información de partición dinámica)

Actualizar los componentes necesarios

A partir de Android 13, snapuserd se ha movido del disco ram del proveedor al disco ram genérico. Si su dispositivo se actualiza a Android 13, es posible que tanto el disco ram del proveedor como el disco ram genérico contengan una copia de snapuserd . En esta situación, Virtual A/B requiere la copia del sistema de snapuserd . Para asegurarse de que esté instalada la copia correcta de snapuserd , aplique CL 2031243 (copie snapuserd a first_stage_ramdisk).