Cómo agregar compatibilidad con el SO Android Automotive a tu app de música

El SO Android Automotive permite a los usuarios instalar apps en un automóvil. Para llegar a los usuarios en esta plataforma, debes distribuir una app optimizada para conductores que sea compatible con el SO Android Automotive. Puedes reutilizar casi todo el código y los recursos de la app de Android Auto, pero debes crear una compilación independiente que cumpla con los requisitos de esta página.

Descripción general del desarrollo

Agregar compatibilidad con el SO Android Automotive es simple y solo requiere unos pocos pasos:

  1. Habilita las funciones automotrices en Android Studio
  2. Crea un módulo automotor
  3. Actualiza tus dependencias de Gradle
  4. Agrega actividades de configuración o acceso (opcional)

Consideraciones del diseño

El SO Android Automotive se encarga de diseñar el contenido multimedia que recibes del servicio de navegador multimedia de tu app. Eso significa que tu app no diseña la IU y no inicia ninguna de las actividades cuando un usuario activa la reproducción de contenido multimedia.

Si estás implementando actividades de configuración o acceso, estas deberán estar optimizadas para vehículos. Cuando diseñes esas áreas de la app, consulta los lineamientos de diseño para el SO Android Automotive.

Configura tu proyecto

Debes configurar varias partes diferentes del proyecto de tu app a fin de habilitar la compatibilidad con el SO Android Automotive.

Habilita las funciones automotrices en Android Studio

Usa Android Studio 4.0 o una versión posterior para asegurarte de que todas las funciones del SO Android Automotive estén habilitadas.

Crea un módulo automotor

Algunos componentes del SO Android Automotive, como el manifiesto, tienen requisitos específicos de la plataforma, por lo que deberás crear un módulo que pueda mantener el código de esos componentes separado de otro código del proyecto, como el que se usa en la aplicación para teléfonos.

Sigue estos pasos para agregar un módulo automotor a tu proyecto:

  1. En Android Studio, selecciona File > New > New Module.
  2. Selecciona Automotive Module y, luego, haz clic en Next.
  3. Proporciona la información de Application/Library name. Se trata del nombre que los usuarios ven para tu app en el SO Android Automotive.
  4. Proporciona un nombre de módulo en Module name.
  5. Ajusta el valor de Package name para que coincida con tu app.
  6. Selecciona API 28:Android 9.0 (Pie) para Minimum SDK y, luego, haz clic en Next.

    Todos los vehículos compatibles con el SO Android Automotive se ejecutan en Android 9 (nivel de API 28) o una versión posterior. Por lo tanto, si seleccionas este valor, se orientará al 100% de los vehículos que usan el SO Android Automotive.

  7. Selecciona Add No Activity y haz clic en Finish.

Después de crear tu módulo en Android Studio, abre AndroidManifest.xml en tu nuevo módulo de Automotive.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.media">

    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:supportsRtl="true"
        android:theme="@style/AppTheme" />

    <uses-feature
        android:name="android.hardware.type.automotive"
        android:required="true" />

</manifest>

Verás información estándar de la app en el elemento application, pero también un elemento uses-feature que declara compatibilidad con el SO Android Automotive. Además, observa que no hay actividades declaradas en el manifiesto.

Si implementas actividades de acceso o configuración, agrégalas aquí. El sistema activará esas actividades con intents explícitos, y esas son las únicas actividades que deberás declarar dentro del manifiesto para tu app con SO Android Automotive.

Después de agregar las actividades de configuración o acceso, completa tu archivo de manifiesto configurando el atributo android:appCategory="audio" en el elemento application y agregando los siguientes elementos users-features:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.media">

    <application
        android:allowBackup="true"
        android:appCategory="audio"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:supportsRtl="true"
        android:theme="@style/AppTheme" />

    <uses-feature
        android:name="android.hardware.type.automotive"
        android:required="true" />

    <uses-feature
        android:name="android.hardware.wifi"
        android:required="false" />
    <uses-feature
        android:name="android.hardware.screen.portrait"
        android:required="false" />
    <uses-feature
        android:name="android.hardware.screen.landscape"
        android:required="false" />

</manifest>

