Dostosowywanie aplikacji

Teraz, gdy komponenty i zasoby biblioteki Car UI są już wbudowane w aplikacje, producenci OEM muszą udostępnić 2 warstwy:

  • Nakładka w czasie kompilacji dodaje wszystkie zasoby potrzebne do nakładki zasobów środowiska wykonawczego (RRO). Obejmuje to m.in.:

    • Obiekty do rysowania
    • style (np. wygląd tekstu);
    • Udostępnione zasoby (np. kolory)

  • Folder nakładka RRO zawiera zasoby używane do generowania jednego RRO na każdą aplikację docelową. Te zasoby mogą się odnosić tylko do:

    • wartości zdefiniowane w ramach tego samego RRO (np. w przypadku koloru jest to wartość szesnastkowa);
    • Zasoby platformy Android (np. @android:color/accent).
    • Zasób zdefiniowany w powyższym nakładce w czasie kompilacji.

Struktura ogólna

Proponowana struktura nakładki personalizacji:

  • <path-to-OEM-overlays>/

    • overlay/framework/base/core/res/. Zasoby nakładek w czasie kompilacji

    • rro/

      • Android.mk. Makefile służy do generowania RRO dla każdego docelowego pakietu na podstawie zasobów zawartych w tym folderze.

      • AndroidManifest.xml. Szablon pliku manifestu używany przez powyższy makefile.

      • res/. Nakładki w czasie działania, które mają być stosowane do wszystkich aplikacji docelowych.

Producenci OEM mogą mieć więcej niż jedną z tych struktur w zależności od liczby marek, które chcą obsługiwać w ramach jednego celu kompilacji (patrz Obsługa wielu marek).

Nakładki zasobów środowiska wykonawczego

Folder RRO w folderze nakładki OEM powinien zawierać zasoby, które mają być stosowane we wszystkich docelowych aplikacjach. RRO mają ograniczenia wpływające na ich zdolność do nakładania złożonych zasobów. Podsumowując, RRO:

  • Nie może odwoływać się do identyfikatorów zasobów zdefiniowanych w docelowym pakiecie APK lub w samym pliku RRO. Oznacza to, że RRO nie mogą dodawać nowych identyfikatorów, takich jak nowe obiekty rysowane, kolory czy style.

  • Może odwoływać się do identyfikatorów zasobów zdefiniowanych w ramach, niezależnie od tego, czy zasoby te są zdefiniowane w pliku /frameworks/base/core/res, czy za pomocą nakładki na etapie kompilacji. Te identyfikatory muszą być podawane w ramach przestrzeni nazw android::

    • W przypadku publicznych RRO DeviceDefault użyj wartości android.
      Na przykład: @android:style/TextAppearance.DeviceDefault.Large.

    • W przypadku wszystkich innych zasobów (niepublicznych lub dodanych za pomocą nakładki w czasie kompilacji) użyj *android.
      Na przykład: @*android/style:TextAppearance.OEM.Brand1.Title.

Oprócz zasobów folder RRO musi zawierać:

  • AndroidManifest.xml. W przykładzie poniżej RRO_PACKAGE_NAME i TARGET_PACKAGE_NAME to obiekty zastępcze dla plików make:

    <?xml version=“1.0” encoding=“utf-8”?>
<manifest xmlns:android=“http://schemas.android.com/apk/res/android”
    package=“{{RRO_PACKAGE_NAME}}” />
    <application android:hasCode=“false” />
    <overlay android:priority=“10”
        android:targetPackage=“{{TARGET_PACKAGE_NAME}}”
        android:requiredSystemPropertyName=“ro.product.sku”
        android:requiredSystemPropertyValue=“<your-product-sku>” />
</manifest>
  • Android.mk, w którym oem w tym pliku make określa prefiks, który będą miały wszystkie wygenerowane RRO. 
      LOCAL_PATH := $(call my-dir)
  include $(CLEAR_VARS)
  CAR_UI_RRO_SET_NAME := oem
  CAR_UI_RESOURCE_DIR := $(LOCAL_PATH)/res
  CAR_UI_RRO_TARGETS := $(CAR_UI_RRO_PACKAGE_NAMES)
  include packages/apps/Car/libs/car-ui-lib/generate_rros.mk

Konfigurowanie RRO

Obsługiwany jest nowy plik konfiguracji overlayable.xml, za pomocą którego można definiować kontrolę dostępu. Możesz na przykład określić, kto może nakładać zasoby i które zasoby mogą być nakładane. Dzięki temu zasoby można grupować na różne sposoby, aby umożliwić nakładanie na nie różnych RRO.

Aby skonfigurować kontrolę dostępu RRO:

  1. W folderze res/values utwórz overlayable.xml.
  2. Utwórz tagi zasobu <overlayable>.
  3. Zdefiniuj atrybut name dla tagu <overlayable>, który musi być unikalny w pakiecie. Każde nakładanie może dotyczyć tylko jednej grupy, na którą można nałożyć inną.
  4. Zdefiniuj tag <policy> wewnątrz tagu <overlayable>.
  5. Określ grupy zasobów, które można nakładać. Przykład: 
      <resources>
      <overlayable name="OverlayableResources">
          <policy type="public">
              <item type="string" name="app_title" />
          </policy>
      </overlayable>
  </resources>

