O Android 10 introduz o Checkpoint de dados do usuário (UDC, na sigla em inglês), que permite que o Android seja revertido ao estado anterior quando uma atualização OTA falha. Com o UDC, se uma atualização OTA do Android falhar, o dispositivo poderá ser revertido com segurança ao estado anterior. Embora
as atualizações A/B resolvam esse problema para a inicialização antecipada, a reversão
não é compatível quando a partição de dados do usuário (montada em /data) é modificada.
O UDC permite que o dispositivo reverta a partição de dados do usuário mesmo depois de ser modificada. O recurso UDC realiza isso com recursos de checkpoint para o sistema de arquivos, uma implementação alternativa quando o sistema de arquivos não oferece suporte a checkpoints, integração com o mecanismo A/B do bootloader, além de oferecer suporte a atualizações não A/B e vinculação de versão de chave e prevenção de reversão de chave.
Impacto no usuário
O recurso UDC melhora a experiência de atualização OTA para os usuários, já que menos usuários perdem dados quando uma atualização OTA falha. Isso pode reduzir o número de chamadas de suporte de usuários que encontram problemas durante o processo de atualização. No entanto, quando uma atualização OTA falha, os usuários podem notar que o dispositivo é reinicializado várias vezes.
Como funciona
Funcionalidade de checkpoint em diferentes sistemas de arquivos
Para o sistema de arquivos F2FS, o UDC adiciona a funcionalidade de checkpoint ao kernel 4.20 do Linux upstream e a porta para todos os kernels comuns com suporte a dispositivos que executam o Android 10.
Para outros sistemas de arquivos, o UDC usa um dispositivo virtual de mapeador de dispositivos chamado dm_bow para a funcionalidade de checkpoint. O dm_bow fica entre o dispositivo e o sistema de arquivos. Quando uma partição é montada, um corte é emitido, fazendo com que o sistema de arquivos emita comandos de corte em todos os blocos livres. O dm_bow intercepta esses cortes e os usa para configurar uma lista de blocos livres. As leituras e gravações são enviadas ao dispositivo sem modificação, mas, antes que uma gravação seja permitida, os dados necessários para uma restauração são armazenados em backup em um bloco livre.
Processo de checkpoint
Quando uma partição com a flag checkpoint=fs/block é montada, o Android chama restoreCheckpoint na unidade para permitir que o dispositivo restaure qualquer checkpoint atual. Em seguida, init chama a função needsCheckpoint para determinar se o dispositivo está em um estado A/B do bootloader ou se definiu a contagem de repetições da atualização. Se qualquer uma dessas condições for verdadeira, o Android chamará createCheckpoint para adicionar flags de montagem ou criar um dispositivo dm_bow.
Depois que a partição é montada, o código de checkpoint é chamado para emitir cortes.
O processo de inicialização continua normalmente. Em LOCKED_BOOT_COMPLETE, o Android chama commitCheckpoint para confirmar o checkpoint atual, e a atualização continua normalmente.
Gerenciar chaves do KeyMint (anteriormente Keymaster)
As chaves do KeyMint são usadas para criptografia de dispositivos ou outras finalidades. Para gerenciar essas chaves, o Android atrasa as chamadas de exclusão de chaves até que o checkpoint seja confirmado.
Monitorar a integridade
Um daemon de integridade verifica se há espaço em disco suficiente para criar um checkpoint. O daemon de integridade está localizado em
cp_healthDaemon
em Checkpoint.cpp.
O daemon de integridade tem os seguintes comportamentos que podem ser configurados:
ro.sys.cp_msleeptime: controla a frequência com que o dispositivo verifica o uso do disco.ro.sys.cp_min_free_bytes: controla o valor mínimo que o daemon de integridade procura.ro.sys.cp_commit_on_full: controla se o daemon de integridade reinicializa o dispositivo ou confirma o checkpoint e continua quando o disco está cheio.
APIs de checkpoint
As APIs de checkpoint são usadas pelo recurso UDC. Para outras APIs usadas pelo UDC, consulte
IVold.aidl.
void startCheckpoint(int retry)
Cria um checkpoint.
O framework chama esse método quando está pronto para iniciar uma atualização. O checkpoint é criado antes que os sistemas de arquivos com checkpoint, como userdata, sejam montados R/W após a reinicialização. Se a contagem de repetições for positiva, a API vai processar o rastreamento de repetições, e o atualizador vai chamar needsRollback para verificar se uma reversão da atualização é necessária. Se a contagem de repetições for -1, a API vai adiar o julgamento do bootloader A/B.
Esse método não é chamado ao fazer uma atualização A/B normal.
void commitChanges()
Confirma as mudanças.
O framework chama esse método após a reinicialização, quando as mudanças estão prontas para serem confirmadas. Isso é chamado antes que os dados (como fotos, vídeos, SMS, recebimento do servidor) sejam gravados em userdata e antes de BootComplete.
Se não houver uma atualização de checkpoint ativa, esse método não terá efeito.
abortChanges()
Força a reinicialização e reverte para o checkpoint. Abandona todas as modificações de userdata desde a primeira reinicialização.
O framework chama esse método após a reinicialização, mas antes de commitChanges.
retry_counter é diminuído quando esse método é chamado. As entradas de registro são geradas.
bool needsRollback()
Determina se uma reversão é necessária.
Em dispositivos sem checkpoint, retorna false. Em dispositivos de checkpoint, retorna true durante uma inicialização sem checkpoint.
Implementar o UDC
Implementação de referência
Para um exemplo de como o UDC pode ser implementado, consulte dm-bow.c.
Para mais documentação sobre o recurso, consulte dm-bow.txt.
Configuração
Em on fs no arquivo init.hardware.rc, verifique se você tem:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early
Em on late-fs no arquivo init.hardware.rc, verifique se você tem:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
No arquivo fstab.hardware, verifique se /data está marcado como latemount.
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,reserve_root=32768,resgid=1065,fsync_mode=nobarrier latemount,wait,check,fileencryption=ice,keydirectory=/metadata/vold/metadata_encryption,quota,formattable,sysfs_path=/sys/devices/platform/soc/1d84000.ufshc,reservedsize=128M,checkpoint=fs
Adicionar partição de metadados
O UDC exige uma partição de metadados para armazenar a contagem de repetições e chaves do não bootloader. Configure uma partição de metadados e monte-a antecipadamente em /metadata.
No arquivo fstab.hardware, verifique se /metadata está marcado como earlymount ou first_stage_mount.
/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount
Inicialize a partição para todos os zeros.
Adicione as linhas abaixo a BoardConfig.mk:
BOARD_USES_METADATA_PARTITION := true BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata
Atualizar sistemas
Sistemas F2FS
Para sistemas que usam o F2FS para formatar dados, verifique se a versão do F2FS oferece suporte a checkpoints. Para mais informações, consulte Funcionalidade de checkpoint em diferentes sistemas de arquivos.
Adicione a flag checkpoint=fs à seção <fs_mgr_flags> do fstab para o
dispositivo montado em /data.
Sistemas não F2FS
Para sistemas não F2FS, o dm-bow precisa ser ativado na configuração do kernel.
Adicione a checkpoint=block flag à seção <fs_mgr_flags> do fstab para o
dispositivo montado em /data.
Verificar os registros
As entradas de registro são geradas quando as APIs de checkpoint são chamadas.
Validação
Para testar a implementação do UDC, execute o conjunto de testes VtsKernelCheckpointTest do VTS.