Configurar de forma explícita estas funciones como no obligatorias garantiza que la app no entre en conflicto con las funciones de hardware disponibles en dispositivos con el SO Android Automotive.

Declara la compatibilidad del contenido multimedia con el SO Android Automotive

Usa la siguiente entrada del manifiesto a fin de declarar que tu app es compatible con el SO Android Automotive:

<application>
    ...
    <meta-data android:name="com.android.automotive"
        android:resource="@xml/automotive_app_desc"/>
    ...
</application>

Esta entrada de manifiesto hace referencia a un archivo en formato XML que declara con qué capacidades de Automotive es compatible tu app. Para indicar que tienes una app de música, agrega un archivo en formato XML llamado automotive_app_desc.xml al directorio res/xml/ de tu proyecto. Este archivo debe incluir el siguiente contenido:

<automotiveApp>
    <uses name="media"/>
</automotiveApp>

Filtros de intents

El SO Android Automotive usa intents explícitos para activar actividades en tu app de música. El archivo de manifiesto no debe contener ninguna actividad que tenga filtros de intents CATEGORY_LAUNCHER o ACTION_MAIN.

Las actividades como la que se muestra en el siguiente ejemplo suelen orientarse a un teléfono o a otro dispositivo móvil. Estas actividades deben declararse en el módulo que compila la aplicación para teléfonos, no en el que compila tu app del SO Android Automotive.

<activity android:name=".MyActivity">
    <intent-filter>
        <!-- You can't use either of these intents for Android Automotive OS -->
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
        <!--
        In their place, you can include other intent filters for any activities
        that your app needs for Android Automotive OS, such as settings or
        sign-in activities.
        -->
    </intent-filter>
</activity>

Actualiza tus dependencias de Gradle

Te recomendamos que mantengas el servicio de navegador multimedia en un módulo separado compartido entre la aplicación para teléfonos y el módulo de Automotive. Si usas este enfoque, deberás actualizar el módulo de Automotive a fin de incluir el módulo compartido, como se muestra en el siguiente fragmento:

my-auto-module/build.gradle

Groovy

buildscript {
    ...
    dependencies {
        ...
        implementation project(':shared_module_name')
    }
}

Kotlin

buildscript {
    ...
    dependencies {
        ...
        implementation(project(":shared_module_name"))
    }
}

Implementa actividades de configuración y acceso

Además del servicio de navegación multimedia, también puedes proporcionar actividades de configuración y acceso optimizadas para vehículos en tu app del SO Android Automotive. Estas actividades te permiten proporcionar una funcionalidad de la app que no está incluida en las API de Android Media.

Solo debes implementar estas actividades si tu app del SO Android Automotive necesita permitir el acceso a los usuarios o especificar la configuración de la app. Android Auto no usa estas actividades.

Flujos de trabajo de las actividades

En el siguiente diagrama, se muestra cómo interactúa un usuario con las actividades de configuración y acceso con el SO Android Automotive:

Flujos de trabajo de las actividades de configuración y acceso

Figura 1: Flujos de trabajo de las actividades de configuración y acceso

Agrega una actividad de configuración

Puedes agregar una actividad de configuración optimizada para vehículos de modo que los usuarios puedan ajustar la configuración de la app en su vehículo. Tu actividad de configuración también puede proporcionar otros flujos de trabajo, como acceder a la cuenta de un usuario, salir de ella o cambiar de una cuenta de usuario a otra. Recuerda que una app que ejecuta el SO Android Automotive es lo único que activa esta actividad. Las apps de teléfono conectadas a Android Auto no la usan.

Declara una actividad de configuración

Debes declarar la actividad de configuración en el archivo de manifiesto de la app, como se muestra en el siguiente fragmento de código:

<application>
    ...
    <activity android:name=".AppSettingsActivity"
              android:exported="true"
              android:theme="@style/SettingsActivity"
              android:label="@string/app_settings_activity_title">
        <intent-filter>
            <action android:name="android.intent.action.APPLICATION_PREFERENCES"/>
        </intent-filter>
    </activity>
    ...
</application>

Implementa tu actividad de configuración

