Implementar o A/B virtual

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Para implementar o A/B virtual em um novo dispositivo ou para retrofitar um dispositivo lançado, é necessário fazer mudanças no código específico do dispositivo.

Flags de build

Os dispositivos que usam o A/B virtual precisam ser configurados como um dispositivo A/B e iniciar com partições dinâmicas.

Para dispositivos iniciados com o A/B virtual, defina-os para herdar a configuração base do dispositivo A/B virtual:

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

Os dispositivos iniciados com A/B virtual precisam de apenas metade do tamanho da placa para BOARD_SUPER_PARTITION_SIZE porque os slots B não estão mais no super. Ou seja, BOARD_SUPER_PARTITION_SIZE precisa ser maior ou igual a soma(tamanho dos grupos de atualização) + overhead, que, por sua vez, precisa ser maior ou igual a soma(tamanho das partições) + overhead.

Para ativar os snapshots compactados com o Virtual A/B no Android 13 e versões mais recentes, herde a seguinte configuração básica:

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

Isso permite snapshots do espaço do usuário com o Virtual A/B usando um método de compressão sem operação. Em seguida, configure o método de compactação para um dos métodos com suporte, zstd e lz4. No Android 15, a compactação pode ser personalizada para atender às necessidades do dispositivo. Para mais informações, consulte Ajustar a compactação.

PRODUCT_VIRTUAL_AB_COMPRESSION_METHOD := lz4
PRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR := 65536

No Android 12, para ativar snapshots compactados com A/B virtual, herde a seguinte configuração básica:

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

Compactação XOR

Para dispositivos que estão fazendo upgrade para o Android 13 e versões mais recentes, o recurso de compactação XOR não é ativado por padrão. Para ativar a compactação XOR, adicione o seguinte ao arquivo .mk do dispositivo.

PRODUCT_VENDOR_PROPERTIES += ro.virtual_ab.compression.xor.enabled=true

A compactação XOR é ativada por padrão para dispositivos que herdam de android_t_baseline.mk.

Mesclagem do espaço do usuário

Na versão moderna do A/B virtual (Android T e versões mais recentes), o processo de mesclagem de snapshots acontece totalmente no espaço do usuário. Essa mudança é possível com o snapuserd e o dm-user. Os dispositivos lançados com o Android 13 e versões mais recentes têm a mesclagem do espaço do usuário ativada por padrão. Para dispositivos mais antigos que estão sendo atualizados, essa propriedade pode ser definida com o seguinte:

PRODUCT_VENDOR_PROPERTIES += ro.virtual_ab.userspace.snapshots.enabled=true

HAL de controle de inicialização

O HAL de controle de inicialização oferece uma interface para que os clientes OTA controlem os slots de inicialização. O A/B virtual requer um upgrade de versão menor do HAL de controle de inicialização, porque APIs adicionais são necessárias para garantir que o carregador de inicialização seja protegido durante a atualização ou redefinição para a configuração original. Consulte IBootControl.hal e types.hal para conferir a versão mais recente da definição 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
}

Mudanças no fstab

A integridade da partição de metadados é essencial para o processo de inicialização, principalmente logo após a aplicação de uma atualização OTA. Portanto, a partição de metadados precisa ser verificada antes que o first_stage_init a monte. Para garantir que isso aconteça, adicione a flag fs_mgr check à entrada de /metadata. Confira um exemplo a seguir:

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

Requisitos do kernel

Para ativar os snapshots, defina CONFIG_DM_SNAPSHOT como true.

Para dispositivos que usam o F2FS, inclua o patch do kernel f2fs: export FS_NOCOW_FL flag to user para corrigir a fixação de arquivos. Inclua o patch do kernel f2fs: support aligned pinned file.

O A/B virtual depende de recursos adicionados na versão 4.3 do kernel: o bit de status overflow nas metas snapshot e snapshot-merge. Todos os dispositivos lançados com o Android 9 e versões mais recentes já precisam ter a versão 4.4 ou mais recente do kernel.

