Ahora que los componentes y recursos de la biblioteca Car UI están en las aplicaciones, para personalizar estas aplicaciones, los OEM deben proporcionar dos superposiciones:
Superposición de tiempo de construcción. Esta superposición agregaría los recursos necesarios para las RRO. Esto incluye:
- Dibujables
- Estilos (por ejemplo, apariencias de texto)
Recursos compartidos (por ejemplo, colores)
Superposición RRO. Esta carpeta contiene los recursos utilizados para generar una RRO por aplicación de destino. Estos recursos solo pueden referirse a:
- Valores definidos dentro de la misma RRO (por ejemplo, para un color sería un valor hexadecimal).
- Recursos del marco de trabajo de Android (por ejemplo,
@android:color/accent
). - Un recurso definido en la superposición de tiempo de compilación anterior.
Estructura general
La estructura superpuesta de personalización propuesta es la siguiente:
<path-to-OEM-overlays>/
overlay/framework/base/core/res/
. Recursos superpuestos en tiempo de compilaciónrro/
Android.mk
. Makefile utilizado para generar las RRO para cada paquete de destino en función de los recursos contenidos en esta carpeta.AndroidManifest.xml
. Una plantilla de archivo de manifiesto utilizada por el archivo MAKE anterior.res/
. Superposiciones de tiempo de ejecución para aplicar a todas las aplicaciones de destino.
Los OEM pueden tener más de una de estas estructuras, según la cantidad de marcas que deseen manejar en un solo objetivo de compilación (consulte Manejo de varias marcas ).
Superposiciones de recursos de tiempo de ejecución
La carpeta RRO en la carpeta de superposición OEM debe contener recursos que se aplicarán a todas las aplicaciones de destino. Las RRO tienen limitaciones que afectan su capacidad para superponer recursos compuestos. En resumen, una RRO:
No se puede hacer referencia a los identificadores de recursos definidos en el APK de destino o en el propio RRO. Esto significa que las RRO no pueden agregar nuevos identificadores, como nuevos elementos de diseño, colores o estilos.
Poder se refieren a los identificadores de recursos definidos en el marco, ya sea que esos recursos estén definidos en
/frameworks/base/core/res
o por medio de una superposición de tiempo de compilación. Estos identificadores deben referirse usando el espacio de nombresandroid:
::Para las RRO de DeviceDefault públicas , use
android
Por ejemplo,@android:style/TextAppearance.DeviceDefault.Large
para todos los demás (recursos no públicos o agregados a través de la superposición en tiempo de compilación), use
*android
Por ejemplo,@*android/style:TextAppearance.OEM.Brand1.Title
Además de los recursos, la carpeta RRO debe contener:
AndroidManifest.xml
. En el ejemplo a continuación,RRO_PACKAGE_NAME
yTARGET_PACKAGE_NAME
son marcadores de posición para los archivos 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
en el queoem
en el siguiente archivo MAKE define el prefijo que tendrían todas las RRO generadas.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
Configuración de superposiciones de RRO
Se admite un nuevo archivo de configuración, overlayable.xml
, que puede usar para definir controles de acceso. Por ejemplo, puede especificar quién puede superponer recursos y qué recursos pueden superponerse. Como resultado, los recursos ahora se pueden agrupar de diferentes maneras para que estén disponibles para ser superpuestos por diferentes RRO.
Para configurar el control de acceso RRO:
- En la carpeta
res/values
, creeoverlayable.xml
. - Cree las etiquetas de recursos
<overlayable>
. - Defina el atributo de
name
para la etiqueta<overlayable>
, que debe ser único en el paquete. Cada superposición puede dirigirse solo a un grupo superponible. - Defina la etiqueta
<policy>
dentro de<overlayable>
. - Defina los grupos de recursos que se pueden superponer. Por ejemplo:
<resources> <overlayable name="OverlayableResources"> <policy type="public"> <item type="string" name="app_title" /> </policy> </overlayable> </resources>
Para aplicar los siguientes cambios a su proyecto RRO:
- En la carpeta
res/xml
, creeoverlays.xml
. Consulte la entrada en el ejemplo de código a continuación para ver laoverlay
. - Defina los recursos que se anularán.
- Agrega
android:resourcesMap="@xml/overlays"
a la etiqueta<overlay>
enAndroidManifest.xml
. Por ejemplo, en el ejemplo de código a continuación, vea la entrada para<overlay>
. - Configure
android:isStatic=”true”
para una superposición estática. Cada superposición puede dirigirse solo a uno de los grupos que se pueden superponer.
Considere el siguiente ejemplo. La primera sección pertenece a AndroidManifest.xml
mientras que la segunda sección pertenece a 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>
Con una advertencia, las RRO existentes anteriormente seguirán funcionando en Android 10. La advertencia es que, para instalarse con PackageManagerRRO, los paquetes deben estar preinstalados o firmados con la misma clave que la aplicación de destino. En Android 10, los archivos de diseño se pueden superponer. Sin embargo, hacerlo requiere el uso de requireViewById()
al obtener la vista en lugar de findViewById()
. En Android 10, este cambio se implementó en car-ui-lib para admitir superposiciones de diseño.
La próxima versión principal de Android le permitirá superponer un archivo de diseño y definir nuevos recursos en el paquete RRO y consultarlos internamente.
Adición de recursos específicos de OEM
Para superar las limitaciones de RRO que impiden que se agreguen recursos OEM:
- Amplíe los marcos/base utilizando una superposición en tiempo de compilación , agregando los recursos necesarios.
- Consulte estos recursos de las RRO de OEM mediante
*android:
espacio de nombres.
Por ejemplo, la siguiente es una forma de agregar un elemento de diseño específico de OEM y usarlo en una 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>
Manejo de múltiples marcas
Los archivos de manifiesto RRO tienen una sintaxis que les permite aplicarse condicionalmente según las propiedades del sistema. Para manejar múltiples marcas en una sola imagen de sistema, los OEM pueden usar esto de la siguiente manera (ver Estructura general ).
<?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>
La sintaxis de android:requiredSystemPropertyName
y android:requiredSystemPropertyValue
haría que este RRO se habilitara solo si la propiedad del sistema correspondiente coincide con el valor proporcionado. Los OEM pueden definir varias de estas RRO, todas ellas habilitadas estáticamente y tener solo una activa a la vez.
Agregar biblioteca de interfaz de usuario de automóvil a un destino
Para incorporar la biblioteca Car UI a un destino de Android, debe incluir el siguiente fragmento de código:
# 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 \ ...
Causas
<path-to-OEM-overlays>/rro/Android.mk
genera un RRO para cada uno de los paquetes nombrados enCAR_UI_RRO_PACKAGE_NAMES
.Incluye los RRO generados en
PRODUCT_PACKAGES
.Incluye una superposición de tiempo de compilación en
PRODUCT_PACKAGE_OVERLAYS
para agregar recursos específicos de OEM.
Para saber qué paquetes son compatibles car-ui-lib
, consulte Paquetes compatibles con car-ui-lib .