Cuando un usuario inicie tu app, el SO Android Automotive detectará la actividad de configuración que declaraste y mostrará una opción, como un ícono. El usuario puede presionar o seleccionar esta opción en la pantalla de su vehículo para navegar a la actividad. El SO Android Automotive envía el intent ACTION_APPLICATION_PREFERENCES, que le indica a la app que inicie la actividad de configuración.

En el resto de esta sección, se revisará cómo adaptar el código desde la app de muestra de Universal Android Music Player (UAMP) a fin de implementar una actividad de configuración en tu app.

Para comenzar, descarga el código de muestra:

# Clone the UAMP repository
git clone https://github.com/android/uamp.git

# Fetch the appropriate pull request to your local repository
git fetch origin pull/323/head:NEW_LOCAL_BRANCH_NAME

# Switch to the new branch
git checkout NEW_LOCAL_BRANCH_NAME

A los efectos de implementar tu actividad, sigue estos pasos:

  1. Copia la carpeta automotive/automotive-lib en tu módulo de Automotive.
  2. Define un árbol de preferencias como en automotive/src/main/res/xml/preferences.xml.
  3. Implementa un PreferenceFragmentCompat (consulta SettingsFragment.kt en UAMP) que mostrará tu actividad de configuración (consulta SettingsActivity.kt). Si deseas obtener más información, revisa la guía de configuración de Android.

A medida que avances en la implementación de tu actividad de configuración, consulta estas prácticas recomendadas para usar algunos de los componentes de la biblioteca de Preference:

  • Tu app no debería tener más de 2 niveles de profundidad debajo de la vista principal en la actividad de configuración.
  • No uses un objeto DropDownPreference. Utiliza una ListPreference en su lugar.
  • Componentes organizacionales:
  • Los siguientes componentes deben tener una key y un title, y pueden tener un summary o un icon:
    • Preference
      • Personaliza la lógica en la devolución de llamada onPreferenceTreeClick() de la implementación de tu PreferenceFragmentCompat.
    • CheckBoxPreference
      • Puede tener summaryOn o summaryOff en lugar de summary para texto condicional.
    • SwitchPreference
      • Puede tener summaryOn o summaryOff en lugar de summary para texto condicional.
      • Puede tener switchTextOn o switchTextOff.
    • SeekBarPreference
      • Debe tener un min, max y defaultValue.
    • EditTextPreference
      • Debe tener dialogTitle, positiveButtonText y negativeButtonText.
      • Puede tener dialogMessage o dialogLayoutResource.
    • com.example.android.uamp.automotive.lib.ListPreference
      • Deriva, principalmente, de ListPreference.
      • Se usa para mostrar una lista de opción única de objetos de Preference.
      • Debe tener un arreglo de entries y entryValues correspondientes.
    • com.example.android.uamp.automotive.lib.MultiSelectListPreference
      • Deriva, principalmente, de MultiSelectListPreference.
      • Se usa para mostrar una lista de opción múltiple de objetos de Preference.
      • Debe tener un arreglo de entries y entryValues correspondientes.

Agrega una actividad de acceso

Si tu app requiere que los usuarios accedan antes de usarla, puedes agregar una actividad de acceso optimizada para vehículos que controle el acceso a tu app y la salida de ella. También puedes agregar flujos de trabajo de acceso y salida a una actividad de configuración, pero deberás usar una actividad de acceso dedicada si la app no se puede usar hasta que el usuario acceda. Recuerda que una app que ejecuta el SO Android Automotive es lo único que activa esta actividad. Las apps de teléfono conectadas a Android Auto no la usan.

Solicita el acceso cuando se inicie la app

Si quieres que un usuario tenga que acceder antes de poder usar tu app, el servicio de navegador multimedia debe realizar las siguientes acciones:

  1. En el método onLoadChildren() de tu servicio, envía un resultado nulo mediante el método sendResult().
  2. Establece el PlaybackState de la sesión multimedia en STATE_ERROR mediante el método setState(). De este modo, se indica al SO Android Automotive que no se podrán llevar a cabo otras operaciones hasta que se resuelva el error.
  3. Establece el código de error de PlaybackState de la sesión multimedia en ERROR_CODE_AUTHENTICATION_EXPIRED. De este modo, se indica al SO Android Automotive que el usuario debe autenticarse.
  4. Establece el mensaje de error de PlaybackState de la sesión multimedia mediante el método setErrorMessage(). Como este mensaje de error se muestra al usuario, el mensaje se deberá localizar según la configuración regional actual del usuario.
  5. Configura los extras de PlaybackState de la sesión multimedia mediante el método setExtras(). Incluye las siguientes dos claves:

