Diese Seite wurde von der Cloud Translation API übersetzt.

APK-Caching

In diesem Dokument wird der Entwurf einer APK-Caching-Lösung für eine schnelle Installation beschrieben. auf einem Gerät, das A/B-Partitionen unterstützt,

OEMs können Preloads und beliebte Apps in den APK-Cache platzieren, der hauptsächlich leere B-Partition auf neuen A/B-partitionierten Geräten ohne Beeinträchtigung in jedem nutzerseitigen Datenbereich. Wenn auf dem Gerät ein APK-Cache verfügbar ist, werden neue oder Geräte, die vor Kurzem auf die Werkseinstellungen zurückgesetzt wurden, sind nahezu sofort einsatzbereit, wo er APK-Dateien von Google Play herunterladen muss.

Anwendungsfälle

Vorinstallierte Apps für eine schnellere Einrichtung in B-Partition speichern
Speichern Sie beliebte Apps für eine schnellere Wiederherstellung in der B-Partition.

Voraussetzungen

Für diese Funktion ist Folgendes erforderlich:

Android 8.1 (O MR1) installiert
A/B-Partition implementiert

Vorab geladene Inhalte können nur beim ersten Start kopiert werden. Der Grund dafür ist, A/B-Systemupdates unterstützt, speichert die B-Partition System-Image-Dateien, sondern vorab geladene Inhalte wie Demo-Ressourcen für den Einzelhandel, OAT-Dateien und der APK-Cache Nachdem Ressourcen in „/data“ kopiert wurden -Partition (dies geschieht beim ersten Start), wird die B-Partition von Over-the-Air (OTA) Updates zum Herunterladen aktualisierter Versionen des System-Images.

Daher kann der APK-Cache nicht über OTA aktualisiert werden. kann nur vorab geladen werden, in einer Fabrik. Das Zurücksetzen auf die Werkseinstellungen betrifft nur die /data-Partition. Das System B enthält noch den vorinstallierten Inhalt, bis das OTA-Image heruntergeladen wurde. Nach dem Zurücksetzen auf die Werkseinstellungen durchläuft das System den ersten Startvorgang. Das bedeutet APK Caching ist nicht verfügbar, wenn das OTA-Image auf die B-Partition heruntergeladen wird. wird das Gerät auf die Werkseinstellungen zurückgesetzt.

Implementierung

Ansatz 1: Inhalt aktiviert system_other partition

Pro: Vorinstallierte Inhalte gehen nach dem Zurücksetzen auf die Werkseinstellungen nicht verloren. nach einem Neustart aus der B-Partition kopiert.

Nachteil: Erfordert Speicherplatz auf Partition B. Nach Zurücksetzen auf Werkseinstellungen starten benötigt mehr Zeit, um vorab geladene Inhalte zu kopieren.

Damit Vorabladevorgänge beim ersten Start kopiert werden können, ruft das System ein Skript auf in „/system/bin/preloads_copy.sh“. Das Skript wird mit einer einzigen Argument (Pfad zum schreibgeschützten Bereitstellungspunkt für system_b Partition):

Nehmen Sie die folgenden gerätespezifischen Änderungen vor, um die Funktion zu implementieren. Hier ist eine Beispiel von Marlin:

Fügen Sie das Skript für den Kopiervorgang zum device-common.mk hinzu. (in diesem Fall device/google/marlin/device-common.mk). Beispiel:
```
# 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
```
Die Beispielskriptquelle findest du unter device/google/marlin/preloads_copy.sh.
Bearbeiten Sie die Datei init.common.rc, damit der notwendige /data/preloads-Verzeichnisse und Unterverzeichnisse:
```
mkdir /data/preloads 0775 system system
mkdir /data/preloads/media 0775 system system
mkdir /data/preloads/demo 0775 system system
```
Die Quelle der Beispieldatei init finden Sie hier: device/google/marlin/init.common.rc

Definieren Sie eine neue SELinux-Domain in der Datei 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;

Eine SELinux-Beispieldatei finden Sie unter /device/google/marlin/+/main/sepolicy/preloads_copy.te.

