Implementando Virtual A/B

Para implementar A/B virtual en un nuevo dispositivo, o para actualizar un dispositivo iniciado, debe realizar cambios en el código específico del dispositivo.

Construir banderas

Los dispositivos que usan A/B virtual deben configurarse como un dispositivo A/B y deben iniciarse con particiones dinámicas .

Para los dispositivos que se inician con A/B virtual, configúrelos para que hereden la configuración base del dispositivo A/B virtual:

$(call inherit-product, \
    $(SRC_TARGET_DIR)/product/virtual_ab_ota.mk)

Los dispositivos que se inician con A/B virtual solo necesitan la mitad del tamaño de la placa para BOARD_SUPER_PARTITION_SIZE porque las ranuras B ya no están en super. Es decir, BOARD_SUPER_PARTITION_SIZE debe ser mayor o igual que sum(size of update groups) + overhead , que, a su vez, debe ser mayor o igual que sum(size of partitions) + overhead .

Para habilitar instantáneas comprimidas con Virtual A/B, herede la siguiente configuración base:

$(call inherit-product, \
    $(SRC_TARGET_DIR)/product/virtual_ab_ota/compression.mk)

Control de arranque HAL

La HAL de control de inicio proporciona una interfaz para que los clientes OTA controlen las ranuras de inicio. Virtual A/B requiere una actualización de la versión menor de la HAL de control de arranque porque se necesitan API adicionales para garantizar que el cargador de arranque esté protegido durante el restablecimiento de fábrica/parpadeo. Consulte IBootControl.hal y types.hal para obtener la versión más reciente de la definición de HAL.

// hardware/interfaces/boot/1.1/types.hal
enum MergeStatus : uint8_t {
    NONE, UNKNOWN, SNAPSHOTTED, MERGING, CANCELLED };

// hardware/interfaces/boot/1.1/IBootControl.hal
package android.hardware.boot@1.1;
interface IBootControl extends @1.0::IBootControl {
    setSnapshotMergeStatus(MergeStatus status)
        generates (bool success);
    getSnapshotMergeStatus()
        generates (MergeStatus status);
}

// Recommended implementation

Return<bool> BootControl::setSnapshotMergeStatus(MergeStatus v) {
    // Write value to persistent storage
    // e.g. misc partition (using libbootloader_message)
    // bootloader rejects wipe when status is SNAPSHOTTED
    // or MERGING
}

Cambios en Fstab

La integridad de la partición de metadatos es esencial para el proceso de arranque, especialmente justo después de aplicar una actualización OTA. Por lo tanto, la partición de metadatos debe verificarse antes de que first_stage_init la monte. Para asegurarse de que esto suceda, agregue el indicador check fs_mgr a la entrada de /metadata . Lo siguiente proporciona un ejemplo:

/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount,check

Requisitos del núcleo

Para habilitar la creación de instantáneas, establezca CONFIG_DM_SNAPSHOT en true .

Para los dispositivos que usan F2FS, incluya el indicador f2fs: export FS_NOCOW_FL al parche del kernel del usuario para corregir la fijación de archivos. Incluya el f2fs: también admite el parche del kernel de archivos anclados alineados .

Virtual A/B se basa en las funciones agregadas en la versión 4.3 del kernel: el bit de estado de desbordamiento en la snapshot y los objetivos snapshot-merge . Todos los dispositivos que se inicien con Android 9 y versiones posteriores ya deberían tener la versión de kernel 4.4 o posterior.

Para habilitar las instantáneas comprimidas, la versión de kernel mínima admitida es 4.19. Establezca CONFIG_DM_USER=m o CONFIG_DM_USER=y . Si usa el primero (un módulo), el módulo debe cargarse en el ramdisk de primera etapa. Esto se puede lograr agregando la siguiente línea al Makefile del dispositivo:

BOARD_GENERIC_RAMDISK_KERNEL_MODULES_LOAD := dm-user.ko

Adaptación en dispositivos que se actualizan a Android 11

Nota: Opcionalmente, puede actualizar A/B virtual en dispositivos que se actualicen a Android 11. Los dispositivos que se actualizaron a particiones dinámicas no pueden actualizar A/B virtual.

Al actualizar a Android 11, los dispositivos que se lanzaron con particiones dinámicas pueden actualizar opcionalmente A/B virtual. El proceso de actualización es prácticamente el mismo que para los dispositivos que se inician con A/B virtual, con algunas diferencias menores:

• Ubicación de los archivos COW : para los dispositivos de lanzamiento, el cliente OTA usa todo el espacio vacío disponible en la súper partición antes de usar el espacio en /data . Para dispositivos actualizados, siempre hay suficiente espacio en la súper partición para que el archivo COW nunca se cree en /data .

• Indicadores de características en tiempo de construcción : para los dispositivos que actualizan A/B virtual, tanto PRODUCT_VIRTUAL_AB_OTA como PRODUCT_VIRTUAL_AB_OTA_RETROFIT se establecen en true , como se muestra a continuación:

  (call inherit-product, \
      (SRC_TARGET_DIR)/product/virtual_ab_ota_retrofit.mk)
  

• Tamaño de superpartición: los dispositivos que se inician con A/B virtual pueden reducir BOARD_SUPER_PARTITION_SIZE a la mitad porque las ranuras B no están en la superpartición. Los dispositivos que actualizan A/B virtual mantienen el tamaño de superpartición anterior, por lo que BOARD_SUPER_PARTITION_SIZE es mayor o igual a 2 * sum (tamaño de los grupos de actualización) + sobrecarga , que a su vez es mayor o igual a 2 * sum (tamaño de las particiones) + sobrecarga .

