O Android 10 apresenta o User Data Checkpoint (UDC), que permite que o Android volte ao estado anterior quando uma atualização over-the-air (OTA) do Android falha. Com o UDC, se uma atualização do Android OTA falhar, o dispositivo poderá reverter com segurança ao estado anterior. Embora as atualizações A/B resolvam esse problema para inicialização antecipada, a reversão não é suportada 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 após ser modificado. O recurso UDC faz isso com recursos de ponto de verificação para o sistema de arquivos, uma implementação alternativa quando o sistema de arquivos não suporta pontos de verificação, integração com o mecanismo A/B do carregador de inicialização, ao mesmo tempo em que oferece suporte a atualizações não A/B e suporte para vinculação de versão de chave e prevenção de reversão chave.
Impacto no usuário
O recurso UDC melhora a experiência de atualização OTA para os usuários, pois menos usuários perdem seus dados quando uma atualização OTA falha. Isso pode reduzir o número de chamadas de suporte de usuários que enfrentam problemas durante o processo de atualização. No entanto, quando uma atualização OTA falha, os usuários podem perceber 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 ponto de verificação ao kernel Linux 4.20 upstream e faz backport para todos os kernels comuns suportados por dispositivos que executam o Android 10.
Para outros sistemas de arquivos, o UDC usa um dispositivo virtual mapeador de dispositivos chamado dm_bow para funcionalidade de ponto de verificação. dm_bow fica entre o dispositivo e o sistema de arquivos. Quando uma partição é montada, um trim é emitido, fazendo com que o sistema de arquivos emita comandos trim em todos os blocos livres. dm_bow intercepta esses cortes e os usa para configurar uma lista de bloqueios gratuita. As leituras e gravações são então enviadas para o dispositivo sem modificações, mas antes que uma gravação seja permitida, os dados necessários para uma restauração são copiados para um bloco livre.
Processo de ponto de verificação
Quando uma partição com o sinalizador checkpoint=fs/block é montada, o Android chama restoreCheckpoint na unidade para permitir que o dispositivo restaure qualquer ponto de verificação atual. init então chama a função needsCheckpoint para determinar se o dispositivo está em um estado A/B do bootloader ou configurou a contagem de novas tentativas de atualização. Se alguma delas for verdadeira, o Android chama createCheckpoint para adicionar sinalizadores de montagem ou construir um dispositivo dm_bow .
Depois que a partição é montada, o código do ponto de verificação é chamado para emitir cortes. O processo de inicialização continua normalmente. Em LOCKED_BOOT_COMPLETE , o Android chama commitCheckpoint para confirmar o ponto de verificação atual e a atualização continua normalmente.
Gerenciar chaves mestras
As chaves mestras são usadas para criptografia de dispositivos ou outros fins. Para gerenciar essas chaves, o Android atrasa as chamadas de exclusão de chaves até que o ponto de verificação seja confirmado.
Monitore a saúde
Um daemon de integridade verifica se há espaço em disco suficiente para criar um ponto de verificação. O daemon de saúde está localizado em cp_healthDaemon em Checkpoint.cpp .
O daemon de funcionamento possui 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 saúde procura. -
ro.sys.cp_commit_on_full: controla se o daemon de integridade reinicia o dispositivo ou confirma o ponto de verificação e continua quando o disco está cheio.
APIs de ponto de verificação
APIs de ponto de verificação são usadas pelo recurso UDC. Para outras APIs usadas pelo UDC, consulte IVold.aidl .
void startCheckpoint(int nova tentativa)
Cria um ponto de verificação.
A estrutura chama esse método quando está pronto para iniciar uma atualização. O ponto de verificação é criado antes que os sistemas de arquivos com ponto de verificação, como userdata, sejam montados R/W após a reinicialização. Se a contagem de novas tentativas for positiva, a API tratará das novas tentativas de rastreamento e o atualizador chamará needsRollback para verificar se uma reversão da atualização é necessária. Se a contagem de novas tentativas for -1 , a API adiará o julgamento do bootloader A/B.
Este método não é chamado ao fazer uma atualização A/B normal.
void commitChanges()
Confirma as alterações.
A estrutura chama esse método após a reinicialização, quando as alterações estão prontas para serem confirmadas. Isso é chamado antes dos dados (como fotos, vídeo, SMS, recebimento de recebimento do servidor) serem gravados em userdata e antes de BootComplete .
Se não existir nenhuma atualização com ponto de verificação ativo, esse método não terá efeito.
abortarChanges()
Força a reinicialização e reverte para o ponto de verificação. Abandona todas as modificações de dados do usuário desde a primeira reinicialização.
A estrutura chama esse método após a reinicialização, mas antes de commitChanges . retry_counter diminui quando este método é chamado. Entradas de log são geradas.
bool precisaRollback()
Determina se uma reversão é necessária.
Em dispositivos sem ponto de verificação, retorna false . Em dispositivos de ponto de verificação, retorna true durante uma inicialização sem ponto de verificação.
Implementar UDC
Implementação de referência
Para obter um exemplo de como o UDC pode ser implementado, consulte dm-bow.c . Para documentação adicional sobre o recurso, consulte dm-bow.txt .
Configurar
No on fs em seu arquivo init.hardware.rc , certifique-se de ter:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early
on late-fs em seu arquivo init.hardware.rc , certifique-se de ter:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
No seu arquivo fstab.hardware , certifique-se de /data esteja 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 requer uma partição de metadados para armazenar a contagem e as chaves de novas tentativas que não são do bootloader. Configure uma partição de metadados e monte-a antecipadamente em /metadata .
No seu arquivo fstab.hardware , certifique-se de que /metadata esteja 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 com zeros.
Adicione as seguintes linhas ao BoardConfig.mk :
BOARD_USES_METADATA_PARTITION := true BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata
Atualizar sistemas
Sistemas F2FS
Para sistemas que usam F2FS para formatar dados, certifique-se de que sua versão do F2FS oferece suporte a pontos de verificação. Para obter mais informações, consulte Funcionalidade do Checkpoint em diferentes sistemas de arquivos .
Adicione o sinalizador checkpoint=fs à seção <fs_mgr_flags> do fstab para o dispositivo montado em /data .
Sistemas não F2FS
Para sistemas não-F2FS, dm-bow deve estar habilitado na configuração do kernel.
Adicione o sinalizador checkpoint=block à seção <fs_mgr_flags> do fstab para o dispositivo montado em /data .
Verifique os registros
As entradas de log são geradas quando as APIs do Checkpoint são chamadas.
Validação
Para testar sua implementação de UDC, execute o conjunto de testes VTS VtsKernelCheckpointTest .