Domain in einem neuen /sepolicy/file_contexts registrieren Datei:
```
/system/bin/preloads_copy\.sh     u:object_r:preloads_copy_exec:s0
```
Ein Beispiel für eine SELinux-Kontextdatei finden Sie unter device/google/marlin/sepolicy/preloads_copy.te.
Bei der Erstellung muss das Verzeichnis mit vorab geladenen Inhalten in den Partition 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)
```
Dies ist ein Beispiel für eine Änderung in einem Makefile, mit dem das Kopieren des APK-Cache möglich ist aus dem Git-Repository des Anbieters (in unserem Fall Hersteller/google_devices/marlin/preloads) in den Speicherort der Partition „system_other“ ein. die später nach /data/preloads kopiert werden, wenn das Gerät zum ersten Mal startet . Dieses Skript wird bei der Build-Erstellung ausgeführt, um das Image „system_other“ vorzubereiten. Es wird erwartet, vorab geladenen Inhalten, die unter "vendor/google_devices/marlin/preloads" verfügbar sind. OEM können Sie den tatsächlichen Namen/Pfad des Repositorys auswählen.
Der APK-Cache befindet sich in /data/preloads/file_cache und wurde folgendes Layout:
```
/data/preloads/file_cache/
    app.package.name.1/
          file1
          fileN
    app.package.name.N/
```
Dies ist die endgültige Verzeichnisstruktur auf den Geräten. OEMs können kostenlos wählen Implementierung, solange die endgültige Dateistruktur die wie oben beschrieben.

Ansatz 2. Inhalte mit Nutzerdaten Bild wurde werkseitig geflasht

Bei diesem alternativen Ansatz wird davon ausgegangen, dass vorab geladener Inhalt bereits in das Verzeichnis /data/preloads in der Partition /data.

Pro: Sofort einsatzbereit – Sie müssen das Gerät nicht selbst herstellen. Anpassungen, um Dateien beim ersten Start zu kopieren. Inhalt befindet sich bereits auf der Partition /data.

Nachteil: Vorab geladene Inhalte gehen nach dem Zurücksetzen auf die Werkseinstellungen verloren. Während Für manche ist dies akzeptabel. Für OEMs, die Geräte nach einer Qualitätskontrolle zurücksetzen.

Die neue @SystemApi-Methode getPreloadsFileCache() wurde zu android.content.Context. Sie gibt einen absoluten Pfad App-spezifisches Verzeichnis im vorab geladenen Cache.

Die neue Methode IPackageManager.deletePreloadsFileCache wurde hinzugefügt. zum Löschen des Verzeichnisses „preloads“, um den gesamten Speicherplatz freizugeben. Die Methode kann kann nur von Apps mit SYSTEM_UID aufgerufen werden, d.h. vom Systemserver oder den Einstellungen.

App-Vorbereitung

Nur privilegierte Apps können auf das Cache-Verzeichnis für Vorabladevorgänge zugreifen. Dafür Zugriff haben, müssen Apps im Verzeichnis /system/priv-app installiert werden.

Zertifizierungsstufe

Nach dem ersten Start sollte sich der Inhalt des Geräts im /data/preloads/file_cache-Verzeichnis.
Der Inhalt im Verzeichnis file_cache/ muss gelöscht werden, wenn der Gerät hat nur noch wenig Speicherplatz.

Verwenden Sie das Beispiel ApkCacheTest. App zum Testen des APK-Cache.

Erstellen Sie die Anwendung, indem Sie den folgenden Befehl im Stammverzeichnis ausführen:
```
make ApkCacheTest
```

Installieren Sie die App als privilegierte App. Denken Sie daran, dass nur privilegierte Apps auf den APK-Cache zugreifen können. Dafür ist ein gerootetes Gerät erforderlich:

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

Simulieren Sie bei Bedarf das Dateicache-Verzeichnis und seinen Inhalt (erfordert zusätzlich Root-Berechtigungen):

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"

App testen Nachdem Sie die App installiert und das file_cache-Testverzeichnis erstellt haben, öffnen Sie die App „ApkCacheTest“. Es sollte eine Datei test.txt und ihr Inhalt angezeigt werden. In diesem Screenshot sehen Sie, wie diese Ergebnisse auf der Benutzeroberfläche dargestellt werden.
Abbildung 1: Ergebnisse von ApkCacheTest.