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 um 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 ...
Aqui está 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 , 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 ao destruir. Ele mantém uma variável que rastreia o ID da tarefa pendente no loop de mensagem. Ao destruir, a tarefa pendente é cancelada para evitar segfault.
Certifique-se de que as seguintes alterações estejam na árvore de origem do Android 11 para corrigir as falhas SIGSEGV no update_engine durante a mesclagem:
- CL 1439792 (um pré-requisito para CL 1439372)
- CL 1439372 (
CleanupPreviousUpdateAction: cancela tarefas pendentes ao destruir) - CL 1663460 (corrige o possível erro de ponteiro selvagem quando
markSlotSuccessfulchega atrasado)
Corrigir a troca de slot incorreta do VAB, após a atualização do 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 troca de slot do 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 pode reverter para o slot anterior e não inicializar.
Para obter um exemplo de solução de código, consulte esta CL: CL 1535570 .
Impedir a mesclagem prematura do update_engine
Quando um dispositivo inicializa (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 reinicia no slot antigo. Como a mesclagem já foi iniciada, o dispositivo falha ao 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: cancela tarefas pendentes ao destruir) - CL 1663460 (corrige o possível erro de ponteiro selvagem quando
markSlotSuccessfulchega atrasado) - CL 1664859 (opcional - adicionar
unittestparaCleanupPreviousUpdateAction)
Evite perda ou corrupção de dados devido a metadados ignorados
No Android 11 e superior, se um dispositivo de armazenamento tiver um cache 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:
- Depois de terminar uma operação de mesclagem de um conjunto de exceções,
merge_callback()foi invocado. - 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 porque o cache do dispositivo de armazenamento da mesclagem recente não foi liberado.
Veja 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 dm-verity:
-
CONFIG_DM_VERITY_AVB=yno kernel - O bootloader configurado para usar qualquer modo verity, (como
AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE), semAVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.
Com essa configuração de dispositivo, qualquer erro de verity faz com que a partição vbmeta seja corrompida e torna os dispositivos não A/B inoperáveis. Da mesma forma, se uma mesclagem foi iniciada, 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 .
- Defina
CONFIG_DM_VERITY_AVB=nno kernel - 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 manipulados por novas solicitações de E/S dm, ou por aqueles que já estão em andamento, podem levar a um estado de corrupção de verdade, 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 Virtual A/B e é conhecida por causar problemas raros de corrupção de página quando ambos são ativados 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 virtuais A/B podem ser descartadas incorretamente durante o processo de mesclagem. Para verificar se as configurações virtuais A/B estão corretas no arquivo de destino mesclado, aplique os seguintes patches: CL 2084183 (mescla 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 o ramdisk do fornecedor e o ramdisk genérico contenham uma cópia do snapuserd . Nesta situação, o Virtual A/B requer 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).