Descripción general de A/B virtual

Android tiene dos mecanismos de actualización: actualizaciones A/B (continuas) y actualizaciones no A/B. Para reducir la complejidad del código y mejorar el proceso de actualización, en Android 11 los dos mecanismos se unifican a través de A/B virtual para brindar actualizaciones perfectas a todos los dispositivos con un costo de almacenamiento minimizado. Android 12 ofrece la opción de compresión virtual A/B para comprimir particiones instantáneas. Tanto en Android 11 como en Android 12, se aplica lo siguiente:

• Las actualizaciones virtuales A/B son perfectas como las actualizaciones A/B. Las actualizaciones virtuales A/B minimizan el tiempo que un dispositivo está fuera de línea e inutilizable.
• Las actualizaciones virtuales A/B se pueden revertir . Si el nuevo sistema operativo no arranca, los dispositivos vuelven automáticamente a la versión anterior.
• Las actualizaciones virtuales A/B utilizan un mínimo de espacio adicional al duplicar solo las particiones que utiliza el gestor de arranque. Se crean instantáneas de otras particiones actualizables.

Nota: Virtual A/B es un requisito de GMS en dispositivos que se inician con Android 11 y versiones posteriores.

Antecedentes y terminología

Esta sección define la terminología y describe la tecnología que admite A/B virtual.

Mapeador de dispositivos

Device-mapper es una capa de bloques virtuales de Linux que se usa a menudo en Android. Con las particiones dinámicas , las particiones como /system son una pila de dispositivos en capas:

• En la parte inferior de la pila está la superpartición física (por ejemplo, /dev/block/by-name/super ).
• En el medio hay un dispositivo dm-linear , que especifica qué bloques de la superpartición forman la partición dada. Esto aparece como /dev/block/mapper/system_[a|b] en un dispositivo A/B, o /dev/block/mapper/system en un dispositivo que no es A/B.
• En la parte superior se encuentra un dispositivo dm-verity , creado para particiones verificadas. Este dispositivo verifica que los bloques en el dispositivo dm-linear estén firmados correctamente. Aparece como /dev/block/mapper/system-verity y es la fuente del punto de montaje /system .

La Figura 1 muestra cómo se ve la pila debajo del punto de montaje /system .

Figura 1. Apilar debajo del punto de montaje /system

instantánea-dm

Virtual A/B se basa en dm-snapshot , un módulo asignador de dispositivos para tomar instantáneas del estado de un dispositivo de almacenamiento. Cuando se utiliza dm-snapshot , hay cuatro dispositivos en juego:

• El dispositivo base es el dispositivo del que se toma la instantánea. En esta página, el dispositivo base es siempre una partición dinámica, como sistema o proveedor.
• El dispositivo de copia en escritura (COW), para registrar cambios en el dispositivo base. Puede ser de cualquier tamaño, pero debe ser lo suficientemente grande para acomodar todos los cambios en el dispositivo base.
• El dispositivo de instantánea se crea utilizando el destino snapshot . Las escrituras en el dispositivo de instantáneas se escriben en el dispositivo COW. Lee desde el dispositivo de instantánea leído desde el dispositivo base o desde el dispositivo COW, dependiendo de si la instantánea ha cambiado los datos a los que se accede.
• El dispositivo de origen se crea utilizando el destino snapshot-origin . Lee en el dispositivo de origen leído directamente desde el dispositivo base. Escribe en el dispositivo de origen, escribe directamente en el dispositivo base, pero se realiza una copia de seguridad de los datos originales escribiendo en el dispositivo COW.

Figura 2. Mapeo de dispositivos para dm-snapshot

Instantáneas comprimidas

En Android 12 y versiones posteriores, debido a que los requisitos de espacio en la partición /data pueden ser altos, puede habilitar instantáneas comprimidas en su compilación para abordar los requisitos de espacio más altos de la partición /data .

Las instantáneas comprimidas virtuales A/B se crean sobre los siguientes componentes que están disponibles en Android 12 y versiones posteriores:

• dm-user , un módulo del kernel similar a FUSE que permite que el espacio de usuario implemente dispositivos de bloque.
• snapuserd , un demonio de espacio de usuario para implementar un nuevo formato de instantánea.

Estos componentes permiten la compresión. Los otros cambios necesarios realizados para implementar las capacidades de instantáneas comprimidas se detallan en las siguientes secciones: formato COW para instantáneas comprimidas , dm-user y Snapuserd .

Formato COW para instantáneas comprimidas

