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 kompilacjirro/
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ładzieRRO_PACKAGE_NAME
iTARGET_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órymoem
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 plikoverlayable.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 plikoverlays.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 plikuAndroidManifest.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 \ ...
Powoduje, że
<path-to-OEM-overlays>/rro/Android.mk
generuje jedno RRO dla każdego z pakietów wymienionych wCAR_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 .