Implementar Virtual A/B - parches

Seleccione los siguientes parches para abordar los siguientes problemas conocidos.

Verifique el espacio asignable correctamente al realizar la carga lateral

La instalación de prueba de un paquete OTA completo en un dispositivo virtual A/B que tiene una súper partición con un tamaño inferior a *2 * sum (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 ...

Aquí hay 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, elija CL 1399393 , reconstruya y actualice la partición de arranque o la partición de recuperación si el dispositivo no usa la recuperación como arranque.

Solucione la falla de segmentación durante la fusió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 se bloquee. 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 destruir. Mantiene una variable que rastrea el ID de tarea de la tarea pendiente en el bucle de mensajes. Al destruir, la tarea pendiente se cancela para evitar un error de segmento.

Asegúrese de que los siguientes cambios estén en su árbol de fuentes de Android 11 para corregir los bloqueos 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 (corregir el posible error de puntero salvaje cuando markSlotSuccessful llega tarde)

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

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

Para ver una solución de código de ejemplo, consulte esta CL: CL 1535570 .

Evitar la fusión prematura de update_engine

Cuando un dispositivo arranca (Android 11 y superior), y el arranque se completa, update_engine llama 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 se inicia 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 (corregir 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 la omisión de metadatos

En Android 11 y versiones posteriores, si un dispositivo de almacenamiento tiene una memoria caché de reescritura volátil, bajo ciertas condiciones, los metadatos de una fusió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 combinació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 elimina limpiamente).

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

Consulte lo siguiente para implementar una resolución:

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

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

  • CONFIG_DM_VERITY_AVB=y en el kernel
  • El cargador 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 verity hace que la partición vbmeta se corrompa y hace que los dispositivos que no sean A/B no funcionen. Del mismo modo, si se ha iniciado una fusión, los dispositivos A/B también pueden dejar de funcionar. Utilice únicamente el modo de verdad AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

  1. Establecer 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 práctica, consulte la documentación de verity: Manejo de errores de dm-verity .

Omita el trabajo de verificación en respuesta a un error de E/S durante el apagado del sistema de emergencia

En Android 11 y versiones posteriores, si se llama a un apagado del sistema de emergencia (como en el caso de un apagado térmico), un dispositivo dm puede estar activo mientras que el dispositivo de bloque ya no puede procesar las 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 tránsito, pueden llevar a un estado de corrupción real, que es un error de juicio.

Para omitir el trabajo de verificación en respuesta a un error de E/S cuando el sistema se está apagando, use lo siguiente:

CL 1847875 (Omite el trabajo de verificación 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 de kernel. Esta configuración no es compatible con Virtual A/B y se sabe que causa problemas raros de corrupción de páginas cuando ambos están habilitados juntos.

Para 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 kernels 5.4 y posteriores, el código se eliminó y la opción de configuración no está disponible.

Confirme que el archivo fusionado está configurado correctamente

Si está creando imágenes del sistema e imágenes del proveedor por separado, luego usa merge_target_files para fusionarlos, 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 fusionado, aplique los siguientes parches: CL 2084183 (fusione pares de clave/valor idénticos en información de partición dinámica)

Actualizar los componentes necesarios

A partir de Android 13, snapuserd pasó de ramdisk de proveedor a ramdisk genérico. Si su dispositivo se está actualizando 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 asegurarse de que se haya realizado la copia correcta de snapuserd , aplique CL 2031243 (copie snapuserd en first_stage_ramdisk).