O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Visão geral do Virtual A / B

O Android tem dois mecanismos de atualização: atualizações A / B (contínuas) e atualizações não A / B. Para reduzir a complexidade do código e aprimorar o processo de atualização, no Android 11 os dois mecanismos são unificados por meio de A / B virtual para trazer atualizações contínuas para todos os dispositivos com um custo mínimo de armazenamento. O Android 12 oferece a opção de compactação Virtual A / B para compactar partições instantâneas. Tanto no Android 11 quanto no Android 12, aplica-se o seguinte:

  • Atualizações virtuais A / B são contínuas, como atualizações de A / B. As atualizações virtuais A / B minimizam o tempo que um dispositivo fica offline e inutilizável.
  • Atualizações virtuais A / B pode ser revertida. Se o novo sistema operacional falhar ao inicializar, os dispositivos serão revertidos automaticamente para a versão anterior.
  • Atualizações virtuais A / B usar um mínimo de espaço extra duplicando apenas as partições que são usados pelo bootloader. Outras partições atualizáveis são snapshotted .

Antecedentes e terminologia

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

Mapeador de dispositivos

O mapeador de dispositivos é 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 é a partição de super física (por exemplo, /dev/block/by-name/super ).
  • No meio é um dm-linear dispositivo, especificando que os blocos na forma de super partição a partição dada. Isto aparece como /dev/block/mapper/system_[a|b] sobre um dispositivo de A / B, ou /dev/block/mapper/system de um dispositivo não-A / B.
  • No topo reside um dm-verity dispositivo, criado para partições verificados. Este dispositivo verifica que os blocos na dm-linear dispositivo são assinados corretamente. Ele aparece como /dev/block/mapper/system-verity e é a fonte do /system ponto de montagem.

Figura 1 mostra que a pilha sob o /system montagem olhares ponto afins.

Partition stacking underneath system

Figura 1. Pilha sob o / sistema de montagem ponto

dm-snapshot

Virtual A / B depende de dm-snapshot , um módulo de dispositivo de mapeador para snapshotting o estado de um dispositivo de armazenamento. Ao usar dm-snapshot , existem quatro dispositivos em jogo:

  • O dispositivo de base é o dispositivo que está snapshotted. Nesta página, o dispositivo base é sempre uma partição dinâmica, como sistema ou fornecedor.
  • O dispositivo copy-on-write (COW), para a exploração madeireira alterações ao dispositivo de base. Pode ser de qualquer tamanho, mas deve ser grande o suficiente para acomodar todas as alterações no dispositivo base.
  • O dispositivo de captura de imagem é criado usando a snapshot alvo. As gravações no dispositivo de instantâneo são gravadas no dispositivo COW. Leituras do dispositivo de instantâneo lidas do dispositivo base ou do dispositivo COW, dependendo se os dados acessados ​​foram alterados pelo instantâneo.
  • O dispositivo de origem é criado usando o snapshot-origin -alvo. Lê para o dispositivo de origem lida diretamente do dispositivo de base. As gravações no dispositivo de origem são gravadas diretamente no dispositivo base, mas o backup dos dados originais é feito gravando-se no dispositivo COW.

Device mapping for dm-snapshot

Figura 2. Dispositivo para mapeamento dm-instantâneo

Instantâneos compactados

Em Android 12, porque os requisitos de espaço no /data partição pode ser alto, você pode ativar instantâneos comprimido em sua construção para atender as necessidades de espaço superiores do /data partição.

Instantâneos compactados A / B virtuais são desenvolvidos com base em dois novos componentes que estão disponíveis no Android 12:

  • dm-user , um módulo de kernel semelhante ao FUSÍVEL que permite espaço de usuário para aplicar dispositivos de bloco.
  • snapuserd , um daemon userspace para implementar um novo formato de snapshot.

Esses componentes permitem a compressão. As outras alterações necessárias feitas para implementar os instantâneos compactados capacidades são dadas nas próximas seções: formato COW para instantâneos compactados , dm-usuário , e Snapuserd .

Formato COW para instantâneos compactados

No Android 12, os instantâneos compactados usam um novo formato COW. Semelhante ao formato embutido do kernel usado para instantâneos não compactados, o formato COW para os instantâneos compactados tem seções alternadas de metadados e dados. Os metadados do formato original só é permitido para "substituir" as operações de: Substituir bloco X na imagem de base com o conteúdo do bloco de Y no instantâneo. O formato COW de instantâneos compactados é mais expressivo e suporta três operações:

  • Cópia - Bloco X no dispositivo de base deve ser substituída com Y bloco no dispositivo de base.
  • Substituir - Bloco X no dispositivo de base deve ser substituído com o conteúdo do bloco de Y no instantâneo. Cada um desses blocos é compactado com gz.
  • Zero - Bloco X no dispositivo de base deve ser substituída com todos os zeros.

Atualizações completa OTA consistem em substituir e apenas zero de operações. Atualizações incrementais OTA pode, adicionalmente, tem operações de cópia.

