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

Implementando Virtual A / B

Para implementar A / B virtual em um novo dispositivo ou para adaptar um dispositivo iniciado, você deve fazer alterações no código específico do dispositivo.

Construir sinalizadores

Dispositivos que usam virtuais A / B deve ser configurado como um dispositivo A / B e deve lançar com partições dinâmicas .

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

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

Dispositivos de lançamento com a necessidade de A / B virtual só a metade do tamanho da placa muito para BOARD_SUPER_PARTITION_SIZE porque ranhuras B não estão mais em Super. Ou seja, BOARD_SUPER_PARTITION_SIZE deve ser maior ou igual a soma (tamanho dos grupos de atualização) + sobrecarga, o que, por sua vez, deve ser maior ou igual a soma (tamanho de partições) + sobrecarga.

Para habilitar instantâneos compactados com Virtual A / B, herde a seguinte configuração de base:

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

HAL de controle de inicialização

O HAL controle de inicialização fornece uma interface para clientes OTA para os slots de inicialização controle. O Virtual A / B requer uma atualização de versão secundária do HAL de controle de inicialização porque APIs adicionais são necessárias para garantir que o carregador de inicialização esteja protegido durante a atualização / redefinição de fábrica. Veja IBootControl.hal e types.hal para 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 de Fstab

A integridade da partição de metadados é essencial para o processo de inicialização, especialmente logo após a aplicação de uma atualização OTA. Assim, a partição de metadados deve ser verificado antes first_stage_init monta-lo. Para garantir que isso aconteça, adicione a check bandeira fs_mgr para a entrada de /metadata . O seguinte fornece um exemplo:

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

Requisitos de kernel

Para habilitar snapshotting, conjunto CONFIG_DM_SNAPSHOT a true .

Para dispositivos que utilizam F2FS, incluem os f2fs: exportação bandeira FS_NOCOW_FL para usuário patch do kernel para pinagem arquivo correção. Inclua os f2fs: apoio alinhado arquivo preso patch do kernel também.

Virtual A / B depende de recursos adicionais na versão do kernel 4.3: o bit de estado estouro nos snapshot e snapshot-merge alvos. Todos os dispositivos lançados com Android 9 e posterior já devem ter a versão do kernel 4.4 ou posterior.

Para habilitar instantâneos compactados, a versão mínima do kernel suportada é 4.19. Conjunto CONFIG_DM_USER=m ou CONFIG_DM_USER=y . Se estiver usando o anterior (um módulo), o módulo deve ser carregado no ramdisk de primeiro estágio. Isso pode ser feito adicionando a seguinte linha ao Makefile do dispositivo:

BOARD_GENERIC_RAMDISK_KERNEL_MODULES_LOAD := dm-user.ko

Retrofitting em dispositivos com upgrade para Android 11

Ao atualizar para o Android 11, os dispositivos iniciados com partições dinâmicas podem opcionalmente fazer o retrofit virtual A / B. O processo de atualização é basicamente o mesmo para dispositivos que iniciam com A / B virtual, com algumas pequenas diferenças:

  • Localização dos arquivos COW - Para dispositivos de lançamento, o cliente OTA usa todo o espaço vazio disponível na partição Super antes de usar o espaço em /data . Para dispositivos de retrofit, sempre há espaço suficiente no super partição para que o arquivo COW nunca é criado em /data .

  • Sinalizadores de recurso em tempo de compilação - Para dispositivos retrofitting virtual A / B, ambos PRODUCT_VIRTUAL_AB_OTA e PRODUCT_VIRTUAL_AB_OTA_RETROFIT estão definidas para true , conforme mostrado abaixo:

    (call inherit-product, \
        (SRC_TARGET_DIR)/product/virtual_ab_ota_retrofit.mk)
    
  • Tamanho Super partição - Dispositivos de lançamento com um virtual / B pode cortar BOARD_SUPER_PARTITION_SIZE na metade porque ranhuras B não estão na partição super. Dispositivos de montagem posterior de um virtual / B manter o tamanho de idade partição super, assim BOARD_SUPER_PARTITION_SIZE é maior do que ou igual a 2 * soma (tamanho dos grupos de actualização) + sobrecarga, o que por sua vez é maior do que ou igual a 2 * soma (tamanho de partições) + sobrecarga.

