Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Se usó la API de Cloud Translation para traducir esta página.

Almacenamiento en caché de APK

En este documento, se describe el diseño de una solución de almacenamiento en caché de APK para una instalación rápida. de apps precargadas en un dispositivo que admite particiones A/B.

Los OEM pueden colocar las precargas y las apps populares en la caché de APK almacenadas en la partición B vacía en nuevos dispositivos con particiones A/B sin afectar cualquier espacio de datos para el usuario. Al tener una caché de APK disponible en el dispositivo, los archivos nuevos o Los dispositivos que recientemente se restablecieron a la configuración de fábrica están listos para usarse casi de inmediato, sin la necesidad de descargar archivos APK de Google Play.

Casos de uso

Almacena apps precargadas en la partición B para una configuración más rápida
Almacena apps populares en la partición B para una restauración más rápida

Requisitos previos

Para usar esta función, el dispositivo necesita lo siguiente:

Versión de Android 8.1 (O MR1) instalada
Se implementó la partición A/B

El contenido precargado solo se puede copiar durante el primer inicio. Esto se debe a que el que admiten actualizaciones del sistema A/B, la partición B no almacena archivos de imagen del sistema, sino contenido precargado, como recursos de demo para punto de venta, OAT y la caché de APK. Después de copiar los recursos en /data, partición (esto ocurre en el primer inicio), la partición B será usada por inalámbricas actualizaciones para descargar versiones actualizadas de la imagen del sistema.

Por lo tanto, la caché del APK no se puede actualizar de manera inalámbrica. solo se puede precargar en una fábrica. El restablecimiento de la configuración de fábrica solo afecta a la partición /data. El sistema B seguirá teniendo el contenido precargado hasta que se descargue la imagen OTA. Después del restablecimiento de la configuración de fábrica, el sistema volverá a someterse al primer inicio. Esto significa que el APK el almacenamiento en caché no está disponible si la imagen inalámbrica se descarga en la partición B. se restablece la configuración de fábrica.

Implementación

Método 1. Contenido activado partición_otra_sistema

Ventaja: El contenido precargado no se pierde después de restablecer la configuración de fábrica. se copiarán de la partición B después de un reinicio.

Desventaja: Requiere espacio en la partición B. Cómo iniciar después de restablecer la configuración de fábrica requiere más tiempo para copiar el contenido precargado.

Para que las precargas se copien durante el primer inicio, el sistema llama a una secuencia de comandos en /system/bin/preloads_copy.sh. La secuencia de comandos se llama con un solo argumento (ruta de acceso al punto de activación de solo lectura para system_b) partición):

Para implementar esta función, realiza los cambios específicos para el dispositivo. Este es un ejemplo de Marlin:

Agrega la secuencia de comandos que realiza la copia al device-common.mk. (en este caso, device/google/marlin/device-common.mk), de la siguiente manera:
```
# 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
```
Encuentra un ejemplo de fuente de secuencia de comandos en: device/google/marlin/preloads_copy.sh.
Edita el archivo init.common.rc para que cree la el directorio y los subdirectorios necesarios /data/preloads:
```
mkdir /data/preloads 0775 system system
mkdir /data/preloads/media 0775 system system
mkdir /data/preloads/demo 0775 system system
```
Encuentra la fuente del archivo init de ejemplo en: device/google/marlin/init.common.rc

Define un nuevo dominio de SELinux en el archivo 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;

Busca un archivo de dominio SELinux de ejemplo en: /device/google/marlin/+/main/sepolicy/preloads_copy.te.

Registrar el dominio en una /sepolicy/file_contexts nueva archivo:
```
/system/bin/preloads_copy\.sh     u:object_r:preloads_copy_exec:s0
```
Busca un archivo de contextos de SELinux de ejemplo en device/google/marlin/sepolicy/preloads_copy.te.
Durante el tiempo de compilación, el directorio con contenido precargado se debe copiar en el Partición 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 es un ejemplo de un cambio en un archivo Make que permite copiar la caché del APK. recursos del repositorio de Git del proveedor (en nuestro caso, era Provider/google_devices/marlin/preloads) a la ubicación de la partición system_other. que luego se copiará en /data/preloads cuando el dispositivo se inicie por primera tiempo. Esta secuencia de comandos se ejecuta durante la compilación para preparar la imagen system_other. Espera el contenido precargado para que esté disponible en provider/google_devices/marlin/preloads. OEM puedes elegir el nombre o la ruta reales del repositorio.
La caché del APK se encuentra en /data/preloads/file_cache y tiene el siguiente diseño:
```
/data/preloads/file_cache/
    app.package.name.1/
          file1
          fileN
    app.package.name.N/
```
Esta es la estructura final del directorio de los dispositivos. Los OEM son quienes eligen libremente cualquier enfoque de implementación siempre que la estructura de archivos final replique el una de las descritas anteriormente.

Enfoque 2. Contenido sobre los datos del usuario imagen escrita en la memoria flash de fábrica

Este enfoque alternativo supone que el contenido precargado ya se incluye en el directorio /data/preloads en la partición /data.

Ventaja: Funciona de inmediato, no es necesario fabricar el dispositivo. personalizadas para copiar archivos en el primer inicio. El contenido ya se encuentra en /data.

Desventaja: El contenido precargado se pierde después de restablecer la configuración de fábrica. Mientras que Esto puede ser aceptable para algunas personas, pero no siempre funciona para los OEM restablecer los dispositivos después de hacer inspecciones de control de calidad.

Se agregó un nuevo método @SystemApi, getPreloadsFileCache(), a android.content.Context Devuelve una ruta de acceso absoluta a un directorio específico de la app en la caché precargada.

Se agregó un nuevo método, IPackageManager.deletePreloadsFileCache. que permite borrar el directorio de precarga para recuperar todo el espacio. El método puede solo pueden llamarlas las apps con SYSTEM_UID, es decir, el servidor del sistema o la Configuración.

Preparación de la app

Solo las apps con privilegios pueden acceder al directorio de caché de precarga. Para eso acceso, las apps se deben instalar en el directorio /system/priv-app.

Validación

Después del primer inicio, el dispositivo debería tener contenido en /data/preloads/file_cache.
Se debe borrar el contenido del directorio file_cache/ si el elemento dispositivo se queda sin espacio de almacenamiento.

Usa el ejemplo ApkCacheTest para probar la caché de APK.

Compila la app ejecutando este comando desde el directorio raíz:
```
make ApkCacheTest
```

Instala la app como una app con privilegios. (Recuerda que solo las aplicaciones con privilegios pueden acceder a la caché del APK). Se requiere un dispositivo con permisos de administrador:

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

Simula el directorio de caché del archivo y su contenido si es necesario (también se requieren privilegios de administrador):

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"

Prueba la app. Después de instalar la app y crear el directorio de prueba file_cache, abre la app ApkCacheTest. Debería mostrar un archivo test.txt y su contenido. Observa esta captura de pantalla para ver cómo aparecen estos resultados en la interfaz de usuario.
Figura 1: Resultados de ApkCacheTest.