En Android 12 y versiones posteriores, las instantáneas comprimidas utilizan el formato COW. Similar al formato integrado del kernel utilizado para instantáneas sin comprimir, el formato COW para las instantáneas comprimidas tiene secciones alternas de metadatos y datos. Los metadatos del formato original solo permitían operaciones de reemplazo : reemplazar el bloque X en la imagen base con el contenido del bloque Y en la instantánea. El formato COW de instantáneas comprimidas es más expresivo y admite las siguientes operaciones:

• Copiar : el bloque X en el dispositivo base debe reemplazarse con el bloque Y en el dispositivo base.
• Reemplazar : el bloque X en el dispositivo base debe reemplazarse con el contenido del bloque Y en la instantánea. Cada uno de estos bloques está comprimido en gz.
• Cero : el bloque X en el dispositivo base debe reemplazarse con todos ceros.
• XOR : El dispositivo COW almacena bytes comprimidos XOR entre el bloque X y el bloque Y. (Disponible en Android 13 y superior).

Las actualizaciones OTA completas consisten únicamente en operaciones de reemplazo y cero . Las actualizaciones OTA incrementales también pueden tener operaciones de copia .

usuario dm en Android 12

El módulo del kernel dm-user permite que userspace implemente dispositivos de bloque de mapeador de dispositivos. Una entrada de la tabla dm-user crea un dispositivo misceláneo en /dev/dm-user/<control-name> . Un proceso userspace puede sondear el dispositivo para recibir solicitudes de lectura y escritura del kernel. Cada solicitud tiene un búfer asociado para que el espacio de usuario se complete (para una lectura) o se propague (para una escritura).

El módulo del kernel dm-user proporciona una nueva interfaz visible para el usuario para el kernel que no forma parte del código base ascendente de kernel.org. Hasta que sea así, Google se reserva el derecho de modificar la interfaz dm-user en Android.

snapuserd

El componente de espacio de usuario snapuserd para dm-user implementa la compresión virtual A/B.

En la versión sin comprimir de Virtual A/B (ya sea en Android 11 y versiones anteriores, o en Android 12 sin la opción de instantánea comprimida), el dispositivo COW es un archivo sin formato. Cuando la compresión está habilitada, COW funciona como un dispositivo dm-user , que está conectado a una instancia del demonio snapuserd .

El kernel no utiliza el nuevo formato COW. Entonces, el componente snapuserd traduce solicitudes entre el formato COW de Android y el formato integrado del kernel:

Figura 3. Diagrama de flujo de snapuserd como traductor entre los formatos Android y Kernel COW

Esta traducción y descompresión nunca ocurre en el disco. El componente snapuserd intercepta las lecturas y escrituras de COW que ocurren en el kernel y las implementa usando el formato COW de Android.

Compresión XOR

Para dispositivos que se inician con Android 13 y versiones posteriores, la función de compresión XOR, que está habilitada de forma predeterminada, permite que las instantáneas del espacio de usuario almacenen bytes comprimidos XOR entre bloques antiguos y nuevos. Cuando solo se cambian unos pocos bytes en un bloque en una actualización virtual A/B, el esquema de almacenamiento de compresión XOR utiliza menos espacio que el esquema de almacenamiento predeterminado porque las instantáneas no almacenan bytes completos de 4K. Esta reducción en el tamaño de la instantánea es posible porque los datos XOR contienen muchos ceros y son más fáciles de comprimir que los datos de bloque sin procesar. En los dispositivos Pixel, la compresión XOR reduce el tamaño de la instantánea entre un 25% y un 40%.

Para dispositivos que se actualizan a Android 13 y superior, la compresión XOR debe estar habilitada. Para obtener más información, consulte Compresión XOR .

Procesos de compresión virtual A/B

Esta sección proporciona detalles sobre el proceso de compresión virtual A/B utilizado en Android 13 y Android 12.

Lectura de metadatos (Android 12)

Nota: Esta sección se aplica solo a Android 12.

Los metadatos son construidos por un demonio snapuserd . Los metadatos son principalmente un mapeo de dos ID, de 8 bytes cada uno, que representan los sectores que se fusionarán. En dm-snapshot se llama disk_exception .

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

Se utiliza una excepción de disco cuando un fragmento de datos antiguo se reemplaza por uno nuevo.

Un demonio snapuserd lee el archivo COW interno a través de la biblioteca COW y construye los metadatos para cada una de las operaciones COW presentes en el archivo COW.

Las lecturas de metadatos se inician desde la dm-snapshot en el kernel cuando se crea el dispositivo dm- snapshot .

La siguiente figura proporciona un diagrama de secuencia de la ruta de IO para la construcción de metadatos.