Aby zastosować te zmiany w projekcie RRO:

  1. W folderze res/xml utwórz overlays.xml. Informacje o wartości overlay znajdziesz w przykładowym kodzie poniżej.
  2. Określ zasoby, które mają zostać zastąpione.
  3. Dodaj android:resourcesMap="@xml/overlays" do tagu <overlay> w AndroidManifest.xml. Na przykład w przykładowym kodzie poniżej zwróć uwagę na wpis <overlay> .
  4. Aby ustawić stałą nakładkę, wybierz android:isStatic=”true”. Każda nakładka może być kierowana tylko na jedną z grup, na które można nakładać nakładki.

Rozważ ten przykład. Pierwsza sekcja należy do AndroidManifest.xml, a druga – do overlays.xml. 

  <manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="com.android.car.ui.rro"
      android:versionCode="1"
      android:versionName="1.0">
      <overlay android:targetName="OverlayableResources"
               android:resourcesMap="@xml/overlays"
               android:targetPackage="com.android.car.ui"
               android:priority="1"
               android:isStatic="false" />
  </manifest>
  <overlay>
      <item target="string/app_title" value="@ string/app_title" />
  </overlay>

Z jednym zastrzeżeniem: wcześniejsze wersje RRO działają w Androidzie 10. Aby można było zainstalować je za pomocą pakietu PackageManagerRRO, muszą one być wstępnie zainstalowane lub podpisane tym samym kluczem co aplikacja docelowa. W Androidzie 10 można nakładać pliki układu. Wymaga to jednak użycia parametru requireViewById() zamiast parametru findViewById(). W Androidzie 10 ta zmiana została wprowadzona do biblioteki car-ui-lib, aby obsługiwać nakładki układu.

Następna duża wersja Androida umożliwi nakładanie pliku układu i definiowanie nowych zasobów w pakiecie RRO oraz ich wewnętrzne wywoływanie.

Dodawanie zasobów dla OEM

Aby obejść ograniczenia RRO, które uniemożliwiają dodawanie zasobów OEM:

  • Rozszerzanie frameworków/podstaw za pomocą nakładki na etapie kompilacji, dodając wszelkie niezbędne zasoby.
  • Zapoznaj się z tymi zasobami z OEM RRO, używając nazewnictwa *android:.

Oto sposób dodawania rysowalnych obiektów dostępnych dla OEM-ów i ich używania w plikach RRO:

  • <path-to-OEM-overlays>

    • overlay/framework/base/core/res/res/drawable/

      • oem_background_drawable.xml

    • rro/res/values

      • drawables.xml

        <resources>
    <item type="drawable" name="car_ui_toolbar_background">
        @*android:drawable/oem_background_drawable
    </item>
</resources>

Praca z wieloma markami

Pliki manifestu RRO mają składnię, która umożliwia ich warunkowe stosowanie na podstawie właściwości systemu. Aby obsługiwać wiele marek w jednym obrazie systemu, OEM może użyć tego w następujący sposób (patrz Ogólna struktura). 

<?xml version=“1.0” encoding=“utf-8”?>
<manifest xmlns:android=“http://schemas.android.com/apk/res/android”
    package=“{{RRO_PACKAGE_NAME}}”/>
    <application android:hasCode=“false”/>
    <overlay android:priority=“10”
        android:targetPackage=“{{TARGET_PACKAGE_NAME}}”
        android:requiredSystemPropertyName=“ro.product.sku”
        android:requiredSystemPropertyValue=“<your-product-sku>”/>
</manifest>

Składnia atrybutów android:requiredSystemPropertyName i android:requiredSystemPropertyValue spowoduje, że ta reguła RRO zostanie włączona tylko , jeśli odpowiednia właściwość systemowa będzie zgodna z podaną wartością. Producenci OEM mogą zdefiniować wiele takich RRO, z których wszystkie są włączone statycznie, a tylko jedno może być aktywne naraz.

Dodawanie biblioteki Car UI do celu

Aby włączyć bibliotekę interfejsu użytkownika Car do celu na Androida, musisz dodać ten fragment kodu: 

# Include build-time overlays
    PRODUCT_PACKAGE_OVERLAYS += \
      <path-to-oem-overlays>/overlay
    # Define package names to generate RROs for
    CAR_UI_RRO_PACKAGE_NAMES += \
      com.android.car.ui.paintbooth \
      com.android.car.media \
      com.android.car.dialer \
      com.android.car.linkviewer \
      com.android.car.settings \
      com.android.car.systemupdater \
      com.google.android.apps.automotive.inputmethod \
      com.google.android.apps.automotive.templates.host \
      ...
    # Include generated RROs
    PRODUCT_PACKAGES += \
      oem-com-android-car-ui-paintbooth \
      oem-com-android-car-media \
      oem-com-android-car-dialer \
      oem-com-android-car-linkviewer \
      oem-com-android-car-settings \
      oem-com-android-car-systemupdater \
      oem-com-google-android-apps-automotive-inputmethod \
      oem-com-google-android-apps-automotive-templates-host \
      ...

  • Sprawia, że <path-to-OEM-overlays>/rro/Android.mk generuje jeden RRO dla każdego pakietu o nazwie podanej w CAR_UI_RRO_PACKAGE_NAMES.

  • Obejmuje wygenerowane RRO w PRODUCT_PACKAGES.

  • Zawiera nakładkę na etapie kompilacji w pliku PRODUCT_PACKAGE_OVERLAYS, aby dodawać zasoby dla OEM.

Aby dowiedzieć się, które pakiety obsługują car-ui-lib, zapoznaj się z listą pakietów zawierających bibliotekę car-ui-lib.