Buforowanie pliku APK

Ten dokument opisuje projekt rozwiązania do buforowania plików APK, które umożliwia szybką instalację. wstępnie załadowanych aplikacji na urządzeniu z obsługą partycji A/B.

OEM może umieszczać wczytywane z wyprzedzeniem i popularne aplikacje w pamięci podręcznej plików APK przechowywanej pustej partycji B na nowych urządzeniach z partycją A/B bez wpływu na w każdej przestrzeni danych dostępnej dla użytkownika. Jeśli na urządzeniu jest dostępna pamięć podręczna pakietów APK, nowe lub urządzenia, które zostały ostatnio przywrócone do ustawień fabrycznych, są gotowe do użycia niemal natychmiast, bez musisz pobrać pliki APK z Google Play.

Przykłady zastosowań

  • Przechowuj wstępnie załadowane aplikacje na partycji B, aby przyspieszyć konfigurację
  • Przechowuj popularne aplikacje na partycji B, aby szybciej przywrócić dane

Wymagania wstępne

Aby można było korzystać z tej funkcji, urządzenie musi mieć:

  • Zainstalowana wersja Androida 8.1 (O MR1)
  • Wdrożono partycję A/B

Wstępnie wczytane treści można skopiować tylko podczas pierwszego uruchomienia. Dzieje się tak, ponieważ na urządzeniach obsługujących aktualizacje systemu A/B, partycja B nie przechowuje za pomocą plików graficznych systemu, a zamiast tego wstępnie wczytywanych treści, np. zasobów w wersji demonstracyjnej plików OAT i pamięci podręcznej plików APK. Po skopiowaniu zasobów do katalogu /data partycji (dzieje się to przy pierwszym uruchomieniu), partycja B będzie używana przez sieć bezprzewodową (OTA). aktualizacje pobierania zaktualizowanych wersji obrazu systemu.

Dlatego nie można aktualizować pamięci podręcznej plików APK za pomocą funkcji OTA. może być wstępnie wczytywany w fabryce. Przywrócenie do ustawień fabrycznych wpływa tylko na partycję /data. System B partycja wciąż zawiera wstępnie wczytywane treści, dopóki obraz OTA nie zostanie pobrany. Po przywróceniu ustawień fabrycznych system uruchomi się ponownie. Oznacza to, że plik APK buforowanie nie jest dostępne, jeśli obraz OTA został pobrany na partycję B i urządzenie zostanie przywrócone do ustawień fabrycznych.

Implementacja

Sposób 1. Włącz treści inna partycja systemowa

Zalety: wstępnie załadowane treści nie zostaną utracone po przywróceniu ustawień fabrycznych. zostaną skopiowane z partycji B po ponownym uruchomieniu.

Wada: wymaga miejsca na partycji B. Uruchamia się po przywróceniu ustawień fabrycznych wymaga dodatkowego czasu na skopiowanie wstępnie wczytywanych treści.

Aby wstępne wczytanie zostały skopiowane podczas pierwszego uruchomienia, system wywołuje skrypt w usłudze /system/bin/preloads_copy.sh. Skrypt jest wywoływany za pomocą (ścieżka do punktu podłączania tylko do odczytu dla instancji system_b) partycja):

