Ahora que incorporaremos componentes y recursos de la biblioteca de la IU del vehículo a las apps, estas apps, los OEMs deben proporcionar dos superposiciones:
-
La superposición en el tiempo de compilación agrega los recursos necesarios para la la superposición de recursos en tiempo de ejecución (RRO). Esto incluye lo siguiente:
- Elementos de diseño
- Estilos (por ejemplo, apariencias del texto)
- Recursos compartidos (por ejemplo, colores)
-
La carpeta Superposición de RRO contiene los recursos que se usan para generar una RRO por app de destino. Estos recursos solo pueden hacer referencia a lo siguiente:
- Valores definidos dentro de la misma RRO (por ejemplo, para un color, sería una forma hexadecimal valor).
- Recursos del framework de Android (por ejemplo,
@android:color/accent
) - Un recurso definido en la superposición de tiempo de compilación anterior.
Estructura general
La estructura de superposición de personalización propuesta es la siguiente:
-
<path-to-OEM-overlays>/
-
overlay/framework/base/core/res/
Recursos de superposición de tiempo de compilación -
rro/
-
Android.mk
Archivo makefile que se usa para generar las RRO para cada paquete de destino según los recursos que se encuentran en esta carpeta. -
AndroidManifest.xml
Una plantilla de archivo de manifiesto utilizada por el modelo anterior makefile. -
res/
Superposiciones de tiempo de ejecución para aplicar a todas las apps de destino.
-
-
Es posible que los OEMs tengan más de una de estas estructuras, según la cantidad de marcas que deseen en un único destino de compilación (consulta Administra varias marcas).
Superposiciones de recursos en tiempo de ejecución
La carpeta RRO en la carpeta de superposición del OEM debe contener recursos que se aplicarán a todas las apps de destino. Las RRO tienen limitaciones que afectan su capacidad de superponer recursos compuestos. En resumen, una RRO tiene las siguientes características:
-
No se pueden hacer referencia a los identificadores de recursos definidos en el APK de destino o en la RRO. Esto significa que los RRO no pueden agregar identificadores nuevos, como nuevos elementos de diseño, colores o estilos.
-
Pueden hacer referencia a los identificadores de recursos definidos en la en el framework, ya sea que esos recursos se definan en
/frameworks/base/core/res
o por medio de una superposición de tiempo de compilación. Se debe hacer referencia a estos identificadores con elandroid:
espacio de nombre:-
Para los RRO públicos de DeviceDefault, usa
android
.
Por ejemplo,@android:style/TextAppearance.DeviceDefault.Large
. -
Para todos los demás (privados o recursos agregados mediante superposición de tiempo de compilación), usa
*android
.
Por ejemplo,@*android/style:TextAppearance.OEM.Brand1.Title
.
-
Además de los recursos, la carpeta RRO debe contener lo siguiente:
-
AndroidManifest.xml
En la siguiente muestra,RRO_PACKAGE_NAME
yTARGET_PACKAGE_NAME
son marcadores de posición para los archivos 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
, en el queoem
en el siguiente archivo makefile 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
Configura RRO
Se admite un nuevo archivo de configuración, overlayable.xml
, que puedes usar para definir
controles de acceso. Por ejemplo, puedes especificar quiénes pueden superponer recursos y cuáles
pueden superponerse. Como resultado, los recursos ahora se pueden agrupar de diferentes maneras para hacerlos
disponibles para que las superpongan diferentes RRO.
Para configurar el control de acceso RRO, haz lo siguiente:
- En la carpeta
res/values
, creaoverlayable.xml
. - Crea las etiquetas de recursos
<overlayable>
. - Define el atributo
name
para la etiqueta<overlayable>
, que debe ser único en el paquete. Cada superposición puede orientarse a solo un grupo superpuesto. - Define la etiqueta
<policy>
dentro de<overlayable>
. - Define 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>
Sigue estos pasos para aplicar los siguientes cambios a tu proyecto de RRO:
- En la carpeta
res/xml
, creaoverlays.xml
. Consulta la entrada en muestra de código a continuación paraoverlay
. - Define los recursos que se anularán.
- Agrega
android:resourcesMap="@xml/overlays"
a<overlay>
. etiqueta enAndroidManifest.xml
. Por ejemplo, en la siguiente muestra de código, consulta la entrada para<overlay>
- Establece
android:isStatic=”true”
para una superposición estática. Cada superposición solo puede orientarse uno de los grupos que se pueden superponer.
Ten en cuenta 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 salvedad, las RRO existentes anteriores funcionan en Android 10. Advertencia
que se instalarán con PackageManagerRRO, los paquetes deben estar preinstalados o
firmado con la misma clave que la app de destino. En Android 10, se pueden superponer los archivos de diseño. Sin embargo,
Para ello, debes usar requireViewById()
mientras obtienes la vista, en lugar de
findViewById()
En Android 10, este cambio se implementó en car-ui-lib para
admiten superposiciones de diseño.
La próxima versión importante de Android te permitirá superponer un archivo de diseño y definir recursos nuevos en el paquete RRO y hacer referencia a ellos internamente.
Cómo agregar recursos específicos de OEM
Para superar las limitaciones de RRO que impiden que se agreguen recursos de OEM, haz lo siguiente:
- Extender los frameworks o la base usando una superposición de tiempo de compilación y agregar los que sean necesarios de Google Cloud.
- Consulta estos recursos de los RRO de OEM con el espacio de nombres de
*android:
.
Por ejemplo, la siguiente es una manera 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>
-
-
Cómo administrar varias marcas
Los archivos de manifiesto RRO tienen una sintaxis para permitir su aplicación condicional según el sistema propiedades. Para administrar varias marcas en una sola imagen del sistema, los OEM pueden usarla como sigue (consulta 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
provocaría que esta RRO se habilite solo
si la propiedad del sistema correspondiente coincide con el valor proporcionado. Los OEM luego pueden definir múltiples de
estas RRO, todas habilitadas de forma estática, y solo tienen una activa a la vez.
Cómo agregar la biblioteca de la IU del vehículo a un destino
Para incorporar la biblioteca de la IU del vehículo a un objetivo de Android, debes 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 \ ...
-
Hace que
<path-to-OEM-overlays>/rro/Android.mk
genere una RRO para cada una. de los paquetes nombrados enCAR_UI_RRO_PACKAGE_NAMES
. -
Incluye las RRO generadas en
PRODUCT_PACKAGES
. -
Incluye una superposición de tiempo de compilación en
PRODUCT_PACKAGE_OVERLAYS
para agregar elementos específicos de OEM. de Google Cloud.
Para saber qué paquetes admiten car-ui-lib
, consulta la Lista de paquetes que contienen car-ui-lib.