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

Dostosowywanie aplikacji

Teraz komponenty i zasoby z biblioteki interfejsu Car UI przenieśliśmy do aplikacji, aby dostosować w przypadku tych aplikacji producent OEM musi dodać 2 nakładki:

Nakładka podczas kompilacji dodaje zasoby potrzebne do nakładek zasobów środowiska wykonawczego. Przykładowe zabezpieczenia:
- Elementy rysowalne
- style (np. wygląd tekstu).
- Udostępnione zasoby (np. kolory)
Folder Nakładka RRO zawiera zasoby użyte do wygenerowania 1 RRO na każde żądanie docelowej aplikacji. Te zasoby mogą odnosić się tylko do:
- Wartości zdefiniowane w tym samym RRO (np. w przypadku koloru będą to liczby szesnastkowe). ).
- Zasoby platformy Androida (np. @android:color/accent).
- Zasób zdefiniowany w powyższej nakładce czasu kompilacji.

Ogólna struktura

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

<path-to-OEM-overlays>/
- overlay/framework/base/core/res/ Zasoby nakładki podczas kompilacji
- rro/
  - Android.mk Plik programu Makefile używany do generowania RRO dla każdego pakietu docelowego na podstawie zasobów w tym folderze.
  - AndroidManifest.xml Szablon pliku manifestu używany przez powyższe rozwiązanie Makefile.
  - res/ Nakładki środowiska wykonawczego do wszystkich aplikacji docelowych.

OEM może mieć więcej niż 1 z tych struktur, w zależności od liczby marek, do których chcą w pojedynczym celu kompilacji (patrz Obsługujesz wiele marek).

Nakładki zasobów środowiska wykonawczego

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

Nie mogą odnosić się do identyfikatorów zasobów zdefiniowanych w docelowym pakiecie APK lub w pliku RRO. Oznacza to, że do RRO nie mogą dodawać nowych identyfikatorów, takich jak nowe elementy, które można przeciągać, kolory stylów.
Może odwoływać się do identyfikatorów zasobów zdefiniowanych w platformy, niezależnie od tego, czy te zasoby są zdefiniowane w zasadzie /frameworks/base/core/res, czy za pomocą środków podczas tworzenia. Do tych identyfikatorów należy się odwołać za pomocą atrybutu android: przestrzeń-nazw:
- W przypadku publicznych RRO w DeviceDefault użyj android.
  Na przykład: @android:style/TextAppearance.DeviceDefault.Large.
- Dla wszystkich innych (niepublicznych lub zasobów dodanych przez nakładkę czasu 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 oraz TARGET_PACKAGE_NAME to obiekty zastępcze dla plików Makefiles:

<?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 prefiks jakie 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

Konfigurowanie RRO

Obsługiwany jest nowy plik konfiguracji overlayable.xml, którego możesz użyć do zdefiniowania kontrolę dostępu. Możesz na przykład określić, kto może nakładać zasoby oraz które zasoby mogą być nakładane. Zasoby można teraz grupować na różne sposoby, które mogą być nałożone przez różne RRO.

Aby skonfigurować kontrolę dostępu RRO:

W folderze res/values utwórz overlayable.xml.
Utwórz <overlayable> tagów zasobów.
Zdefiniuj atrybut name dla tagu <overlayable>, który musi być niepowtarzalny w ramach pakietu. Każda nakładka może być kierowana tylko na jedną grupę, do której można nałożyć reklamy.
Zdefiniuj tag <policy> w elemencie <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ć w projekcie RRO te zmiany:

W folderze res/xml utwórz overlays.xml. Zobacz wpis w poniżej znajdziesz przykładowy kod dla domeny overlay.
Określ zasoby do zastąpienia.
Dodaj android:resourcesMap="@xml/overlays" do: <overlay> w tagu AndroidManifest.xml. W przykładowym kodzie poniżej znajdziesz wpis <overlay>
Ustaw android:isStatic=”true” jako nakładkę statyczną. Każda nakładka może być kierowana tylko i grupy, które można nakładać.

Przyjrzyjmy się temu przykładowi. Pierwsza sekcja należy do domeny AndroidManifest.xml a druga sekcja dotyczy 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>

Istnieje jednak pewne zastrzeżenie, że dotychczasowe reklamy RRO działają na Androidzie 10. Zastrzeżenie aby zainstalować pakiet za pomocą PackageManagerRRO, pakiety muszą być wstępnie zainstalowane lub podpisany tym samym kluczem co aplikacja docelowa. W Androidzie 10 pliki układu mogą być nałożone. Pamiętaj jednak: uzyskanie widoku wymaga użycia funkcji requireViewById() zamiast findViewById() W Androidzie 10 ta zmiana została wdrożona w komponencie car-ui-lib, obsługują nakładki układu.

Kolejna duża wersja Androida umożliwia nakładanie pliku układu zdefiniować nowe zasoby w pakiecie RRO i odwoływać się do nich wewnętrznie.

Dodaj zasoby konkretnego OEM

Aby przezwyciężyć ograniczenia RRO, które uniemożliwiają dodawanie zasobów OEM:

Rozbuduj platformy lub bazę za pomocą nakładki z czasem kompilacji (jeśli jest taka potrzeba) i zasobami Google Cloud.
Skorzystaj z tych zasobów w RRO OEM, używając formatu *android:.

Poniższy przykład pokazuje, jak dodać obiekt rysowalny określony przez OEM i użyć 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ługa wielu marek

Pliki manifestu RRO mają składnię umożliwiającą ich warunkowe stosowanie w zależności od systemu usług. Aby obsługiwać wiele marek w jednym obrazie systemu, producenci OEM mogą go użyć jako (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 instrukcji android:requiredSystemPropertyName oraz android:requiredSystemPropertyValue spowodowałby włączenie tego RRO tylko , jeśli odpowiednia właściwość systemowa jest zgodna z podaną wartością. OEM może następnie zdefiniować wiele te RRO, wszystkie są statycznie włączone i mają tylko 1 aktywny jednocześnie.

Dodaj do celu bibliotekę interfejsu samochodu

Aby dodać bibliotekę interfejsu samochodu do celu Androida, musisz uwzględnić 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 \
      ...

. Uwaga: prefiks oem- musi być zgodny z CAR_UI_RRO_SET_NAME zdefiniowaną w RRO Android.mk. Powyższy kod:

Powoduje, że <path-to-OEM-overlays>/rro/Android.mk generuje 1 RRO dla każdej z nich pakietów wymienionych w dokumencie CAR_UI_RRO_PACKAGE_NAMES.
Obejmuje wygenerowane RRO w PRODUCT_PACKAGES.
Zawiera nakładkę czasu kompilacji w PRODUCT_PACKAGE_OVERLAYS, aby dodać informacje dotyczące konkretnego OEM i zasobami Google Cloud.

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