Aby korzystać z tej funkcji, wprowadź zmiany zależnie od urządzenia. Oto przykład z Marlina:

  1. Dodaj do narzędzia device-common.mk skrypt wykonujący kopiowanie (w tym przypadku 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
    
    Przykładowe źródło skryptu znajdziesz na device/google/marlin/preloads_copy.sh
  2. Edytuj plik init.common.rc, aby utworzył niezbędne /data/preloads katalogi i podkatalogi:
    mkdir /data/preloads 0775 system system
    mkdir /data/preloads/media 0775 system system
    mkdir /data/preloads/demo 0775 system system
    
    Przykładowe źródło pliku init znajdziesz tutaj: device/google/marlin/init.common.rc
  3. Zdefiniuj nową domenę SELinux w pliku 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;
    
    Przykładowy plik domeny SELinux znajdziesz na /device/google/marlin/+/main/sepolicy/preloads_copy.te
  4. Zarejestruj domenę w nowym miejscu /sepolicy/file_contexts plik:
    /system/bin/preloads_copy\.sh     u:object_r:preloads_copy_exec:s0
    
    Przykładowy plik kontekstu SELinux znajdziesz na stronie device/google/marlin/sepolicy/preloads_copy.te
  5. Podczas kompilacji katalog ze wstępnie wczytywaną treścią musi zostać skopiowany do system_other partycja:
    # 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)
    
    To przykład zmiany w pliku Makefile, która umożliwia kopiowanie pamięci podręcznej plików APK z repozytorium Git dostawcy (w naszym przypadku było to dostawcy/google_devices/marlin/preloads) do lokalizacji na partycji system_other który zostanie później skopiowany do folderu /data/preloads przy pierwszym uruchomieniu urządzenia obecnie się znajdujesz. Ten skrypt jest uruchamiany podczas kompilacji, aby przygotować obraz system_other. Oczekuje, wstępnie załadowane materiały, które będą dostępne w Vendor/google_devices/marlin/preloads. OEM pozwala wybrać rzeczywistą nazwę/ścieżkę repozytorium.
  6. Pamięć podręczna pliku APK znajduje się w regionie /data/preloads/file_cache i ma ten układ:
    /data/preloads/file_cache/
        app.package.name.1/
              file1
              fileN
        app.package.name.N/
    
    Jest to ostateczna struktura katalogów na urządzeniach. OEM ma swobodę wyboru z dowolną metodą wdrożeniową, o ile ostateczna struktura plików odzwierciedla opisanego powyżej.

Sposób 2. Treść dotycząca danych użytkownika obraz został wyrenderowany w fabryce

Ta metoda alternatywna zakłada, że wstępnie wczytywane treści są już uwzględnione katalogu /data/preloads na partycji /data.

Za: działa po uruchomieniu – nie trzeba tworzyć urządzenia dostosowania kopiowania plików przy pierwszym uruchomieniu. Treść jest już w /data partycja.

Wada: wstępnie wczytane treści zostają utracone po przywróceniu ustawień fabrycznych. Choć W niektórych przypadkach może to być akceptowalne, ale nie zawsze sprawdza się w przypadku producentów OEM, którzy resetować urządzenia po przeprowadzeniu kontroli jakości.

Nowa metoda @SystemApi (getPreloadsFileCache()) została dodana do android.content.Context Zwraca ścieżkę bezwzględną do katalogu aplikacji we wstępnie załadowanej pamięci podręcznej.

Dodano nową metodę (IPackageManager.deletePreloadsFileCache) która umożliwia usunięcie katalogu wstępnego wczytywania i wolne miejsce. Przy użyciu tej metody można może być wywoływana tylko przez aplikacje z systemem SYSTEM_UID, tj. z serwerem systemu lub ustawieniami.

Przygotowanie aplikacji

Tylko aplikacje z podwyższonymi uprawnieniami mają dostęp do katalogu pamięci podręcznej wczytywania wstępnego. Do tego celu dostęp, aplikacje muszą być zainstalowane w katalogu /system/priv-app.

Weryfikacja

  • Po pierwszym uruchomieniu urządzenie powinno znajdować się w Katalog /data/preloads/file_cache.
  • Zawartość katalogu file_cache/ musi zostać usunięta, jeśli na urządzeniu zaczyna brakować pamięci.

Użyj przykładowego ApkCacheTest. to aplikacja do testowania pamięci podręcznej plików APK.

  1. Utwórz aplikację, uruchamiając to polecenie z katalogu głównego:
    make ApkCacheTest
    
  2. Zainstaluj aplikację jako aplikację z podwyższonymi uprawnieniami. Pamiętaj, że dostęp do pamięci podręcznej plików APK mają tylko aplikacje z podwyższonymi uprawnieniami. Wymaga to urządzenia z dostępem do roota:
    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
    
  3. W razie potrzeby przeprowadź symulację katalogu pamięci podręcznej plików i jego zawartości (wymagaj też uprawnień użytkownika 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"
    
  4. Przetestuj aplikację. Po zainstalowaniu aplikacji i utworzeniu katalogu testowego file_cache otwórz aplikację ApkCacheTest. Powinien wyświetlić się 1 plik test.txt i jego zawartość. Spójrz na ten zrzut ekranu, by zobaczyć, jak te wyniki wyglądają w interfejsie.

    Rysunek 1. Wyniki testu ApkCacheTest.