Cambios en el cargador de arranque

Durante el paso de fusión de una actualización, /data contiene la única instancia completa del sistema operativo Android. Una vez que comienza la migración, las particiones de product , vendor y system nativo están incompletas hasta que finaliza la copia. Si el dispositivo se restablece de fábrica durante este proceso, ya sea por recuperación o a través del cuadro de diálogo de configuración del sistema, entonces el dispositivo no se podrá iniciar.

Antes de borrar /data , finalice la combinación en recuperación o reversión según el estado del dispositivo:

• Si la nueva compilación se inició correctamente antes, finalice la migración.
• De lo contrario, retroceda a la ranura anterior:
  • Para particiones dinámicas, retroceda al estado anterior.
  • Para particiones estáticas, establezca la ranura activa en la ranura anterior.

Tanto el gestor de arranque como fastbootd pueden borrar la partición /data si el dispositivo está desbloqueado. Si bien fastbootd puede forzar la finalización de la migración, el gestor de arranque no puede. El cargador de arranque no sabe si una combinación está en progreso o no, o qué bloques en /data constituyen las particiones del sistema operativo. Los dispositivos deben evitar que el usuario inutilice el dispositivo sin saberlo (bloqueo) al hacer lo siguiente:

1. Implemente el control de arranque HAL para que el gestor de arranque pueda leer el valor establecido por el método setSnapshotMergeStatus() .
2. Si el estado de fusión es MERGING , o si el estado de fusión es SNAPSHOTTED y la ranura ha cambiado a la ranura recién actualizada, las solicitudes para borrar los datos de userdata , metadata o la partición que almacena el estado de fusión deben rechazarse en el gestor de arranque.
3. Implemente el fastboot snapshot-update cancel para que los usuarios puedan indicarle al gestor de arranque que desean omitir este mecanismo de protección.
4. Modifique las herramientas o secuencias de comandos de fastboot snapshot-update cancel cuando se flashea todo el dispositivo. Esto es seguro de emitir porque flashear todo el dispositivo elimina la OTA. Las herramientas pueden detectar este comando en tiempo de ejecución implementando fastboot getvar snapshot-update-status . Este comando ayuda a diferenciar entre condiciones de error.

Ejemplo

struct VirtualAbState {
    uint8_t StructVersion;
    uint8_t MergeStatus;
    uint8_t SourceSlot;
};

bool ShouldPreventUserdataWipe() {
    VirtualAbState state;
    if (!ReadVirtualAbState(&state)) ...
    return state.MergeStatus == MergeStatus::MERGING ||
           (state.MergeStatus == MergeStatus::SNAPSHOTTED &&
            state.SourceSlot != CurrentSlot()));
}

Cambios en las herramientas de Fastboot

Android 11 realiza los siguientes cambios en el protocolo fastboot:

• getvar snapshot-update-status — Devuelve el valor que el HAL de control de arranque comunicó al gestor de arranque:
  • Si el estado es MERGING , el gestor de arranque debe devolver la merging .
  • Si el estado es SNAPSHOTTED , el gestor de arranque debe devolver una snapshotted .
  • De lo contrario, el gestor de arranque debe devolver none .
• snapshot-update merge : completa una operación de fusión, arrancando en recuperación/arranque rápido si es necesario. Este comando solo es válido si snapshot-update-status se está merging y solo se admite en fastbootd.
• snapshot-update cancel : establece el estado de combinación de HAL de control de inicio en CANCELLED . Este comando no es válido cuando el dispositivo está bloqueado.
• erase o wipe : un erase o wipe de metadata , datos de userdata o una partición que contiene el estado de fusión para el control de arranque HAL debe verificar el estado de fusión de la instantánea. Si el estado es MERGING o SNAPSHOTTED , el dispositivo debe cancelar la operación.
• set_active : un comando set_active que cambia la ranura activa debe verificar el estado de fusión de la instantánea. Si el estado es MERGING , el dispositivo debe cancelar la operación. La ranura se puede cambiar de forma segura en el estado SNAPSHOTTED .

Estos cambios están diseñados para evitar que un dispositivo no se pueda iniciar accidentalmente, pero pueden interrumpir las herramientas automatizadas. Cuando los comandos se usan como un componente del flasheo de todas las particiones, como ejecutar fastboot flashall , se recomienda usar el siguiente flujo:

1. Consulta getvar snapshot-update-status .
2. Si se merging o toma una snapshotted , emita snapshot-update cancel .
3. Continúe con los pasos intermitentes.

Nota: Cuando una herramienta está realizando un borrado único de un dispositivo, o un cambio de número de ranura único usando set_active , no use el flujo anterior, para asegurarse de que las protecciones en el dispositivo (ya sea en el cargador de arranque o fastbootd) prohíban una operación que podría hacer que el dispositivo no pueda arrancar.

Reducción de los requisitos de almacenamiento

Se recomienda encarecidamente que utilicen la herramienta de mapeo de bloques en los dispositivos que no tienen almacenamiento A/B completo asignado en super y esperan usar /data según sea necesario. La herramienta de mapeo de bloques mantiene la asignación de bloques consistente entre compilaciones, lo que reduce las escrituras innecesarias en la instantánea. Esto se documenta en Reducción del tamaño de OTA .