En el siguiente fragmento de código, se muestra cómo la app puede requerir el acceso del usuario antes de que este pueda utilizarla:

Kotlin

import androidx.media.utils.MediaConstants

val signInIntent = Intent(this, SignInActivity::class.java)
val signInActivityPendingIntent = PendingIntent.getActivity(this, 0,
    signInIntent, 0)
val extras = Bundle().apply {
    putString(
        MediaConstants.PLAYBACK_STATE_EXTRAS_KEY_ERROR_RESOLUTION_ACTION_LABEL,
        "Sign in"
    )
    putParcelable(
        MediaConstants.PLAYBACK_STATE_EXTRAS_KEY_ERROR_RESOLUTION_ACTION_INTENT,
        signInActivityPendingIntent
    )
}

val playbackState = PlaybackStateCompat.Builder()
        .setState(PlaybackStateCompat.STATE_ERROR, 0, 0f)
        .setErrorMessage(
            PlaybackStateCompat.ERROR_CODE_AUTHENTICATION_EXPIRED,
            "Authentication required"
        )
        .setExtras(extras)
        .build()
mediaSession.setPlaybackState(playbackState)

Java

import androidx.media.utils.MediaConstants;

Intent signInIntent = new Intent(this, SignInActivity.class);
PendingIntent signInActivityPendingIntent = PendingIntent.getActivity(this, 0,
    signInIntent, 0);
Bundle extras = new Bundle();
extras.putString(
    MediaConstants.PLAYBACK_STATE_EXTRAS_KEY_ERROR_RESOLUTION_ACTION_LABEL,
    "Sign in");
extras.putParcelable(
    MediaConstants.PLAYBACK_STATE_EXTRAS_KEY_ERROR_RESOLUTION_ACTION_INTENT,
    signInActivityPendingIntent);

PlaybackStateCompat playbackState = new PlaybackStateCompat.Builder()
    .setState(PlaybackStateCompat.STATE_ERROR, 0, 0f)
    .setErrorMessage(
            PlaybackStateCompat.ERROR_CODE_AUTHENTICATION_EXPIRED,
            "Authentication required"
    )
    .setExtras(extras)
    .build();
mediaSession.setPlaybackState(playbackState);

Una vez que el usuario se haya autenticado correctamente, la app deberá establecer PlaybackState en un estado diferente de STATE_ERROR y, luego, llevar al usuario al SO Android Automotive llamando al método finish() de la actividad.

Implementa tu actividad de acceso

Google ofrece varias herramientas de identidad que puedes utilizar para ayudar a los usuarios a acceder a tu app en sus vehículos. Algunas herramientas, como Firebase Authentication, proporcionan herramientas de pila completa que pueden ayudar a crear experiencias de autenticación personalizadas. Otras herramientas aprovechan las credenciales existentes de los usuarios o de otras tecnologías para ayudarte a crear experiencias de acceso sin problemas para los usuarios.

Te recomendamos las siguientes herramientas como ayuda con el fin de crear una experiencia de acceso más simple para los usuarios que hayan accedido anteriormente desde otro dispositivo:

  • Acceso con Google: Si ya implementaste el Acceso con Google para otros dispositivos (como tu aplicación para teléfonos), deberás implementar esta funcionalidad en tu app del SO Android Automotive a fin de admitir a los usuarios existentes del Acceso con Google.
  • Autocompletar con Google: Si los usuarios habilitaron Autocompletar con Google en sus otros dispositivos Android, se guardarán sus credenciales en el Administrador de contraseñas de Google. Luego, cuando acceden a tu app del SO Android Automotive, la función Autocompletar con Google sugerirá las credenciales guardadas relevantes. El uso de Autocompletar con Google no requiere ningún esfuerzo de desarrollo de aplicaciones; sin embargo, los desarrolladores deberán optimizar sus apps a fin de obtener resultados de mejor calidad. La función Autocompletar con Google es compatible con todos los dispositivos que ejecutan Android Oreo 8.0 (nivel de API 26) o versiones posteriores (incluido el SO Android Automotive).

