O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

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 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. Apesar de A / B atualizações resolver este problema para o arranque inicial, a reversão não é suportada quando a partição de dados do utilizador (montado em /data ) é modificado.

UDC permite que o dispositivo reverta a partição de dados do usuário, mesmo depois de 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 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 o backports para todos os kernels comuns suportados por dispositivos que executam o Android 10.

Para outros sistemas de arquivos, UDC usa um dispositivo virtual dispositivo mapeador chamado dm_bow para a funcionalidade checkpoint. dm_bow fica entre o dispositivo eo 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 estas guarnições e os utiliza para criar uma lista de blocos livres. 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 checkpoint=fs/block bandeira é montado, Android chama restoreCheckpoint na unidade para permitir que o dispositivo para restaurar qualquer ponto de verificação atual. init , em seguida, chama o needsCheckpoint função para determinar se o dispositivo quer está em um bootloader Um estado / B ou fixou a contagem de atualização de repetição. Se uma for verdadeira, Android chama createCheckpoint a qualquer add montar bandeiras ou construir uma dm_bow dispositivo.

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. No LOCKED_BOOT_COMPLETE , Android chama commitCheckpoint para cometer o ponto de verificação atual e a atualização continua como normal.

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 na cp_healthDaemon em Checkpoint.cpp .

O daemon de integridade tem os seguintes comportamentos que podem ser configurados:

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 em R / W após a reinicialização. Se a contagem de repetição é positivo, as alças API rastreamento tentativas, e as chamadas atualizador needsRollback para verificar se é necessária uma reversão da atualização. Se a contagem de repetição é -1 , os adia API para julgamento do A / B do bootloader.

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 de dados (como fotos, vídeo, SMS, Recibo servidor de recebimento) é escrito para userdata e antes BootComplete .

Se nenhuma atualização ativa de ponto de verificação existe, este método não tem 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 commitChanges . retry_counter é diminuída quando este método é chamado. As entradas de log são geradas.

bool needsRollback ()

Determina se uma reversão é necessária.

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

Implementando UDC

Implementação de referência

Para um exemplo de como UDC pode ser implementado, consulte dm-bow.c . Para obter documentação adicional sobre o recurso, consulte dm-bow.txt .

Configurar

Em on fs em seu init.hardware.rc arquivo, verifique se você tem:

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

Em on late-fs em seu init.hardware.rc arquivo, verifique se você tem:

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

Em sua fstab.hardware arquivo, certifique-se /data é 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

UDC requer uma partição de metadados para armazenar a contagem e as chaves de novas tentativas do nonbootloader. Configurar uma partição de metadados e montá-lo cedo no /metadata .

Em sua fstab.hardware arquivo, certifique-se /metadata é 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 para 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 mais informações, consulte funcionalidade Checkpoint em diferentes sistemas de arquivos .

Adicione o checkpoint=fs bandeira para as <fs_mgr_flags> seção 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 checkpoint=block de bandeira, às <fs_mgr_flags> seção 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 a sua implementação UDC, execute o VtsKernelCheckpointTest conjunto de testes VTS.