Esta página se ha traducido con Cloud Translation API.

Personalizar aplicaciones

Ahora que los componentes y recursos de la biblioteca Car UI están en las aplicaciones, para poder personalizar estas aplicaciones, los OEM deben proporcionar dos superposiciones:

La superposición en tiempo de compilación agrega los recursos necesarios para la superposición de recursos en tiempo de ejecución (RRO). Esto incluye:
- Dibujables
- Estilos (por ejemplo, apariencias de texto)
- Recursos compartidos (por ejemplo, colores)
La carpeta de superposición de RRO contiene los recursos utilizados para generar un RRO por aplicación de destino. Estos recursos sólo pueden referirse a:
- Valores definidos dentro del mismo RRO (por ejemplo, para un color este 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 de superposición de personalización propuesta es la siguiente:

<path-to-OEM-overlays>/
- overlay/framework/base/core/res/ . Recursos superpuestos en tiempo de construcción
- rro/
  - Android.mk . Makefile se utiliza para generar los 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 en 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 quieran manejar en un único objetivo de compilación (consulte Manejar varias marcas ).

Superposiciones de recursos en 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 identificadores de recursos definidos en el APK de destino ni en el propio RRO. Esto significa que los RRO no pueden agregar nuevos identificadores, como nuevos elementos de diseño, colores o estilos.
Poder haga referencia a los identificadores de recursos definidos en el marco, ya sea que esos recursos estén definidos en /frameworks/base/core/res o mediante una superposición en tiempo de compilación. Estos identificadores deben referirse mediante el espacio de nombres android: ::
- Para RRO públicos DeviceDefault, use android .
  Por ejemplo, @android:style/TextAppearance.DeviceDefault.Large .
- Para todos los demás (recursos no públicos o agregados mediante 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 siguiente ejemplo, RRO_PACKAGE_NAME y TARGET_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 que oem en el siguiente archivo MAKE define el prefijo que tendrían todos los RRO generados.

  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

Configurar RRO

Se admite un nuevo archivo de configuración, overlayable.xml , que puede utilizar para definir controles de acceso. Por ejemplo, puede especificar quién puede superponer recursos y qué recursos se pueden superponer. Como resultado, ahora los recursos 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 , cree overlayable.xml .
Cree las etiquetas de recursos <overlayable> .
Defina el atributo name para la etiqueta <overlayable> , que debe ser único en el paquete. Cada superposición puede apuntar 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 , cree overlays.xml . Consulte la entrada en el ejemplo de código siguiente para ver overlay .
Defina los recursos que se anularán.
Agrega android:resourcesMap="@xml/overlays" a la etiqueta <overlay> en AndroidManifest.xml . Por ejemplo, en el ejemplo de código siguiente, consulte la entrada de <overlay> .
Configure android:isStatic=”true” para una superposición estática. Cada superposición puede apuntar 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, los RRO existentes anteriormente funcionan 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() mientras se obtiene 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 importante de Android le permitirá superponer un archivo de diseño y definir nuevos recursos en el paquete RRO y consultarlos internamente.

Agregar 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 de tiempo de compilación , agregando los recursos necesarios.
Consulte estos recursos de los RRO OEM utilizando *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 un 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>

Manejar múltiples marcas

Los archivos de manifiesto RRO tienen una sintaxis que permite su aplicación condicional según las propiedades del sistema. Para manejar varias marcas en una única imagen del sistema, los OEM pueden usarla de la siguiente manera (consulte 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 habilite solo si la propiedad del sistema correspondiente coincide con el valor proporcionado. Luego, los OEM pueden definir varios de estos RRO, todos ellos habilitados estáticamente y tener solo uno activo a la vez.

Agregar biblioteca Car UI a un objetivo

Para incorporar la biblioteca Car UI a un destino 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 \
      ...

Nota: El prefijo oem- debe coincidir con la variable CAR_UI_RRO_SET_NAME definida en RRO Android.mk . El código anterior:

Causas <path-to-OEM-overlays>/rro/Android.mk genera un RRO para cada uno de los paquetes nombrados en CAR_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 con car-ui-lib , consulte Lista de paquetes que contienen car-ui-lib .