Usa AccountManager

Las apps del SO Android Automotive que tienen autenticación deberán usar AccountManager por los siguientes motivos:

  • Mejor UX y administración sencilla de cuentas: Los usuarios podrán administrar fácilmente todas sus cuentas desde el menú de cuentas en la configuración del sistema, lo que incluye el acceso y el cierre de sesión.
  • Experiencias de "invitado": Como los automóviles son dispositivos compartidos, los OEM pueden habilitar las experiencias de "invitado" en el vehículo, cuando no se puedan agregar cuentas. Esta restricción se logra usando DISALLOW_MODIFY_ACCOUNT para AccountManager.

Permisos

Si necesitas solicitar permisos del usuario, usa el mismo flujo que la actividad de autenticación o la actividad de configuración en el diagrama de flujos de trabajo de la actividad.

Manejo de errores

Los errores en las apps de música del SO Android Automotive se comunican a través del PlaybackState de la sesión multimedia. Para todos los errores, debes establecer un código y un mensaje de error adecuados en el PlaybackState. Eso hará que aparezca un Toast en la IU.

Cuando ocurre un error, pero la reproducción puede continuar, debes emitir un error recuperable. Por ejemplo, un usuario no necesitará acceder a fin de reproducir música en una app, pero deberá hacerlo para poder omitir una canción. Si se usa un error recuperable, el sistema podrá sugerir que el usuario acceda sin interrumpir la reproducción del elemento multimedia actual. En ese caso, deberás conservar el resto del PlaybackState tal como está (aparte del código de error y su mensaje). De este modo, se permitirá que la reproducción del elemento multimedia actual continúe mientras el usuario decide si accederá o no.

Cuando no se pueda reproducir el contenido (por ejemplo, si no hay conexión a Internet ni contenido sin conexión), deberás establecer el estado PlaybackState en STATE_ERROR.

En las actualizaciones posteriores a tu PlaybackState, deberás borrar el código de error y su mensaje a fin de evitar mostrar varias advertencias para el mismo error.

Si en algún momento no puedes cargar un árbol de navegación (por ejemplo, si necesitas autenticación y el usuario no accedió), deberás enviar un árbol de navegación vacío. Para indicar esto, onLoadChildren() del nodo multimedia raíz deberá mostrar un resultado nulo. Cuando esto suceda, el sistema mostrará un error de pantalla completa con el mensaje de error establecido en el PlaybackState.

Errores de acción

Si un error es de acción, establece los dos extras siguientes en el PlaybackState:

Los errores de acción se mostrarán como un Dialog y los usuarios podrán resolverlos solo cuando el vehículo esté detenido.

Prueba de casos de error

Deberás verificar que la app funcione correctamente en todas las situaciones, incluidas las siguientes:

  • Niveles diferentes de tu producto: Por ejemplo, el acceso gratuito o el premium, o la sesión iniciada o sin iniciar
  • Estados de conducción diferentes: Por ejemplo, estacionado o en movimiento
  • Estados de conectividad diferentes: Por ejemplo, en línea o sin conexión

Otros factores que considerar

Ten en cuenta estas otras consideraciones cuando desarrolles tu app para el SO Android Automotive:

Contenido sin conexión

Si corresponde, implementa la reproducción sin conexión. Se espera que los vehículos con el SO Android Automotive tengan su propia conexión de datos; es decir, un plan de datos incluido en el costo del vehículo o que el usuario paga. Sin embargo, también se espera que los vehículos tengan una conectividad más variable que los dispositivos móviles. Por lo tanto, te recomendamos que pienses en la mejor estrategia de soporte sin conexión para tu contenido. El espacio en disco de los vehículos puede variar, por lo que debes asegurarte de que los usuarios puedan borrar contenido sin conexión, por ejemplo, mediante una opción en tu actividad de configuración.

