Ta strona została przetłumaczona przez Cloud Translation API.

Dostosuj aplikacje

Teraz, gdy w aplikacjach znajdują się komponenty i zasoby Car UI, producenci OEM muszą zapewnić dwie nakładki, aby dostosować te aplikacje:

Nakładka czasu kompilacji dodaje wszelkie zasoby potrzebne do nakładki zasobów środowiska wykonawczego (RRO). To zawiera:
- Rysunki
- Style (na przykład wygląd tekstu)
- Udostępnione zasoby (na przykład kolory)
Folder nakładki RRO zawiera zasoby użyte do wygenerowania jednego RRO na aplikację docelową. Zasoby te mogą odnosić się wyłącznie do:
- Wartości zdefiniowane w ramach tego samego RRO (na przykład dla koloru będzie to wartość szesnastkowa).
- Zasoby platformy Android (na przykład @android:color/accent ).
- Zasób zdefiniowany w powyższej nakładce czasu kompilacji.

Struktura ogólna

Proponowana struktura nakładki dostosowywania jest następująca:

<path-to-OEM-overlays>/
- overlay/framework/base/core/res/ . Zasoby nakładki w czasie kompilacji
- rro/
  - Android.mk . Plik Makefile używany do generowania RRO dla każdego pakietu docelowego w oparciu o zasoby zawarte w tym folderze.
  - AndroidManifest.xml . Szablon pliku manifestu używany przez powyższy plik makefile.
  - res/ . Nakładki środowiska wykonawczego, które można zastosować 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łużyć w ramach jednego celu kompilacji (zobacz Obsługa wielu marek ).

Nakładki zasobów środowiska wykonawczego

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

Nie można odwoływać się do identyfikatorów zasobów zdefiniowanych w docelowym pliku APK ani w samym RRO. Oznacza to, że RRO nie mogą dodawać nowych identyfikatorów, takich jak nowe rysunki, kolory lub style.
Móc odnoszą się do identyfikatorów zasobów zdefiniowanych w frameworku, niezależnie od tego, czy zasoby te są zdefiniowane w /frameworks/base/core/res , czy za pomocą nakładki w czasie kompilacji. Do tych identyfikatorów należy odwoływać się za pomocą android: name-space:
- W przypadku publicznych RRO DeviceDefault użyj android .
  Na przykład @android:style/TextAppearance.DeviceDefault.Large .
- W przypadku wszystkich innych (niepublicznych lub zasobów dodanych poprzez nakładkę 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 poniższym przykładzie RRO_PACKAGE_NAME i TARGET_PACKAGE_NAME są symbolami zastępczymi plików makefile:

<?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 następującym pliku makefile definiuje przedrostek, jaki miałyby 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

Skonfiguruj RRO

Obsługiwany jest nowy plik konfiguracyjny overlayable.xml , którego można użyć do zdefiniowania kontroli dostępu. Można na przykład określić, kto może nakładać zasoby i na które zasoby. W rezultacie zasoby można teraz grupować na różne sposoby, aby umożliwić nakładanie ich na siebie przez różne RRO.

Aby skonfigurować kontrolę dostępu RRO:

W folderze res/values utwórz plik overlayable.xml .
Utwórz znaczniki zasobów <overlayable> .
Zdefiniuj atrybut name dla znacznika <overlayable> , który musi być unikalny w pakiecie. Każda nakładka może być kierowana tylko na jedną grupę, na którą można się nałożyć.
Zdefiniuj tag <policy> wewnątrz <overlayable> .

Zdefiniuj grupy zasobów, które można nakładać. Na przykład:

  <resources>
      <overlayable name="OverlayableResources">
          <policy type="public">
              <item type="string" name="app_title" />
          </policy>
      </overlayable>
  </resources>

Aby zastosować następujące zmiany w projekcie RRO:

W folderze res/xml utwórz plik overlays.xml . Zobacz wpis w przykładowym kodzie poniżej, aby zapoznać overlay .
Zdefiniuj zasoby, które mają zostać zastąpione.
Dodaj android:resourcesMap="@xml/overlays" do tagu <overlay> w pliku AndroidManifest.xml . Na przykład w poniższym przykładzie kodu zobacz wpis dla <overlay> .
Ustaw android:isStatic=”true” dla nakładki statycznej. Każda nakładka może być kierowana tylko na jedną z grup, które można nałożyć.

Rozważ następujący przykład. Pierwsza sekcja należy do AndroidManifest.xml , natomiast druga sekcja dotyczy pliku 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, istniejące wcześniej RRO działają w systemie Android 10. Zastrzeżenie polega na tym, że aby zainstalować pakiety za pomocą PackageManagerRRO, pakiety muszą być preinstalowane lub podpisane tym samym kluczem co aplikacja docelowa. W systemie Android 10 pliki układu można nakładać. Wymaga to jednak użycia requireViewById() podczas uzyskiwania widoku zamiast findViewById() . W systemie Android 10 tę zmianę zaimplementowano w car-ui-lib w celu obsługi nakładek układu.

Następna główna wersja Androida umożliwi nałożenie pliku układu i zdefiniowanie nowych zasobów w pakiecie RRO oraz odwoływanie się do nich wewnętrznie.

Dodaj zasoby specyficzne dla OEM

Aby pokonać ograniczenia RRO, które uniemożliwiają dodanie zasobów OEM:

Rozszerzaj frameworki/bazę za pomocą nakładki w czasie kompilacji , dodając wszelkie niezbędne zasoby.
Skorzystaj z tych zasobów od RRO OEM, używając przestrzeni nazw *android:

Na przykład poniżej przedstawiono sposób dodania rysunku specyficznego dla OEM i użycia go w 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>

Obsługuj wiele marek

Pliki manifestu RRO mają składnię umożliwiającą ich warunkowe zastosowanie w oparciu o właściwości systemu. Aby obsłużyć wiele marek w jednym obrazie systemu, producenci OEM mogą użyć tego w następujący sposób (patrz Struktura ogólna ).

<?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 android:requiredSystemPropertyName i android:requiredSystemPropertyValue spowodowałaby włączenie tego RRO tylko wtedy, gdy odpowiednia właściwość systemowa odpowiada podanej wartości. Producenci OEM mogą następnie zdefiniować wiele takich RRO, wszystkie z nich będą włączone statycznie i tylko jeden będzie aktywny w danym momencie.

Dodaj bibliotekę Car UI do celu

Aby włączyć bibliotekę Car UI do docelowego systemu Android, musisz dołączyć następujący 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 \
      ...

Uwaga: prefiks oem- musi odpowiadać zmiennej CAR_UI_RRO_SET_NAME zdefiniowanej w RRO Android.mk . Powyższy kod:

Powoduje, że <path-to-OEM-overlays>/rro/Android.mk generuje jedno RRO dla każdego z pakietów wymienionych w CAR_UI_RRO_PACKAGE_NAMES .
Zawiera wygenerowane RRO w PRODUCT_PACKAGES .
Zawiera nakładkę na czas kompilacji w PRODUCT_PACKAGE_OVERLAYS , która umożliwia dodanie zasobów specyficznych dla OEM.

Aby dowiedzieć się, które pakiety obsługują car-ui-lib , zobacz Lista pakietów zawierających car-ui-lib .