Tokens de diseño de OEM

Los tokens de diseño de OEM son una implementación del sistema Material Design del SO Android Automotive (AAOS). A diferencia del enfoque de selección algorítmica o del usuario para los valores de token en dispositivos móviles, los OEM designan valores de token de diseño. Los tokens de diseño representan las pequeñas decisiones de diseño repetidas que componen el estilo visual de un sistema de diseño y reemplazan los valores estáticos con nombres que se explican por sí solos. Los tokens son similares a los que define el sistema de Material Design.

Biblioteca de tokens del OEM

Se hace referencia a los tokens de diseño del OEM a través de la biblioteca de tokens del OEM, que consta de los tres componentes que se ilustran en la Figura 1.

Figura 1: Componentes de la biblioteca de tokens del OEM

Biblioteca estática

El componente de biblioteca estática de la biblioteca de tokens del OEM facilita el acceso a los valores de tokens de la siguiente manera:

  • Proporciona APIs para acceder a los valores de OEM para tokens.
  • Habilita la anulación con solicitud de aceptación de referencias de tokens en el tema con valores de OEM.

Biblioteca compartida

El componente de biblioteca compartida es responsable de definir lo siguiente:

  • Es el nombre de la biblioteca.
  • Habilitación booleana para los valores de token de OEM.
  • Es el estilo que proporciona valores de token de OEM.

Para admitir la propiedad del OEM de este componente de biblioteca compartida, incluido un nombre de paquete definido por el OEM, los OEMs pueden crear una anulación de la implementación de la biblioteca compartida.

Figura 2: Anula una implementación de biblioteca compartida.

Biblioteca compartida del OEM

Las anulaciones del OEM del componente de la biblioteca compartida permiten que el OEM sea propietario de la biblioteca y, al mismo tiempo, mantiene la compatibilidad con otros componentes de la biblioteca de tokens del OEM, ya que proporciona un medio para que los OEM establezcan el nombre y la firma del paquete, sin modificar la implementación de la biblioteca compartida.

Las anulaciones de una biblioteca compartida se pueden definir como se muestra a continuación:

override_android_app {
    name: "[OEM]-token-shared-lib",
    base: "token-shared-lib",
    package_name: "com.[OEM].sharedlib",
    rename_resources_package: false,
    certificate: 
}

Para establecer valores de token, consulta Especifica valores de token de OEM.

Personalizaciones de bibliotecas compartidas del OEM

Para admitir diversos esquemas de valores de tokens (por ejemplo, diferenciación de modelos o modos de conducción), los OEMs pueden proporcionar valores dinámicos para los tokens segmentando la biblioteca compartida del OEM con superposiciones de recursos de tiempo de ejecución (RRO). Para obtener más información, consulta Cómo cambiar el valor de los recursos de una app en el tiempo de ejecución.

Para establecer valores de token, consulta Especifica valores de token de OEM.

Especifica los valores de token del OEM

Para especificar valores de token, establece el atributo correspondiente en el estilo OemStyle en el valor requerido.

<resources>
    <style name="OemStyle">
        <item name="colorPrimary">#B0C5FF</item>
        <item name="colorOnPrimary">#002B76</item>
        <item name="colorPrimaryContainer">#003FA4</item>
        <item name="colorOnPrimaryContainer">#D9E2FF</item>
        …
    </style>
</resources>

Acepta los valores del OEM

Para que las apps puedan acceder a los valores de token proporcionados por el OEM, los OEMs primero deben habilitar la anulación de los valores de token predeterminados configurando el valor booleano enable_oem_tokens como true.

Valores de los tokens de RRO

Del mismo modo que se establecen los valores de token en OemStyle, se pueden usar los RRO para modificar el estilo y proporcionar valores de token alternativos.

<resources>
    <style name="OemStyle">
        <item name="com.android.oem.tokens:colorPrimary">#B0C5FF</item>
        <item name="com.android.oem.tokens:colorOnPrimary">#002B76</item>
        <item name="com.android.oem.tokens:colorPrimaryContainer">#003FA4</item>
        <item name="com.android.oem.tokens:colorOnPrimaryContainer">#D9E2FF</item>
        …
    </style>
</resources>

Los RRO deben establecer los atributos de la biblioteca compartida en el estilo especificando el nombre de la biblioteca.

Configura la carga por último

Los sistemas que incluyen una implementación de OEM de una biblioteca compartida de tokens deben configurar el sistema para que cargue la biblioteca compartida después de las clases de la app. Para ello, incluye el nombre de la biblioteca (com.android.oem.tokens) en la configuración de config_sharedLibrariesLoadedAfterApp en el sistema. Si tienes acceso a los Servicios de Google Automotive (GAS), esto se aplica como un requisito.

<!-- The OEM token shared library will be loaded after app classes -->
<string-array name="config_sharedLibrariesLoadedAfterApp" translatable="false">
    <item>com.android.oem.tokens</item>
</string-array>

Prácticas recomendadas

A continuación, se describen las prácticas recomendadas para la biblioteca de tokens del OEM.

Habilita una estrategia de actualización flexible

Consulta las estrategias que se indican a continuación para asegurarte de incorporar flexibilidad con respecto a las actualizaciones.

Biblioteca compartida del OEM

Como las bibliotecas compartidas del sistema deben estar preinstaladas en las imágenes del sistema, los dispositivos deben enviarse con la biblioteca o esta debe agregarse como parte de una actualización inalámbrica (OTA) (para obtener más información, consulta Actualizaciones inalámbricas). Sin embargo, incluir una implementación de stub de una anulación de OEM de una biblioteca compartida de token de OEM en una imagen del sistema permite que se envíe una actualización a una implementación funcional completa a los dispositivos en una fecha posterior sin necesidad de una actualización inalámbrica.

RRO de bibliotecas compartidas

Aunque no es obligatorio que los RRO se instalen como apps del sistema, hacerlo proporciona un comportamiento de actualización que podría ser deseado.

  • Actualizaciones automáticas de apps cuando los usuarios no accedieron a sus cuentas
  • El usuario no puede desinstalarla (solo puede desinstalar las actualizaciones).