Escolha os patches a seguir para resolver os problemas conhecidos a seguir.
Verificar o espaço alocável corretamente ao transferir por 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 ...
Veja 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 a 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 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 (um pré-requisito para o CL 1439372)
- CL 1439372
(
CleanupPreviousUpdateAction: cancelar tarefas pendentes na destruição) - CL 1663460: correção do
possível erro de ponteiro wild quando
markSlotSuccessfulchega atrasado.
Impedir a fusão 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 para o slot antigo. Como a mesclagem já foi iniciada, o dispositivo não
inicializa e fica inoperante.
Adicione as seguintes mudanças à sua árvore de origem. A CL 1664859 é opcional.
- CL 1439792 (um pré-requisito para o CL 1439372)
- CL 1439372
(
CleanupPreviousUpdateAction: cancelar tarefas pendentes na destruição) - CL 1663460: correção do
possível erro de ponteiro selvagem quando
markSlotSuccessfulchega atrasado. - CL 1664859 (opcional -
adicione
unittestparaCleanupPreviousUpdateAction)
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=yno kernel- O carregador de inicialização configurado para usar qualquer modo de verificação, como
AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE, semAVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.
Com essa configuração do 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
for iniciada, os dispositivos A/B também poderão 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 mais informações, consulte a documentação do verity: Como lidar com erros dm-verity.
Confirmar se o arquivo mesclado está configurado corretamente
Se você estiver criando imagens do sistema e de fornecedor separadamente e usar
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 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 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 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).