A continuación, se incluyen algunos aspectos que debes tener en cuenta a la hora de analizar la estrategia de soporte sin conexión:

  • El mejor momento para descargar contenido es cuando tu app está en uso.
  • No des por sentado que la conexión Wi-Fi está disponible. Es posible que un automóvil nunca llegue a estar dentro del rango de conexión Wi-Fi o que el OEM haya inhabilitado esa conexión a fin de priorizar una red móvil.
  • Aunque está bien almacenar en caché de forma inteligente el contenido que crees que los usuarios podrían utilizar, te recomendamos que permitas al usuario cambiar este comportamiento mediante tu actividad de configuración.

Compatibilidad comercial

Por el momento, el SO Android Automotive no admite ninguna funcionalidad comercial. Eso significa que no puedes tener una aplicación pagada ni ninguna compra directa desde tu aplicación. Los usuarios podrán comprar CDA fuera de la app del SO Android Automotive, pero, una vez que estén dentro del vehículo, no se les debe requerir que realicen ninguna operación financiera adicional para poder usar funciones o contenido nuevos y pagos.

Compatibilidad con WebView

Las WebViews son compatibles con el SO Android Automotive, pero solo se permiten para las actividades de configuración y acceso. Las actividades que usan WebView deberán tener una opción cercana o inversa fuera de la WebView.

A continuación, te mostramos algunos ejemplos de casos de uso aceptables para WebViews:

  • Mostrar tu Política de Privacidad, las Condiciones del Servicio u otros vínculos relacionados con cuestiones legales en tu actividad de configuración
  • Contar con un flujo de acceso basado en la Web en tu actividad de acceso

Cuando usas una WebView, puedes habilitar JavaScript.

Protege tu WebView

Toma todas las precauciones posibles para asegurarte de que tu WebView no funcione como punto de entrada a Internet. Consulta el fragmento de código que aparece a continuación a fin de ver un ejemplo de cómo bloquear la WebView en la URL usada en la llamada a loadUrl() y evitar los redireccionamientos. Te recomendamos que implementes protecciones como esta cuando tiene sentido para el caso de uso (por ejemplo, cuando se muestran vínculos relacionados con cuestiones legales).

Kotlin

override fun shouldOverrideUrlLoading(webView: WebView,
                             webResourceRequest: WebResourceRequest): Boolean {
  val originalUri: Uri = Uri.parse(webView.originalUrl)
  // Check for allowed URLs
  if (originalUri.equals(Uri.parse(BLANK_URL))
      || originalUri.equals(webResourceRequest.url)) {
    return false
  }
  if (webResourceRequest.isRedirect) {
    logger.w("Redirect detected, not following")
    return true
  }
  setupWizardWebViewClientListener.onUriBlocked(webResourceRequest.url)
  logger.w(
    String.format(
      "Navigation prevented to %s original is %s", webResourceRequest.url, originalUri))
  return true
}

Java

@Override
public boolean shouldOverrideUrlLoading(WebView webView, WebResourceRequest webResourceRequest) {
  Uri originalUri = Uri.parse(webView.getOriginalUrl());
  // Check for allowed URLs
  if (originalUri.equals(Uri.parse(BLANK_URL))
      || originalUri.equals(webResourceRequest.getUrl())) {
    return false;
  }
  if (webResourceRequest.isRedirect()) {
    logger.w("Redirect detected, not following");
    return true;
  }
  setupWizardWebViewClientListener.onUriBlocked(webResourceRequest.getUrl());
  logger.w(
      String.format(
          "Navigation prevented to %s original is %s", webResourceRequest.getUrl(), originalUri));
  return true;
}

Nombres de los paquetes

Debido a que distribuyes un APK independiente para el SO Android Automotive, tendrás la opción de volver a usar el nombre del paquete de tu app para dispositivos móviles o crear un nombre de paquete nuevo. La diferencia principal es que con un nombre de paquete diferente, la app tendrá dos fichas de Play Store completamente independientes, mientras que, si vuelves a usar el nombre de tu paquete actual, tendrás una sola ficha en ambas plataformas.

Esto es, en esencia, una decisión comercial. Por ejemplo, si tienes un equipo que trabaja en la app para dispositivos móviles y otro equipo completamente separado que trabaja en tu app del SO Android Automotive, podría tener sentido tener nombres de paquetes independientes y permitir que cada uno administre su propia ficha de Play Store. No hay una gran diferencia en términos del esfuerzo técnico necesario para usar cualquiera de los enfoques.

