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.

Armazenamento em cache de APK

Este documento descreve o design de uma solução de armazenamento em cache de APK para instalação rápida de apps pré-carregados em dispositivos com suporte a partições A/B.

OEMs podem colocar pré-carregamentos e apps populares no cache do APK armazenado na maioria partição B vazia em novos dispositivos particionados A/B sem afetar qualquer espaço de dados voltado para o usuário. Com um cache de APK disponível no dispositivo, novos ou os dispositivos redefinidos para a configuração original estão prontos para uso quase imediatamente, sem fazer o download de arquivos APK do Google Play.

Casos de uso

Armazenar apps pré-carregados na partição B para uma configuração mais rápida
Armazenar aplicativos populares na partição B para uma restauração mais rápida

Pré-requisitos

Para usar esse recurso, o dispositivo precisa ter:

Versão do Android 8.1 (O MR1) instalada
Partição A/B implementada

O conteúdo pré-carregado só pode ser copiado durante a primeira inicialização. Isso ocorre porque, dispositivos compatíveis com atualizações do sistema A/B, a partição B não armazena arquivos de imagem do sistema, mas conteúdo pré-carregado, como recursos de demonstração, OAT e o cache do APK. Depois que os recursos forem copiados para a pasta "/data" (isso acontece na primeira inicialização), a partição B será usada por chamadas over-the-air (OTA) atualizações para fazer o download de versões atualizadas da imagem do sistema.

Portanto, o cache do APK não pode ser atualizado por OTA. ele só pode ser pré-carregado em uma fábrica. A redefinição para a configuração original afeta apenas a partição /data. O sistema B partição ainda tem o conteúdo pré-carregado até que a imagem OTA seja baixada. Após a redefinição de fábrica, o sistema vai passar pela primeira inicialização novamente. Ou seja, APK o armazenamento em cache não estará disponível se a imagem OTA for transferida por download para a partição B. o dispositivo é redefinido para a configuração original.

Implementação

Abordagem 1. Conteúdo em partição system_other

Vantagem: o conteúdo pré-carregado não é perdido após a redefinição para a configuração original. será copiado da partição B após uma reinicialização.

Desvantagem: exige espaço na partição B. Inicializar após redefinir para a configuração original requer mais tempo para copiar o conteúdo pré-carregado.

Para que os pré-carregamentos sejam copiados durante a primeira inicialização, o sistema chama um script em /system/bin/preloads_copy.sh. O script é chamado com uma única argumento (caminho para o ponto de montagem somente leitura de system_b partição):

Para implementar esse recurso, faça estas mudanças específicas dos dispositivos. Veja um exemplo de Marlin:

Adicione o script que faz a cópia para o device-common.mk. (neste caso, device/google/marlin/device-common.mk), assim:
```
# Script that copies preloads directory from system_other to data partition
PRODUCT_COPY_FILES += \
    device/google/marlin/preloads_copy.sh:system/bin/preloads_copy.sh
```
Confira um exemplo de fonte de script em: device/google/marlin/preloads_copy.sh
Edite o arquivo init.common.rc para que ele crie o diretório e subdiretórios /data/preloads necessários:
```
mkdir /data/preloads 0775 system system
mkdir /data/preloads/media 0775 system system
mkdir /data/preloads/demo 0775 system system
```
Veja um exemplo de fonte de arquivo init em: device/google/marlin/init.common.rc

Defina um novo domínio SELinux no arquivo preloads_copy.te:

type preloads_copy, domain, coredomain;
type preloads_copy_exec, exec_type, vendor_file_type, file_type;

init_daemon_domain(preloads_copy)

allow preloads_copy shell_exec:file rx_file_perms;
allow preloads_copy toolbox_exec:file rx_file_perms;
allow preloads_copy preloads_data_file:dir create_dir_perms;
allow preloads_copy preloads_data_file:file create_file_perms;
allow preloads_copy preloads_media_file:dir create_dir_perms;
allow preloads_copy preloads_media_file:file create_file_perms;

# Allow to copy from /postinstall
allow preloads_copy system_file:dir r_dir_perms;

Encontre um exemplo de arquivo de domínio SELinux em: /device/google/marlin/+/main/sepolicy/preloads_copy.te

