Visão geral do A/B virtual

O Android tem dois mecanismos de atualização: atualizações A/B (ininterruptas) e atualizações não A/B. Para reduzir a complexidade do código e melhorar o processo de atualização, no Android 11, a dois mecanismos são unificados por meio do A/B virtual para oferecer atualizações contínuas a todos e dispositivos com custo de armazenamento minimizado. Android 12 oferece a opção de compactação A/B virtual para compactar partições com snapshots. No Android 11 e 12, os requisitos a seguir se aplicam:

• As atualizações A/B virtuais são integradas, assim como as atualizações A/B. Atualizações A/B virtuais minimizar o tempo em que um dispositivo fica off-line e inutilizável.
• As atualizações A/B virtuais podem ser revertidas. Se ocorrer uma falha na inicialização do novo SO, os dispositivos são revertidos automaticamente para a versão anterior.
• As atualizações A/B virtuais usam um mínimo de espaço extra, duplicando apenas os que são usadas pelo carregador de inicialização. Outras partições atualizáveis são instantâneo.

.

Observação: o A/B virtual é um requisito do GMS em dispositivos lançados com o Android 11 e superiores.

Contexto e terminologia

Esta seção define a terminologia e descreve a tecnologia que oferece suporte A/B virtual.

Mapeador do dispositivo

O mapeador de dispositivo é uma camada de bloco virtual do Linux usada com frequência no Android. Com partições dinâmicas, partições como /system são uma pilha de dispositivos em camadas:

• Na parte inferior da pilha está a partição super física (por exemplo, /dev/block/by-name/super).
• No meio está um dispositivo dm-linear, especificando quais blocos no super da partição especificada. Ele aparece como /dev/block/mapper/system_[a|b] em um dispositivo A/B ou /dev/block/mapper/system em um dispositivo não A/B.
• Na parte de cima, está um dispositivo dm-verity, criado para partições verificadas. Este dispositivo verifica se os bloqueios do dispositivo dm-linear estão assinados corretamente. Ele aparece como /dev/block/mapper/system-verity e é a origem do ponto de montagem /system.

A Figura 1 mostra a aparência da pilha abaixo do ponto de montagem /system.

Figura 1. Empilhar no ponto de montagem /system

dm-snapshot

O A/B virtual depende do dm-snapshot, um módulo mapeador de dispositivo para criar snapshots do o estado atual de um dispositivo de armazenamento. Ao usar dm-snapshot, há quatro dispositivos em reproduzir:

• O dispositivo base é aquele que tem um snapshot. Nesta página, a base dispositivo é sempre uma partição dinâmica, como o sistema ou fornecedor.
• O dispositivo copy-on-write (COW), para registrar alterações no dispositivo base. Ela pode ter qualquer tamanho, mas deve ser grande o suficiente para acomodar todas as alterações no do dispositivo de base.
• O dispositivo snapshot é criado usando o destino snapshot. Escreve no dispositivo de instantâneo são gravadas no dispositivo COW. Faz leituras no snapshot leitura do dispositivo base ou do dispositivo COW, dependendo do se os dados acessados foram alterados pelo snapshot.
• O dispositivo origin é criado usando o destino snapshot-origin. Leitura para o dispositivo de origem lê diretamente do dispositivo base. Grava na origem gravação do dispositivo diretamente no dispositivo de base, mas os dados originais são salvos em backup gravando no dispositivo COW.

Figura 2. Mapeamento de dispositivo para dm-snapshot

Instantâneos compactados

No Android 12 e em versões mais recentes, como os requisitos de espaço a partição /data for alta, será possível ativar snapshots compactados na build para atender aos requisitos de espaço maior da partição /data.

Os snapshots compactados A/B virtuais são criados com base nos seguintes componentes disponíveis no Android 12 e versões mais recentes:

• dm-user, um módulo do kernel semelhante ao FUSE, que permite o espaço do usuário para implementar dispositivos em blocos.
• snapuserd, um daemon do espaço do usuário para implementar um novo snapshot .

Esses componentes ativam a compactação. As outras mudanças necessárias feitas implementar os recursos de snapshots compactados são fornecidos nas próximas seções: formato COW para snapshots compactados, dm-user e Snapuserd.

Formato COW para snapshots compactados