En la siguiente tabla, se resumen algunas de las otras diferencias clave entre cada enfoque:

Función Mismo nombre de paquete Nuevo nombre de paquete
Ficha de Play Store Una Varias
Instalación duplicada Sí. "Reinstalación rápida de app" durante el asistente de configuración No
Proceso de revisión de Play Store Bloqueo de revisiones. Actualmente, si la revisión falla en un APK, se bloquearán otros APK enviados de la misma versión Revisiones individuales
Estadísticas, métricas e indicadores esenciales Combinado. Nota: Puedes filtrar por nombre de dispositivo para datos específicos de vehículos (por ejemplo, 2 vehículos en el año 2020) Separar
Indexación y clasificación en la búsqueda El punto de partida es la clasificación actual No se transfiere
Integración con otras apps Lo más probable es que no se necesiten cambios, suponiendo que el código multimedia se comparte entre ambos APK Es posible que debas actualizar la app correspondiente (por ejemplo, para la reproducción de URI con Asistente de Google)

Preguntas frecuentes

Consulta las secciones siguientes a fin de obtener respuestas a algunas preguntas frecuentes sobre el SO Android Automotive.

Hardware

¿Mi app puede acceder al micrófono?

En las apps orientadas a Android 10 (nivel de API 29) o versiones posteriores, consulta la documentación sobre el uso compartido de entradas de audio. Esto no es posible en niveles de API inferiores a 29.

¿A qué API de vehículos podemos acceder y cómo?

Solo podrás acceder a las API que exponga el OEM. Estamos trabajando para estandarizar la forma en que accedes a estas API.

Las apps pueden acceder a las API de vehículos mediante SetProperty() y GetProperty() en CarPropertyManager. Consulta el código fuente o la documentación de referencia para ver una lista de todas las propiedades disponibles. Si la propiedad está anotada con @SystemApi, estará limitada a las apps del Sistema (precargadas).

¿Qué tipos de códecs de audio son compatibles?

Consulta la información detallada de códecs de audio en el CDD de Android.

¿Widevine DRM es compatible?

Sí. Widevine DRM es compatible.

Desarrollo y pruebas

¿Hay restricciones o recomendaciones para usar SDK y bibliotecas de terceros?

No tenemos lineamientos específicos sobre el uso de SDK y bibliotecas de terceros. Si eliges usar bibliotecas y SDK de terceros, serás responsable de cumplir todos los requisitos de calidad de la app para vehículos.

¿Puedo usar un servicio en primer plano?

El único caso de uso permitido para un servicio en primer plano es descargar contenido para su uso sin conexión. Si tienes otro caso de uso de un servicio en primer plano para el que quieras obtener asistencia, comunícate con nosotros a través del grupo de discusión del SO Android Automotive.

Publicación de apps para el SO Android Automotive

¿Cómo publico mi app para el SO Android Automotive con Google Play Console?

El proceso de publicación de apps es similar al de tu aplicación para teléfonos, pero usas un tipo de versión diferente. Para habilitar tu app a fin de usar el tipo de versión del SO Android Automotive, sigue estos pasos:

  1. Abre Play Console.
  2. Selecciona tu app.
  3. En el menú de la izquierda, selecciona Versión > Configuración > Configuración avanzada > Tipos de versión.
  4. Selecciona Agregar tipo de versión > SO Android Automotive y, luego, sigue las instrucciones de Play Console.

Recursos adicionales

Si quieres obtener más información sobre el SO Android Automotive, consulta los siguientes recursos adicionales.

Ejemplos

Guías

Blogs

Videos

Informa un problema en las apps de música para SO Android Automotive

Si tienes un problema mientras desarrollas tu app de música para SO Android Automotive, puedes informarlo con la herramienta de seguimiento de errores de Google. Asegúrate de llenar toda la información solicitada en la plantilla de problemas.

Crear un error nuevo

Antes de informar un problema nuevo, verifica si ya se informó en la lista de problemas. Para suscribirte a un problema o votarlo, haz clic en el ícono de estrella que aparece en la herramienta de seguimiento. Si deseas obtener más información, consulta Cómo suscribirte a un problema.