Mudanças de bootloader

Durante a etapa de fusão de uma atualização, /data detém apenas toda a instância do sistema operacional Android. Uma vez que os começos de migração, o nativo system , vendor e product partições são incompletos até que a cópia acabamentos. Se o dispositivo for redefinido para os padrões de fábrica durante esse processo, seja por recuperação ou por meio da caixa de diálogo Configurações de sistemas, o dispositivo não poderá ser inicializado.

Antes de apagar /data , concluir a fusão na recuperação ou reversão dependendo do estado do dispositivo:

  • Se a nova compilação foi inicializada com sucesso antes, conclua a migração.
  • Caso contrário, reverta para o slot antigo:
    • Para partições dinâmicas, volte ao estado anterior.
    • Para partições estáticas, defina o slot ativo para o slot antigo.

Tanto o carregador de arranque e fastbootd pode apagar o /data partição, se o dispositivo é desbloqueado. Enquanto fastbootd pode forçar a migração para completar, o bootloader não pode. O bootloader não sabe se deve ou não uma mesclagem está em andamento, ou o que blocos em /data constituem as partições do sistema operacional. Os dispositivos devem evitar que o usuário inadvertidamente torne o dispositivo inoperante (bricking), fazendo o seguinte:

  1. Implementar o HAL controle de inicialização para que o bootloader pode ler o valor definido pelo setSnapshotMergeStatus() método.
  2. Se o status de mesclagem é MERGING , ou se o status de mesclagem é SNAPSHOTTED eo slot mudou para o slot recém-atualizado, em seguida, pede para limpar userdata , metadata , ou a partição armazenar o estado de integração tem de ser rejeitada no bootloader.
  3. Implementar o fastboot snapshot-update cancel comando para que os usuários podem sinalizar para o bootloader que eles querem ignorar esse mecanismo de proteção.
  4. Modificar costume piscar ferramentas ou scripts para emitir fastboot snapshot-update cancel quando piscar o dispositivo inteiro. Isso é seguro porque o flash de todo o dispositivo remove o OTA. Tooling pode detectar este comando em tempo de execução através da implementação de fastboot getvar snapshot-update-status . Este comando ajuda a diferenciar as condições de erro.

Exemplo

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()));
}

Mudanças nas ferramentas do Fastboot

O Android 11 faz as seguintes alterações no protocolo fastboot:

  • getvar snapshot-update-status - retorna o valor que o HAL controle de inicialização comunicadas ao bootloader:
    • Se o estado é MERGING , o bootloader deve retornar merging .
    • Se o estado é SNAPSHOTTED , o bootloader deve retornar snapshotted .
    • Caso contrário, o bootloader deve retornar none .
  • snapshot-update merge - conclui uma operação de mesclagem, a inicialização para recuperação / fastbootd se necessário. Este comando é válido apenas se snapshot-update-status está merging , e só é suportado no fastbootd.
  • snapshot-update cancel - Status merge define o controle de inicialização do HAL para CANCELLED . Este 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 o HAL controle de inicialização deve verificar o status instantâneo mesclagem. Se o status for MERGING ou SNAPSHOTTED , o dispositivo deve abortar a operação.
  • set_active - A set_active comando que altera o slot ativo deve verificar o status instantâneo mesclagem. Se o status for MERGING , o dispositivo deve abortar a operação. O slot de segurança pode ser alterado no SNAPSHOTTED estado.

Essas alterações foram projetadas para evitar que um dispositivo não possa ser inicializado acidentalmente, mas podem ser prejudiciais às ferramentas automatizadas. Quando os comandos são usados como um componente de piscar todas as partições, como a execução fastboot flashall , recomenda-se utilizar o seguinte fluxo:

  1. Consulta getvar snapshot-update-status .
  2. Se merging ou snapshotted , assuntos de snapshot-update cancel .
  3. Prossiga com as etapas piscantes.

Reduzindo os requisitos de armazenamento

Os dispositivos que não têm armazenamento A / B integral atribuído em super, e estão à espera de utilização /data como necessário, são fortemente recomendados para usar a ferramenta de mapeamento de bloco. A ferramenta de mapeamento de bloco mantém a alocação de bloco consistente entre as compilações, reduzindo gravações desnecessárias no instantâneo. Isso está documentado sob Reduzir OTA Tamanho .