Implementar A/B virtual: patches

Escolha os seguintes patches para resolver os problemas conhecidos a seguir.

Verificar o espaço alocável corretamente durante o sideload

O sideload de um pacote OTA completo em um dispositivo A/B virtual com uma superpartição menor que *2 * soma(tamanho dos grupos de atualização)* pode falhar com o seguinte no registro de recuperação /tmp/recovery.log:

The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...

Confira um exemplo do registro:

[INFO:dynamic_partition_control_android.cc(1020)] Will overwrite existing partitions. Slot A may be unbootable until update finishes!
[...]
[ERROR:dynamic_partition_control_android.cc(803)] The maximum size of all groups with suffix _b (2147483648) has exceeded half of allocatable space for dynamic partitions 1073741824.

Se você encontrar esse problema, escolha CL 1399393, recrie e faça o flash da partição de inicialização ou de recuperação se o dispositivo não usar a recuperação como inicialização.

Corrigir falha de segmentação durante a mesclagem

Após a aplicação de uma atualização OTA, durante o processo de mesclagem do VAB, uma chamada para update_engine_client --cancel faz com que o CleanupPreviousUpdateAction falhe. Um possível erro de ponteiro wild também existe quando markSlotSuccessful chega atrasado.

Isso foi resolvido com a adição da função StopActionInternal. CleanupPreviousUpdateAction cancela tarefas pendentes na destruição. Ele mantém uma variável que rastreia o ID da tarefa pendente no loop de mensagens. Na destruição, a tarefa pendente é cancelada para evitar o segfault.

Verifique se as seguintes mudanças estão na árvore de origem do Android 11 para corrigir falhas de SIGSEGV em update_engine durante a mesclagem:

  • CL 1439792 pré-requisito para o CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancelar tarefas pendentes na destruição)
  • CL 1663460 (corrija o possível erro de ponteiro curinga quando markSlotSuccessful chega atrasado)

Impedir a mesclagem prematura de update_engine

Quando um dispositivo é inicializado (Android 11 e versões mais recentes) e a inicialização é concluída, a update_engine chama ScheduleWaitMarkBootSuccessful() e WaitForMergeOrSchedule(). Isso inicia o processo de mesclagem. No entanto, o dispositivo é reinicializado no slot antigo. Como a mesclagem já foi iniciada, o dispositivo não inicializa e fica inoperante.

Adicione as seguintes mudanças à árvore de origem: A CL 1664859 é opcional.

  • CL 1439792 (um pré-requisito para o CL 1439372)
  • CL 1439372 (link em inglês) (CleanupPreviousUpdateAction: cancelar tarefas pendentes na destruição)
  • CL 1663460 (corrija o possível erro de ponteiro curinga quando markSlotSuccessful chega atrasado)
  • CL 1664859 (opcional: adicione unittest para CleanupPreviousUpdateAction)

Verificar a configuração correta do dm-verity

No Android 11 e versões mais recentes, os dispositivos podem ser configurados acidentalmente com as seguintes opções do dm-verity:

  • CONFIG_DM_VERITY_AVB=y no kernel
  • O carregador de inicialização configurado para usar qualquer modo de verdade, como AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE), sem AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

Com essa configuração do dispositivo, qualquer erro de verdade faz com que a partição vbmeta ser corrompido e inoperar dispositivos que não sejam A/B. Da mesma forma, se uma mesclagem for iniciada, os dispositivos A/B também poderão ficar inoperantes. Use apenas o Modo verity AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

  1. Defina CONFIG_DM_VERITY_AVB=n no kernel.
  2. Configure os dispositivos para usar o modo AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

Para mais informações, consulte a documentação da verity: Handling dm-verity (Como lidar com dm-verity) Erros.

Confirmar se o arquivo mesclado está configurado corretamente

Se você estiver criando imagens do sistema e do fornecedor separadamente e usando merge_target_files para mesclar, as configurações A/B virtuais poderão ser eliminadas incorretamente durante o processo de mesclagem. Para verificar se as configurações do Virtual A/B estão corretas no arquivo de destino mesclado, aplique os seguintes patches: CL 2084183 (mesclar pares de chave/valor idênticos em informações de partição dinâmica).

Atualizar os componentes necessários

No Android 13 e versões mais recentes, o snapuserd foi movido do ramdisk do fornecedor para o formato genérico. no ramdisk. Caso seu dispositivo esteja sendo atualizado para o Android 13, é possível que ambos o ramdisk do fornecedor e o ramdisk genérico contêm uma cópia de snapuserd. Neste situação, o A/B virtual exige a cópia do sistema de snapuserd. Para garantir que a cópia correta de snapuserd esteja em vigor, aplique CL 2031243 (copie snapuserd para first_stage_ramdisk).