O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Ponto de verificação de dados do usuário (UDC)

O Android 10 apresenta o User Data Checkpoint (UDC), que permite que o Android volte ao seu estado anterior quando uma atualização do Android over-the-air (OTA) falha. Com o UDC, se uma atualização do Android OTA falhar, o dispositivo pode voltar com segurança ao estado anterior. Embora as atualizações A / B resolvam esse problema na inicialização antecipada, a reversão não é suportada quando a partição de dados do usuário (montada em /data ) é modificada.

UDC permite que o dispositivo reverta a partição de dados do usuário, mesmo depois de ser modificado. O recurso UDC realiza isso com recursos de ponto de verificação para o sistema de arquivos, uma implementação alternativa quando o sistema de arquivos não oferece suporte para pontos de verificação, integração com o mecanismo A / B do carregador de inicialização, ao mesmo tempo 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 do 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 é reiniciado 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 Linux 4.20 upstream e faz backports em 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 dispositivo denominado 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 corte é emitido, fazendo com que o sistema de arquivos emita comandos de corte em todos os blocos livres. dm_bow intercepta esses cortes e os usa para configurar uma lista de bloqueio livre. As leituras e gravações são enviadas ao 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 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 carregador de inicialização ou configurou a contagem de novas tentativas de atualização. Se qualquer um deles for verdadeiro, 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.

Gerenciando chaves do keymaster

As chaves do keymaster são usadas para criptografar o dispositivo 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.

Monitorando 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 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 ponto de verificação 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 IVoid.aidl .

void startCheckpoint (tentativa int)

Cria um ponto de verificação.

A estrutura chama esse método quando está pronta para iniciar uma atualização. O ponto de verificação é criado antes que os sistemas de arquivos com ponto de verificação, como dados do usuário, sejam montados R / W após a reinicialização. Se a contagem de needsRollback tentativas for positiva, a API lida com as needsRollback tentativas de rastreamento e o atualizador chama needsRollback para verificar se uma reversão da atualização é necessária. Se a contagem de novas tentativas for -1 , a API será submetida ao julgamento do carregador de inicialização A / B.

Este método não é chamado ao fazer uma atualização A / B normal.

void commitChanges ()

Compromete as mudanças.

A estrutura chama esse método após a reinicialização, quando as alterações estão prontas para serem confirmadas. Isso é chamado antes que os dados (como imagens, vídeo, SMS, recebimento de recebimento do servidor) sejam gravados nos dados do BootComplete e antes do BootComplete .

Se não houver nenhuma atualização ativa de ponto de verificação, este método não terá efeito.

abortChanges ()

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 é diminuído quando este método é chamado. As entradas de log são geradas.

bool needsRollback ()

Determina se uma reversão é necessária.

Em dispositivos sem verificação, retorna false . Em dispositivos de ponto de verificação, retorna true durante uma inicialização sem ponto de verificação.

Implementando 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 .

Configuração

Em on fs em seu arquivo init.hardware.rc , certifique-se de ter:

mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early

Em on late-fs em seu arquivo init.hardware.rc , certifique-se de ter:

mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late

Em seu arquivo fstab.hardware , certifique-se de que /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

Adicionando partição de metadados

O UDC requer uma partição de metadados para armazenar a contagem e as chaves de novas tentativas do nonbootloader. Configure uma partição de metadados e monte-a antecipadamente em /metadata .

Em 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 a BoardConfig.mk :

BOARD_USES_METADATA_PARTITION := true
BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata

Atualizando sistemas

Sistemas F2FS

Para sistemas que usam F2FS para formatar dados, certifique-se de que sua versão do F2FS suporta pontos de verificação. Para obter mais informações, consulte Funcionalidade do ponto de verificação em sistemas de arquivos diferentes .

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 ser habilitado na configuração do kernel.

Adicione o sinalizador checkpoint=block à seção <fs_mgr_flags> do fstab para o dispositivo montado em /data .

Verificando registros

As entradas de log são geradas quando as APIs de Checkpoint são chamadas.

Validação

Para testar sua implementação UDC, execute o conjunto VtsKernelCheckpointTest de testes VTS.