No Android 12 e versões mais recentes, os snapshots compactados usam uma formato COW. Semelhante ao formato integrado do kernel usado para arquivos descompactados snapshots, o formato COW para os snapshots compactados tem seções alternadas de metadados e dados. Os metadados do formato original só são permitidos para replace operações: substitua o bloco X na imagem de base pelo conteúdo do bloco Y no snapshot. O formato COW de snapshots compactados é mais expressivo e oferece suporte às seguintes operações:

• Cópia: o bloco X no dispositivo de base precisa ser substituído pelo bloco Y em no dispositivo base.
• Substituir: o bloco X no dispositivo de base precisa ser substituído pelo conteúdo. do bloco Y no snapshot. Cada um desses blocos é compactado em gz.
• Zero: o bloco X no dispositivo de base precisa ser substituído por todos os zeros.
• XOR: o dispositivo COW armazena bytes compactados XOR entre os blocos X e bloco Y. Disponível no Android 13 e versões mais recentes.

As atualizações OTA completas consistem em apenas operações replace e zero. incremental As atualizações OTA também podem ter operações de cópia.

dm-user no Android 12

O módulo do kernel dm-user permite que o userspace implemente o bloco device-mapper dispositivos. Uma entrada de tabela dm-user cria um dispositivo diverso sob /dev/dm-user/<control-name>: Um processo userspace pode pesquisar o dispositivo para recebem solicitações de leitura e gravação do kernel. Cada solicitação tem uma configuração para que o espaço do usuário seja preenchido (para uma leitura) ou propagado (para uma gravação).

O módulo do kernel dm-user fornece uma nova interface visível ao usuário para o kernel. que não faz parte da base de código upstream do kernel.org. Até lá, o Google reserva-se o direito de modificar a interface do dm-user no Android.

Snapuserd

O componente snapuserd do espaço do usuário para dm-user implementa o A/B virtual compactação.

Na versão descompactada do A/B virtual (no Android 11 e versões anteriores no Android 12 sem a opção de snapshot compactado), o dispositivo COW é um arquivo bruto. Quando a compactação está ativada, as funções COW como um dispositivo dm-user, que está conectado a uma instância do snapuserd.

O kernel não usa o novo formato COW. Portanto, o componente snapuserd converte solicitações entre o formato COW do Android e o kernel integrado formato:

Figura 3. Diagrama de fluxo do Snapuserd como tradutor entre o Android e o Kernel Formatos COW

Essas conversões e descompactações nunca ocorrem no disco. O snapuserd intercepta as leituras e gravações de COW que ocorrem no kernel e os implementa usando o formato COW do Android.

Compactação XOR

Para dispositivos lançados com o Android 13 e versões mais recentes, o O recurso de compactação XOR, que é ativado por padrão, ativa o espaço do usuário snapshots para armazenar bytes compactados XOR entre blocos antigos e novos. Quando apenas alguns bytes em um bloco são alterados em uma atualização A/B virtual, a função esquema de armazenamento por compactação usa menos espaço do que o esquema de armazenamento padrão porque snapshots não armazenam 4.000 bytes completos. Essa redução no tamanho do snapshot é possível porque os dados XOR contêm muitos zeros e são mais fáceis de compactar do que brutos. e blocos de dados. Em dispositivos Pixel, a compactação XOR reduz o tamanho do snapshot em 25% para 40%.

Para dispositivos que estão fazendo upgrade para o Android 13 e versões mais recentes, o XOR Compactação precisa estar ativada. Para mais detalhes, consulte XOR compactação.

Processos virtuais de compactação A/B

Esta seção fornece detalhes sobre o processo de compactação A/B virtual usado no Android 13 e Android 12.

Como ler metadados (Android 12)

Observação: esta seção se aplica apenas ao Android 12.

Os metadados são construídos por um daemon snapuserd. Os metadados são principalmente uma mapeamento de dois IDs, 8 bytes cada, que representam os setores a serem mesclados. Em dm-snapshot, ele é chamado de disk_exception.

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

Uma exceção de disco é usada quando um bloco de dados antigo é substituído por um novo.

Um daemon snapuserd lê o arquivo interno COW pela biblioteca COW e constrói os metadados de cada uma das operações COW presentes no arquivo COW.

As leituras de metadados são iniciadas no dm-snapshot no kernel quando o dispositivo dm- snapshot é criado.

A figura abaixo fornece um diagrama de sequência para o caminho de E/S de metadados construção.

Figura 4. Fluxo de sequência para o caminho de E/S na construção de metadados

Mesclagem (Android 12)

Observação: esta seção se aplica apenas ao Android 12.