Para ativar os snapshots compactados, a versão mínima do kernel é 4.19. Defina CONFIG_DM_USER=m ou CONFIG_DM_USER=y. Se você usar o primeiro (um módulo), ele precisará ser carregado no ramdisk da primeira etapa. Para isso, adicione a seguinte linha ao Makefile do dispositivo:

BOARD_GENERIC_RAMDISK_KERNEL_MODULES_LOAD := dm-user.ko

Mudanças nas ferramentas do Fastboot

O Android 11 faz as seguintes mudanças no protocolo Fastboot:

• getvar snapshot-update-status: retorna o valor que a HAL de controle de inicialização comunicou ao carregador de inicialização:
  • Se o estado for MERGING, o carregador de inicialização precisará retornar merging.
  • Se o estado for SNAPSHOTTED, o carregador de inicialização precisará retornar snapshotted.
  • Caso contrário, o carregador de inicialização precisa retornar none.
• snapshot-update merge: conclui uma operação de mesclagem, inicializando para recuperação/inicialização rápida, se necessário. Esse comando só é válido se snapshot-update-status for merging e só é compatível com fastbootd.
• snapshot-update cancel: define o status de mesclagem do HAL de controle de inicialização como CANCELLED. Esse comando é inválido quando o dispositivo está bloqueado.
• erase ou wipe: um erase ou wipe de metadata, userdata ou uma partição que contém o status de mesclagem para a HAL de controle de inicialização precisa verificar o status de mesclagem do snapshot. Se o status for MERGING ou SNAPSHOTTED, o dispositivo vai abortar a operação.
• set_active: um comando set_active que muda o slot ativo precisa verificar o status de mesclagem do snapshot. Se o status for MERGING, o dispositivo vai abortar a operação. O slot pode ser alterado com segurança no estado SNAPSHOTTED.

Essas mudanças foram projetadas para evitar que um dispositivo seja inicializado acidentalmente, mas podem atrapalhar as ferramentas automatizadas. Quando os comandos são usados como componente de flash de todas as partições, como a execução de fastboot flashall, é recomendado usar o seguinte fluxo:

1. Consulta getvar snapshot-update-status.
2. Se merging ou snapshotted, emita snapshot-update cancel.
3. Siga as etapas de piscar.

Reduzir os requisitos de armazenamento

É altamente recomendável que os dispositivos que não têm armazenamento A/B completo alocado no super e que esperam usar /data conforme necessário usem a ferramenta de mapeamento de blocos. A ferramenta de mapeamento de blocos mantém a alocação de blocos consistente entre builds, reduzindo gravações desnecessárias no snapshot. Isso está documentado em Reduzir o tamanho do OTA.

Algoritmos de compactação OTA

Os pacotes OTA podem ser ajustados para diferentes métricas de desempenho. O Android oferece vários métodos de compactação com suporte (lz4, zstd e none) que têm complicações entre o tempo de instalação, o uso de espaço de COW, o tempo de inicialização e o tempo de mesclagem de snapshots. A opção padrão ativada para ab virtual com compactação é lz4 compression method.

Ajuste fino da compactação

Os algoritmos de compactação podem ser personalizados ainda mais por dois métodos: nível de compactação (a quantidade de compactação alcançada à custa da velocidade) e fator de compactação (o tamanho máximo da janela com compactação). O nível de compactação está disponível para determinados algoritmos, como zstd, e mudar o nível gera uma compensação entre velocidade e taxa de compactação. O fator de compactação descreve o tamanho máximo da janela de compactação usada durante a instalação OTA. O padrão é definido como 64k, mas pode ser substituído personalizando o parâmetro de build PRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR. Fatores de compressão compatíveis: 4k, 8k, 16k, 32k, 64k, 128k e 256k.

PRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR := 65536

OTA incremental no Pixel 8 Pro

OTA completo no Pixel 8 Pro