Figura 4. Flujo de secuencia para la ruta IO en la construcción de metadatos

Fusión (Android 12)

Nota: Esta sección se aplica solo a Android 12.

Una vez que se completa el proceso de inicio, el motor de actualización marca la ranura como inicio exitoso e inicia la fusión cambiando el destino dm-snapshot al destino dm-snapshot-merge .

dm-snapshot recorre los metadatos e inicia una fusión IO para cada excepción de disco. A continuación se muestra una descripción general de alto nivel de la ruta de fusión de E/S.

Figura 5. Descripción general de la ruta de fusión de E/S

Si el dispositivo se reinicia durante el proceso de fusión, la fusión se reanuda en el siguiente reinicio y se completa.

Capas del mapeador de dispositivos

Para dispositivos que se inician con Android 13 y versiones posteriores, los procesos de instantánea y fusión de instantáneas en la compresión virtual A/B los realiza el componente de espacio de usuario snapuserd . Para dispositivos que se actualizan a Android 13 y superior, esta función debe estar habilitada. Para obtener más información, consulte Fusión de espacio de usuario .

A continuación se describe el proceso de compresión virtual A/B:

1. El marco monta la partición /system de un dispositivo dm-verity , que está apilado encima de un dispositivo dm-user . Esto significa que cada E/S del sistema de archivos raíz se enruta a dm-user .
2. dm-user enruta la E/S al demonio snapuserd del espacio de usuario, que maneja la solicitud de E/S.
3. Cuando se completa la operación de fusión, el marco colapsa dm-verity encima de dm-linear ( system_base ) y elimina dm-user .

Figura 6. Proceso de compresión virtual A/B

El proceso de combinación de instantáneas se puede interrumpir. Si el dispositivo se reinicia durante el proceso de fusión, el proceso de fusión se reanuda después del reinicio.

transiciones iniciales

Al arrancar con instantáneas comprimidas, el init de primera etapa debe iniciar snapuserd para montar particiones. Esto plantea un problema: cuando se carga y aplica sepolicy , snapuserd se coloca en el contexto incorrecto y sus solicitudes de lectura fallan, con denegaciones de selinux.

Para solucionar esto, snapuserd realiza la transición al mismo tiempo que init , de la siguiente manera:

1. La primera etapa init inicia snapuserd desde el disco RAM y guarda un descriptor de archivo abierto en una variable de entorno.
2. La primera etapa init cambia el sistema de archivos raíz a la partición del sistema y luego ejecuta la copia del sistema de init .
3. La copia del sistema de init lee la política combinada en una cadena.
4. Init invoca mlock() en todas las páginas respaldadas por ext4. Luego desactiva todas las tablas de mapeador de dispositivos para dispositivos de instantáneas y detiene snapuserd . Después de esto, está prohibido leer particiones, ya que hacerlo provoca un punto muerto.
5. Usando el descriptor de apertura de la copia del disco ram de snapuserd , init reinicia el demonio con el contexto selinux correcto. Se reactivan las tablas de mapeador de dispositivos para dispositivos de instantáneas.
6. Init invoca munlockall() : es seguro realizar IO nuevamente.

Uso del espacio

La siguiente tabla proporciona una comparación del uso de espacio para diferentes mecanismos OTA que utilizan el sistema operativo y los tamaños de OTA de Pixel.

Impacto del tamaño	no A/B	A/B	Virtual A/B	Virtual A/B (comprimido)
Imagen original de fábrica	4,5 GB súper (imagen 3,8 G + 700 M reservados) ^1	9GB super (3.8G + 700M reservados, para dos ranuras)	4,5 GB súper (imagen 3,8 G + 700 M reservados)	4,5 GB súper (imagen 3,8 G + 700 M reservados)
Otras particiones estáticas	/cache	Ninguno	Ninguno	Ninguno
Almacenamiento adicional durante OTA (espacio devuelto después de aplicar OTA)	1,4 GB en/datos	0	3,8 GB ^2 activados/datos	2,1 GB ^2 activados/datos
Almacenamiento total requerido para aplicar OTA	5.9GB ^3 (super y datos)	9GB (súper)	8.3GB ^3 (super y datos)	6.6GB ^3 (super y datos)

¹ Indica un diseño supuesto basado en el mapeo de píxeles.

² Se supone que la nueva imagen del sistema tiene el mismo tamaño que la original.

³ El requisito de espacio es transitorio hasta el reinicio.

Para implementar Virtual A/B o utilizar capacidades de instantáneas comprimidas, consulte Implementación de Virtual A/B.