Implementando A/B Virtual - Patches

Escolha os seguintes patches para resolver os seguintes problemas conhecidos.

Verifique o espaço alocado corretamente ao carregar lateralmente

O sideload de um pacote OTA completo em um dispositivo A/B virtual que possui uma superpartição com tamanho menor que *2 * soma(tamanho dos grupos de atualização)* 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 ...

Segue 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, selecione CL 1399393 , reconstrua e atualize a partição de inicialização ou a 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 VAB, uma chamada para update_engine_client --cancel faz com que CleanupPreviousUpdateAction falhe. 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. Ao destruir, a tarefa pendente é cancelada para evitar segfault.

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

  • CL 1439792 (Um pré-requisito para CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : cancela tarefas pendentes ao destruir)
  • CL 1663460 (Corrigir o potencial erro de ponteiro selvagem quando markSlotSuccessful chegar atrasado)

Corrija a troca de slot incorreta do VAB, poste a atualização OTA

No Android 11 e superior, a falha ao sincronizar um switch de slot em um dispositivo após uma atualização OTA pode colocar um dispositivo em um estado inutilizável. Se a implementação de comutação de slot do seu IBootControl HAL executa gravações, você deve 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 comutador de slot, o dispositivo poderá reverter para o slot anterior e não inicializar.

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 inicializa 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 : cancela tarefas pendentes ao destruir)
  • CL 1663460 (Corrigir o potencial erro de ponteiro selvagem quando markSlotSuccessful chegar atrasado)
  • CL 1664859 (Opcional - adicione unittest para CleanupPreviousUpdateAction )

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

No Android 11 e superior, 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 para o dispositivo COW é liberada de forma limpa.)

Resultado: o sistema travou devido ao cache do dispositivo de armazenamento da mesclagem recente não ser liberado.

Consulte o seguinte para implementar uma resolução:

Garanta a configuração correta do dm-verity

No Android 11 e superior, 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 esta configuração de dispositivo, qualquer erro de verificação faz com que a partição vbmeta seja corrompida e torna os dispositivos não A/B inoperantes. Da mesma forma, se uma mesclagem tiver sido iniciada, os dispositivos A/B também poderão ficar inoperantes. Use apenas o modo de verdade 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 obter mais informações e como prática, consulte a documentação do verity: Handling dm-verity Errors .

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 superior, se um desligamento de emergência do sistema for chamado (como no caso de um desligamento térmico), um dispositivo dm pode estar ativo enquanto o dispositivo de bloco não pode mais processar solicitações de E/S. Nesse estado, erros de E/S tratados por novas solicitações de E/S 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 um erro de E/S durante o desligamento)

Verifique se DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED está desativado

Os dispositivos Android Go que executam o kernel 4.19 ou anterior podem ter DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y em sua configuração de kernel. Essa configuração não é compatível com o Virtual A/B e é conhecida por causar problemas raros de corrupção de página quando ambos são habilitados juntos.

Para kernels 4.19 e anteriores, desative-o configurando 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.