Quando o processo de inicialização é concluído, o mecanismo de atualização marca o slot como inicialização bem-sucedido e inicia a mesclagem alternando o destino dm-snapshot para o Meta de dm-snapshot-merge.

dm-snapshot percorre os metadados e inicia uma E/S de mesclagem para cada disco exceção. Uma visão geral de alto nível do caminho de E/S de mesclagem é mostrada abaixo.

Figura 5. Visão geral do caminho de E/S de mesclagem

Se o dispositivo for reinicializado durante o processo de mesclagem, ela será retomada no na próxima reinicialização e a mesclagem estará concluída.

Camadas do mapeador de dispositivo

Para dispositivos lançados com o Android 13 e versões mais recentes, o são executados processos de snapshots e mesclagem de snapshots na compactação A/B virtual. pelo componente snapuserd do espaço do usuário. Para dispositivos que estão fazendo upgrade para o Android 13 e superiores, esse recurso precisa estar ativado. Para detalhes, consulte Espaço do usuário mesclagem.

Veja a seguir a descrição do processo de compactação A/B virtual:

1. O framework monta a partição /system de um dispositivo dm-verity. que é empilhada sobre um dispositivo dm-user. Isso significa que toda E/S do sistema de arquivos raiz é roteado para dm-user.
2. dm-user encaminha a E/S para o daemon snapuserd do espaço do usuário, que processa a solicitação de E/S.
3. Quando a operação de mesclagem é concluída, o framework recolhe dm-verity na a parte superior do dm-linear (system_base) e remove dm-user.

Figura 6. Processo de compactação A/B virtual

O processo de mesclagem de snapshots pode ser interrompido. Se o dispositivo for reinicializado durante o processo de mesclagem será retomado após a reinicialização.

Transições de inicialização

Na inicialização com snapshots compactados, o init de primeiro estágio precisa ser iniciado snapuserd para ativar partições. Isso representa um problema: quando sepolicy é carregado. e aplicada, o snapuserd é colocado no contexto errado, e as solicitações de leitura dele com negações selinux.

Para resolver isso, a snapuserd faz a transição em conjunto com init, desta forma:

1. O init de primeiro estágio inicia o snapuserd no ramdisk e salva uma descritor de arquivo a ele em uma variável de ambiente.
2. O init de primeiro estágio alterna o sistema de arquivos raiz para a partição do sistema. em seguida, executa a cópia do sistema de init.
3. A cópia do sistema de init lê a sepolicy combinada em uma string.
4. Init invoca mlock() em todas as páginas com suporte de ext4. Em seguida, ele desativa todas Device-mapper para dispositivos de snapshot e interrompe snapuserd. Depois disso é proibido ler partições, porque isso causa um impasse.
5. Como usar o descritor aberto na cópia do ramdisk de snapuserd, init reinicia o daemon com o contexto selinux correto. Tabelas de mapeador de dispositivo para dispositivos de snapshot são reativados.
6. A inicialização invoca munlockall(), ou seja, é seguro realizar a E/S novamente.

Uso do espaço

A tabela a seguir fornece uma comparação do uso do espaço para diferentes OTAs que usam os tamanhos de SO e OTA do Pixel.

Impacto no tamanho	não A/B	A/B	A/B virtual	A/B virtual (compactado)
Imagem original de fábrica	Super 4,5 GB (imagem de 3,8 G + 700 mi de reserva)^1	Super 9 GB (3,8 GB + 700 mi reservados, para dois slots)	Super 4,5 GB (imagem de 3,8 G + 700 mi de espaço reservados)	Super 4,5 GB (imagem de 3,8 G + 700 mi de espaço reservados)
Outras partições estáticas	/cache	Nenhum	Nenhum	Nenhum
Armazenamento adicional durante a OTA (espaço retornado após a aplicação do OTA)	1,4 GB em /data	0	3,8 GB^2em /data	2,1 GB^2em /data
Total de armazenamento necessário para aplicar OTA	5,9 GB^3 (superior e dados)	9GB (super)	8,3 GB^3 (superior e dados)	6,6 GB^3 (superior e dados)

¹Indica o layout presumido com base no mapeamento de pixels.

² Pressupõe que a nova imagem do sistema tem o mesmo tamanho que a original.

³O requisito de espaço é temporário até a reinicialização.

Para implementar o A/B virtual ou usar os recursos de snapshot compactados, consulte Como implementar o A/B virtual