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 nazwandroid::- 
        
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żejRRO_PACKAGE_NAMEiTARGET_PACKAGE_NAMEto 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órymoemw 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:
- W folderze 
res/valuesutwórzoverlayable.xml. - Utwórz tagi zasobu 
<overlayable>. - Zdefiniuj atrybut 
namedla 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ą. - Zdefiniuj tag 
<policy>wewnątrz tagu<overlayable>. - 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:
- W folderze 
res/xmlutwórzoverlays.xml. Informacje o wartościoverlayznajdziesz w przykładowym kodzie poniżej. - Określ zasoby, które mają zostać zastąpione.
 - Dodaj 
android:resourcesMap="@xml/overlays"do tagu<overlay>wAndroidManifest.xml. Na przykład w przykładowym kodzie poniżej zwróć uwagę na wpis<overlay>. - 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.mkgeneruje jeden RRO dla każdego pakietu o nazwie podanej wCAR_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.