Эта страница переведена с помощью Cloud Translation API.

Кэширование APK

В этом документе описывается разработка решения для кэширования APK для быстрой установки предварительно загруженных приложений на устройство, поддерживающее разделы A/B.

OEM-производители могут размещать предварительные загрузки и популярные приложения в кэше APK, хранящемся в основном пустом разделе B на новых устройствах с разделами A/B , не затрагивая какое-либо доступное пользователю пространство данных. Имея кэш APK на устройстве, новые устройства или устройства, недавно сбросившие заводские настройки, готовы к использованию почти сразу, без необходимости загружать файлы APK из Google Play.

Сценарии использования

Храните предварительно загруженные приложения в разделе B для более быстрой настройки
Храните популярные приложения в разделе B для более быстрого восстановления

Предпосылки

Для использования этой функции устройству необходимо:

Установлен выпуск Android 8.1 (O MR1)
Раздел A/B реализован

Предварительно загруженный контент можно скопировать только во время первой загрузки. Это связано с тем, что на устройствах, поддерживающих системные обновления A/B, в разделе B на самом деле хранятся не файлы образа системы, а вместо этого предварительно загруженный контент, такой как розничные демонстрационные ресурсы, файлы OAT и кэш APK. После того, как ресурсы будут скопированы в раздел /data (это происходит при первой загрузке), раздел B будет использоваться обновлениями по беспроводной сети (OTA) для загрузки обновленных версий образа системы.

Поэтому кэш APK нельзя обновить через OTA; он может быть предварительно загружен только на заводе. Сброс к заводским настройкам влияет только на раздел /data. Раздел системы B по-прежнему имеет предварительно загруженное содержимое, пока не будет загружен образ OTA. После сброса настроек система снова выполнит первую загрузку. Это означает, что кэширование APK недоступно, если образ OTA загружается в раздел B, а затем выполняется сброс настроек устройства.

Реализация

Подход 1. Содержимое раздела system_other

Pro : предварительно загруженный контент не теряется после сброса настроек — он будет скопирован из раздела B после перезагрузки.

Минусы : требуется место на разделе B. Загрузка после сброса настроек требует дополнительного времени для копирования предварительно загруженного содержимого.

Чтобы предварительные загрузки копировались при первой загрузке, система вызывает скрипт в /system/bin/preloads_copy.sh . Скрипт вызывается с одним аргументом (путь к доступной только для чтения точке монтирования раздела system_b ):

Чтобы реализовать эту функцию, внесите эти изменения для конкретного устройства. Вот пример из Марлина:

Добавьте скрипт, который выполняет копирование, в файл device-common.mk (в данном случае, device/google/marlin/device-common.mk ), например так:
```
# 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
```
Найдите пример скрипта по адресу: device/google/marlin . /preloads_copy.sh
Отредактируйте файл init.common.rc , чтобы он создал необходимый каталог /data/preloads и подкаталоги:
```
mkdir /data/preloads 0775 system system
mkdir /data/preloads/media 0775 system system
mkdir /data/preloads/demo 0775 system system
```
Найдите пример исходного файла init по адресу: device/google/marlin/init.common.rc

Определите новый домен SELinux в файле 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;

Найдите пример файла домена SELinux по адресу: /device/google/marlin/+/master/sepolicy/preloads_copy.te

Зарегистрируйте домен в новом
/sepolicy/file_contexts :
```
/system/bin/preloads_copy\.sh     u:object_r:preloads_copy_exec:s0
```
Найдите пример файла контекстов SELinux по адресу: device/google/marlin/sepolicy/preloads_copy.te
Во время сборки каталог с предварительно загруженным содержимым необходимо скопировать в раздел 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)
```
Это пример изменения в Makefile, которое позволяет копировать ресурсы кеша APK из Git-репозитория поставщика (в нашем случае это vendor/google_devices/ marlin/preloads) в расположение на разделе system_other, которое позже будет скопировано в /data/preloads при первой загрузке устройства. Этот скрипт запускается во время сборки для подготовки образа system_other. Ожидается, что предварительно загруженный контент будет доступен в vendor/google_devices/marlin/preloads. OEM может свободно выбирать фактическое имя/путь репозитория.
Кэш APK находится в /data/preloads/file_cache и имеет следующую структуру:
```
/data/preloads/file_cache/
    app.package.name.1/
          file1
          fileN
    app.package.name.N/
```
Это окончательная структура каталогов на устройствах. OEM-производители могут свободно выбирать любой подход к реализации, если окончательная файловая структура повторяет структуру, описанную выше.

Подход 2. Содержимое изображения пользовательских данных прошивается на заводе

Этот альтернативный подход предполагает, что предварительно загруженное содержимое уже включено в каталог /data/preloads раздела /data .

Pro : Работает сразу после установки — не нужно настраивать устройство для копирования файлов при первой загрузке. Содержимое уже находится в разделе /data .

Минусы : предварительно загруженный контент теряется после сброса настроек. Хотя это может быть приемлемо для некоторых, это не всегда работает для OEM-производителей, которые сбрасывают устройства до заводских настроек после проведения проверок контроля качества.

Новый метод @SystemApi, getPreloadsFileCache() , был добавлен в android.content.Context . Он возвращает абсолютный путь к каталогу приложения в предварительно загруженном кеше.

Был добавлен новый метод IPackageManager.deletePreloadsFileCache , который позволяет удалить каталог preloads, чтобы освободить все пространство. Метод может вызываться только приложениями с SYSTEM_UID, т.е. системным сервером или настройками.

Подготовка приложения

Только привилегированные приложения могут получить доступ к каталогу кеша предварительной загрузки. Для этого доступа приложения должны быть установлены в /system/priv-app .

Проверка

После первой загрузки устройство должно иметь содержимое в /data/preloads/file_cache .
Содержимое file_cache/ необходимо удалить, если на устройстве заканчивается память.

Используйте пример приложения ApkCacheTest для тестирования кеша APK.

Создайте приложение, выполнив эту команду из корневого каталога:
```
make ApkCacheTest
```
.
Установите приложение как привилегированное приложение. (Помните, только привилегированные приложения могут получить доступ к кешу APK.) Для этого требуется рутированное устройство:
```
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
```

Смоделируйте каталог кэша файлов и его содержимое, если необходимо (также требуются привилегии root):

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"

Протестируйте приложение. После установки приложения и создания тестового каталога file_cache откройте приложение ApkCacheTest. Он должен показать один файл test.txt и его содержимое. На этом снимке экрана показано, как эти результаты отображаются в пользовательском интерфейсе.
Рисунок 1. Результаты ApkCacheTest