Registre o domínio em um novo /sepolicy/file_contexts arquivo:
```
/system/bin/preloads_copy\.sh     u:object_r:preloads_copy_exec:s0
```
Encontre um exemplo de arquivo de contextos do SELinux em: device/google/marlin/sepolicy/preloads_copy.te
No tempo de compilação, o diretório com conteúdo pré-carregado deve ser copiado para o Partição system_other:
```
# Copy contents of preloads directory to system_other partition
PRODUCT_COPY_FILES += \
    $(call find-copy-subdir-files,*,vendor/google_devices/marlin/preloads,system_other/preloads)
```
Este é um exemplo de mudança em um Makefile que permite copiar o cache do APK recursos do repositório Git do fornecedor (no nosso caso, foi fornecedor/google_devices/marlin/preloads) para o local na partição system_other que depois será copiado para /data/preloads quando o dispositivo for inicializado pela primeira tempo de resposta. Este script é executado no tempo de build para preparar a imagem system_other. Ele espera que o conteúdo pré-carregado seja disponibilizado em fornecedor/google_devices/marlin/preloads. OEM é livre para escolher o nome/caminho do repositório real.
O cache do APK está localizado em /data/preloads/file_cache e tem o seguinte layout:
```
/data/preloads/file_cache/
    app.package.name.1/
          file1
          fileN
    app.package.name.N/
```
Essa é a estrutura de diretórios final nos dispositivos. OEMs são livres para escolher qualquer abordagem de implementação, desde que a estrutura do arquivo final replique o um descrito acima.

Abordagem 2. Conteúdo nos dados do usuário imagem atualizada na fábrica

Essa abordagem alternativa pressupõe que o conteúdo pré-carregado já esteja incluído no no diretório /data/preloads na partição /data.

Pró: vem pronto para uso, sem necessidade de deixar o dispositivo personalizações para copiar arquivos na primeira inicialização. O conteúdo já está na guia /data.

Desvantagem: o conteúdo pré-carregado é perdido após uma redefinição para a configuração original. isso pode ser aceitável para algumas pessoas, mas nem sempre funciona para OEMs que produzem redefinir os dispositivos após inspeções de controle de qualidade.

Um novo método @SystemApi, getPreloadsFileCache(), foi adicionado à android.content.Context. Ela retorna um caminho absoluto para uma específico do app no cache pré-carregado.

Um novo método, IPackageManager.deletePreloadsFileCache, foi adicionado que permite excluir o diretório de pré-carregamentos para recuperar todo o espaço. O método pode ser chamado apenas por apps com SYSTEM_UID, ou seja, o servidor do sistema ou as configurações.

Preparação do app

Somente apps privilegiados podem acessar o diretório de cache de pré-carregamentos. Para isso acesso, os apps precisam ser instalados no diretório /system/priv-app.

Validação

Após a primeira inicialização, o dispositivo deve ter conteúdo na /data/preloads/file_cache.
O conteúdo no diretório file_cache/ deverá ser excluído se o dispositivo fica com pouco espaço de armazenamento.

Use o exemplo ApkCacheTest app para testar o cache do APK.

Crie o app executando este comando no diretório raiz:
```
make ApkCacheTest
```

Instalar o app como um app privilegiado. Lembre-se de que apenas apps privilegiados podem acessar o cache do APK. Isso exige um dispositivo com acesso root:

adb root && adb remount
adb shell mkdir /system/priv-app/ApkCacheTest
adb push $ANDROID_PRODUCT_OUT/data/app/ApkCacheTest/ApkCacheTest.apk /system/priv-app/ApkCacheTest/
adb shell stop && adb shell start

Simule o diretório de cache de arquivos e seu conteúdo, se necessário (também exigindo privilégios raiz):

adb shell mkdir -p /data/preloads/file_cache/com.android.apkcachetest
adb shell restorecon -r /data/preloads
adb shell "echo "Test File" > /data/preloads/file_cache/com.android.apkcachetest/test.txt"

Teste o app. Depois de instalar o app e criar o diretório file_cache de teste, abra o app ApkCacheTest. Ele vai mostrar um arquivo test.txt e o conteúdo dele. Confira esta captura de tela para saber como esses resultados aparecem na interface do usuário.
Figura 1. Resultados de ApkCacheTest.