dm-user no Android 12

O módulo do kernel-utilizador dm permite userspace para aplicar dispositivos de blocos dispositivo de mapeador. A entrada da tabela do usuário dm cria um dispositivo miscellaneous sob /dev/dm-user/<control-name> . A userspace processo pode consultar o dispositivo para receber solicitações de leitura e gravação do kernel. Cada solicitação tem um buffer associado para o espaço do usuário preencher (para uma leitura) ou propagar (para uma gravação).

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

Snapuserd

O snapuserd componente userspace para dm-user implementos Virtual A / B de compressão.

Na versão não compactada do Virtual A / B (no Android 11 e inferior ou no Android 12 sem a opção de instantâneo compactado), o dispositivo COW é um arquivo bruto. Quando a compressão está activado, as funções de vaca no lugar como um dm-user dispositivo, o qual está ligado a uma instância do snapuserd daemon.

O kernel não usa o novo formato COW. Assim, o snapuserd componente traduz solicitações entre o formato COW Android eo kernel está embutido formato:

Snapuserd component translating requests between Android COW format and kernel built-in format

Figura 3. Diagrama de Fluxo de snapuserd como tradutor entre Android e Kernel formatos COW

Esta tradução e descompressão nunca ocorre no disco. Os snapuserd componente intercepta a vaca lê e escreve que ocorrem no kernel e implementa-las usando o formato COW Android.

Processos de compressão virtual A / B

Essas seções fornecem detalhes sobre os processos usados ​​na compactação Virtual A / B: leitura de metadados, fusão e realização de transições init.

Lendo metadados

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

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

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

A Snapuserd daemon lê o arquivo COW interno através da biblioteca COW e constrói os metadados para cada uma das operações COW presente no arquivo COW.

Metadados lê são iniciadas a partir da dm-snapshot no kernel quando o dm- snapshot dispositivo é criado.

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

Sequence diagram, IO path for metadata construction

Fluxo Sequência Figura 4. para o caminho IO na construção metadados

Mesclando

Uma vez que o processo de inicialização estiver concluída, as marcas de motores atualização do caça-níqueis como arranque bem sucedido e inicia a mesclagem por mudar o dm-snapshot de destino para o dm-snapshot-merge -alvo.

dm-snapshot caminha através da metadados e inicia uma mala IO para cada excepção disco. Uma visão geral de alto nível do caminho IO de mesclagem é mostrada abaixo.

Merge IO path

Figura 5. Mesclar visão caminho IO

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

Transições de inicialização

Ao inicializar com instantâneos compactados, a inicialização de primeiro estágio deve começar snapuserd montar partições. Isto coloca um problema: Quando sepolicy é carregada e executada, snapuserd é colocado no contexto errado, e seus pedidos de leitura falhar, com negações do SELinux.

Para resolver isso, snapuserd transições em lock-passo com init , como segue:

  1. Primeira fase init lançamentos snapuserd do disco RAM, e salva um arquivo-descritor abertos a isso em uma variável de ambiente.
  2. Uma primeira fase init muda o sistema de ficheiros 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ê o sepolicy combinado em uma string.
  4. Init Invoca mlock() páginas em todos os ext4-backed. Em seguida, desativa todas as tabelas device-mapper para dispositivos instantâneo, e pára snapuserd . Depois disso, é proibido ler nas partições, pois isso causa um deadlock.
  5. Usando o descritor aberto para a cópia ramdisk de snapuserd , init relança o daemon com o contexto SELinux correto. As tabelas do mapeador de dispositivos para dispositivos de instantâneo são reativadas.
  6. Invoca INIT munlockall() - que é seguro para executar IO novamente.

Uso do espaço

A tabela a seguir fornece uma comparação do uso de espaço para diferentes mecanismos OTA usando o sistema operacional e os tamanhos OTA do Pixel.

Impacto de tamanho não A / B A / B Virtual A / B Virtual A / B (comprimido)
Imagem Original de Fábrica 4.5GB super (imagem 3,8 g + 700M reservado) 1 9GB super (3.8G + 700M reservados, para dois slots) 4.5 GB super (imagem 3.8G + 700M reservados) 4.5 GB super (imagem 3.8G + 700M reservados)
Outras partições estáticas / cache Nenhum Nenhum Nenhum
Armazenamento adicional Durante OTA (espaço devolvidos após a aplicação OTA) 1,4 GB em / dados 0 3.8GB 2 em / dados 2,1 GB 2 em / dados
Armazenamento total necessário para aplicar OTA 5.9GB 3 (super e dados) 9 GB (super) 8,3 GB 3 (super e dados) 6.6GB 3 (super e dados)

Indica uma disposição assumida com base em mapeamento de pixel.

2 Assume nova imagem do sistema é o mesmo tamanho que o original.

3 Necessidade de espaço é transitória até reiniciar.

Para implementar Virtual A / B, ou para usar recursos de snapshot comprimido, consulte Implementando Virtual A / B