Implementar A/B virtual: patches

Faça cherry-pick dos seguintes patches para resolver os problemas conhecidos a seguir.

Verificar o espaço alocável corretamente ao fazer sideload

O carregamento lateral de um pacote OTA completo em um dispositivo A/B virtual que tem uma superpartição com um tamanho menor que *2 * sum(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, selecione 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.

Correção de falha de segmentação durante a fusão

Depois de aplicar uma atualização OTA, durante o processo de fusão do VAB, uma chamada para update_engine_client --cancel causa uma falha em CleanupPreviousUpdateAction. Um possível erro de ponteiro descontrolado também existe quando markSlotSuccessful chega tarde.

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

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

  • CL 1439792 (um pré-requisito para CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (corrige o possível erro de ponteiro solto quando markSlotSuccessful chega tarde)

Impedir a fusão prematura do update_engine

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

Adicione as seguintes mudanças à sua árvore de origem. A observação CL 1664859 é opcional.

  • CL 1439792 (um pré-requisito para CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (corrige o possível erro de ponteiro solto quando markSlotSuccessful chega tarde)
  • 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 inadvertidamente com as seguintes opções de dm-verity:

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

Com essa configuração de dispositivo, qualquer erro de veracidade corrompe a partição vbmeta e torna os dispositivos não A/B inoperáveis. Da mesma forma, se uma fusão começou, os dispositivos A/B também podem ficar inoperáveis. Use apenas o modo de verificação 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 do verity: Como processar erros do dm-verity.

Confirme se o arquivo mesclado está configurado corretamente

Se você estiver criando imagens do sistema e do fornecedor separadamente e usando merge_target_files para mesclá-las, as configurações virtuais A/B poderão ser descartadas 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, snapuserd foi movido do ramdisk do fornecedor para o ramdisk genérico. Se o dispositivo estiver fazendo upgrade para o Android 13, é possível que o ramdisk do fornecedor e o ramdisk genérico contenham uma cópia de snapuserd. Nessa situação, o Virtual A/B exige a cópia do sistema de snapuserd. Para garantir que a cópia correta de snapuserd esteja no lugar, aplique CL 2031243 (copie snapuserd para first_stage_ramdisk).