Implementar Virtual A/B - patches

Escolha os seguintes patches para resolver os seguintes problemas conhecidos.

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

O sideload de um pacote OTA completo em um dispositivo Virtual A/B que possui uma superpartição com tamanho menor que *2 * sum(size of update groups)* pode falhar com o seguinte no log de recuperação /tmp/recovery.log :

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

Aqui está um exemplo do log:

[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 , reconstrua e atualize a partição de inicialização ou partição de recuperação se o dispositivo não usar a recuperação como inicialização.

Corrigir falha de segmentação durante a mesclagem

Depois de aplicar uma atualização OTA, durante o processo de mesclagem do VAB, uma chamada para update_engine_client --cancel faz com que CleanupPreviousUpdateAction trave. Um possível erro de ponteiro selvagem também existe quando markSlotSuccessful chega atrasado.

Isso foi resolvido adicionando a 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 falha de segurança.

Certifique-se de que as seguintes alterações estejam na árvore de origem do Android 11 para corrigir falhas SIGSEGV em update_engine durante a mesclagem:

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

Corrigir troca de slot incorreta do VAB, pós atualização OTA

No Android 11 e superior, a falha na sincronização de um switch de slot em um dispositivo após uma atualização OTA pode colocar o dispositivo em um estado inutilizável. Se a implementação de comutação de slot do seu IBootControl HAL executar gravações, você deverá liberar essas gravações imediatamente. Se as gravações não forem liberadas e o dispositivo for reinicializado após o início da mesclagem, mas antes que o hardware possa liberar a gravação do switch de slot, o dispositivo poderá reverter para o slot anterior e falhar na inicialização.

Para obter um exemplo de solução de código, veja este CL: CL 1535570 .

Impedir a mesclagem prematura do update_engine

Quando um dispositivo é inicializado (Android 11 e superior) e a inicialização é concluída, o 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 consegue inicializar e fica inoperante.

Adicione as seguintes alterações à sua árvore de origem. Observe que CL 1664859 é opcional.

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

Evite perda ou corrupção de dados devido a metadados ignorados

No Android 11 e versões posteriores, se um dispositivo de armazenamento tiver um cache de write-back volátil, sob certas condições, os metadados de uma mesclagem concluída serão ignorados, resultando em perda ou corrupção de dados.

Condições:

  1. Depois de terminar uma operação de mesclagem de um conjunto de exceções, merge_callback() foi invocado.
  2. Os metadados foram atualizados no dispositivo COW que rastreia a conclusão da mesclagem. (Esta atualização do dispositivo COW foi liberada de forma limpa.)

Resultado: o sistema travou porque o cache do dispositivo de armazenamento da mesclagem recente não foi liberado.

Consulte o seguinte para implementar uma resolução:

Garanta a configuração correta do dm-verity

No Android 11 e versões posteriores, os dispositivos podem ser configurados inadvertidamente com as seguintes opções de dm-verity:

  • CONFIG_DM_VERITY_AVB=y no kernel
  • O bootloader 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 esta configuração de dispositivo, qualquer erro de verdade faz com que a partição vbmeta seja corrompida e torna os dispositivos não A/B inoperantes. Da mesma forma, se uma fusão tiver sido iniciada, os dispositivos A/B também poderão ficar inoperantes. 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 dispositivos para usar o modo AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

Para obter mais informações e por uma questão prática, consulte a documentação de verity: Manipulando erros de dm-verity .

Ignorar o trabalho de verificação em resposta a um erro de E/S durante o desligamento de emergência do sistema

No Android 11 e versões posteriores, se um desligamento de emergência do sistema for chamado (como no caso de um desligamento térmico), um dispositivo dm poderá permanecer ativo enquanto o dispositivo de bloco não puder mais processar solicitações de E/S. Nesse estado, erros de E/S tratados por novas solicitações de E/S do dm, ou por aquelas já em andamento, podem levar a um estado de corrupção de verdade, o que é um erro de julgamento.

Para ignorar o trabalho de verificação em resposta a um erro de E/S quando o sistema está sendo desligado, use o seguinte:

CL 1847875 (ignora o trabalho de verificação em resposta a erro de E/S durante o desligamento)

Certifique-se de que DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED esteja desativado

Dispositivos Android Go executando o kernel 4.19 ou anterior podem ter DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y na configuração do kernel. Essa configuração não é compatível com Virtual A/B e é conhecida por causar raros problemas de corrupção de página quando ambos estão habilitados juntos.

Para kernels 4.19 e anteriores, desative-o definindo CONFIG_DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=n na configuração do kernel.

Para kernels 5.4 e posteriores, o código foi removido e a opção de configuração não está disponível.

Confirme se o arquivo mesclado está configurado corretamente

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

Atualize os componentes necessários

A partir do Android 13, snapuserd foi movido do ramdisk do fornecedor para o ramdisk genérico. Se o seu dispositivo estiver atualizando para o Android 13, é possível que tanto o ramdisk do fornecedor quanto o ramdisk genérico contenham uma cópia do snapuserd . Nessa situação, o Virtual A/B requer a cópia do sistema snapuserd . Para garantir que a cópia correta do snapuserd esteja em vigor, aplique CL 2031243 (copie snapuserd para first_stage_ramdisk).