Foco de audio

Antes de iniciar una transmisión lógica, una app solicita el foco de audio con los mismos atributos de audio que se usan para la transmisión lógica. La app debe respetar las pérdidas de enfoque para funcionar como se espera en los casos de uso de la industria automotriz.

Si bien se recomienda enviar una solicitud de enfoque, el sistema no la aplica de forma forzosa. Por lo tanto, considera el enfoque como un medio para controlar indirectamente y evitar conflictos durante la reproducción, en lugar de como un mecanismo de control de audio principal. El vehículo no debe depender del sistema de enfoque para el funcionamiento del subsistema de audio.

Interacciones de enfoque

Para admitir AAOS, las solicitudes de enfoque de audio se controlan en función de interacciones predefinidas entre el CarAudioContext de la solicitud y el de los titulares de enfoque actuales. Existen tres tipos de interacciones:

  • Exclusivo
  • Rechazar
  • Concurrent

Interacción exclusiva

Este es el modelo de interacción más usado con Android.

En las interacciones exclusivas, solo una app puede mantener el foco a la vez. Por lo tanto, se otorga el foco a una solicitud de foco entrante mientras el titular de foco existente pierde el foco. Como ambas apps reproducen contenido multimedia, solo una puede mantener el foco. Como resultado, la solicitud de enfoque de la app recién iniciada se muestra con AUDIOFOCUS_REQUEST_GRANTED, mientras que la app de música que se está reproduciendo recibe un evento de cambio de enfoque con un estado de pérdida que corresponde al tipo de solicitud que se realizó.

Cómo rechazar una interacción

Con las interacciones de rechazo, la solicitud entrante siempre se rechaza. Por ejemplo, cuando intentas reproducir música mientras se está realizando una llamada. En este caso, si el selector de llamadas mantiene el foco de audio para una llamada y una segunda app solicita el foco para reproducir música, la app de música recibe AUDIOFOCUS_REQUEST_FAILED en respuesta a la solicitud. Dado que se rechaza la solicitud de enfoque, no se envía ninguna pérdida de enfoque al titular de enfoque actual.

Interacción simultánea

Las interacciones simultáneas son exclusivas de los AAOS. Esto permite que las apps que solicitan el foco de audio en el vehículo puedan mantener el foco de forma simultánea con otras apps. Para que se lleve a cabo una interacción simultánea, se deben cumplir las siguientes condiciones. El:

Si se cumplen estos criterios, la solicitud de enfoque se muestra con AUDIOFOCUS_REQUEST_GRANTED, mientras que el contenedor de enfoque actual no tiene cambios en el enfoque. Sin embargo, si el titular de enfoque actual opta por recibir eventos de ocultación o por detenerse cuando se oculta, pierde el enfoque, como ocurre con una interacción exclusiva.

Controla las transmisiones simultáneas

Si bien la interacción simultánea tiene varios usos, ten cuidado con la combinación y la atenuación a nivel del hardware en todos los dispositivos de salida. Te recomendamos que las instancias de CarAudioContext que se pueden reproducir de forma simultánea se enruten a diferentes dispositivos de salida.

Tener dispositivos de salida independientes para transmisiones simultáneas permite que el HAL atenúe una de las transmisiones antes de mezclarlas o enrutar las transmisiones físicas a diferentes bocinas del vehículo. Si los flujos lógicos se mezclan en Android, las ganancias no se alteran y se entregan como parte del mismo flujo físico.

Por ejemplo, cuando la navegación y el contenido multimedia se entregan de forma simultánea, la ganancia del flujo de contenido multimedia se puede reducir temporalmente (o atenuar) para que se puedan escuchar con mayor claridad las instrucciones de navegación. Como alternativa, la transmisión de navegación se puede enrutar a las bocinas del lado del conductor mientras el contenido multimedia continúa reproduciéndose en el resto de la cabina.

Matriz de interacción

En esta tabla, se muestra la matriz de interacción como la define CarAudioService. Cada fila representa el CarAudioContext del titular de enfoque actual y cada columna representa el de la solicitud entrante.

Por ejemplo, cuando una app de música mantiene el foco mientras una app de navegación lo solicita, la matriz indica que las dos interacciones pueden reproducirse de forma simultánea, siempre que se cumplan los otros criterios para las interacciones simultáneas.

Debido a las interacciones simultáneas, es posible tener más de un elemento de enfoque. En este caso, una solicitud de enfoque entrante se compara con cada uno de los titulares de enfoque actuales antes de determinar qué interacción aplicar. En este caso, gana la interacción más conservadora. Rechazo, luego exclusivo y, por último, simultáneo.

Matriz de interacción de foco de audio

Figura 1: Matriz de interacción de foco de audio.

En Android 11, se introdujo un nuevo parámetro de configuración del usuario para permitir que los usuarios alteren el comportamiento de interacción entre la navegación y las llamadas telefónicas. Cuando se establece, android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL cambia la interacción entre las solicitudes de enfoque NAVIGATION entrantes y los elementos de enfoque CALL actuales de simultánea a rechazo. Si un usuario prefiere que las instrucciones de navegación no interrumpan una llamada, puede habilitar el parámetro de configuración. Este valor se conserva para el usuario y se puede establecer de forma dinámica para que las solicitudes de enfoque posteriores respeten el nuevo parámetro de configuración.

Foco de audio demorable

En Android 11, AAOS agregó compatibilidad para solicitar enfoque de audio aplazable. Esto permite que se retrasen las solicitudes de enfoque no transitorias cuando su interacción con los titulares de enfoque actuales normalmente haría que se rechacen. Una vez que un cambio en el enfoque genera un estado en el que la solicitud diferida puede obtener el enfoque, se otorga la solicitud.

Reglas para solicitudes de enfoque de audio retrasadas

  • Solo solicitudes no transitorias. Solo se puede realizar una solicitud diferida para fuentes no transitorias para evitar que se reproduzca un sonido transitorio mucho después de que sea relevante.

  • Solo se puede retrasar una solicitud a la vez. Si se realiza una solicitud diferida mientras ya hay una solicitud diferida, la solicitud diferida original recibe un evento de cambio AUDIOFOCUS_LOSS y la solicitud nueva recibe una respuesta síncrona de AUDIOFOCUS_REQUEST_DELAYED.

  • Las solicitudes demorables deben tener OnAudioFocusChangeListener. Después de que se retrasa una solicitud, el objeto de escucha se usa para notificar al solicitante cuando se otorga (AUDIOFOCUS_GAIN) o se rechaza más adelante (AUDIOFOCUS_LOSS).

Cómo solicitar enfoque diferido

Para compilar una solicitud que se puede retrasar, haz lo siguiente:

  1. Utiliza AudioFocusRequest.Builder#setAcceptsDelayedFocusGain.

    mMediaWithDelayedFocusListener = new MediaWithDelayedFocusListener();

mDelayedFocusRequest = new AudioFocusRequest
     .Builder(AudioManager.AUDIOFOCUS_GAIN)
     .setAudioAttributes(mMusicAudioAttrib)
     .setOnAudioFocusChangeListener(mMediaWithDelayedFocusListener)
     .setForceDucking(false)
     .setWillPauseWhenDucked(false)
     .setAcceptsDelayedFocusGain(true)
     .build();

  2. Cuando realices la solicitud, controla la respuesta AUDIOFOCUS_REQUEST_DELAYED:

    int delayedFocusRequestResults = mAudioManager.requestAudioFocus(mDelayedFocusRequest);
if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_GRANTED) {
    // start audio playback
    return;
}
if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_DELAYED) {
     // audio playback delayed to audio focus listener
     return;
}

  3. Cuando se retrasa la solicitud, el objeto de escucha de enfoque controla los cambios de enfoque:

    private final class MediaWithDelayedFocusListener implements
OnAudioFocusChangeListener {
       @Override
       public void onAudioFocusChange(int focusChange) {
           synchronized (mLock) {
               switch (focusChange) {
                   case AudioManager.AUDIOFOCUS_GAIN:
                       … // Start focus playback
                   case AudioManager.AUDIOFOCUS_LOSS_TRANSIENT:
                       … // Pause media transiently
                   case AudioManager.AUDIOFOCUS_LOSS:
                       … // Stop media

Atenuación forzada del sistema

Android 15 presenta la atenuación de audio impuesta por el sistema en AAOS. En Android, el sistema no aplica el foco de audio. Por lo tanto, si bien se recomienda a los desarrolladores de apps que cumplan con los lineamientos de enfoque de audio, si una app continúa reproduciéndose a un volumen alto incluso después de perder el enfoque de audio, el sistema no puede evitarlo.

En entornos automotrices de seguridad crítica, el cumplimiento del enfoque de audio es fundamental para minimizar la distracción del conductor. Con esta función, el framework de audio ahora atenúa automáticamente las apps que pierden el foco de audio para brindar una experiencia de audio más controlada y predecible.

Esta mejora ayuda a garantizar que las apps cumplan con la decisión de pérdida de enfoque de audio como se define en la matriz de interacción, lo que evita conflictos de reproducción de audio.

Diseño de alto nivel

En la siguiente figura, se muestra el diseño de alto nivel y la compatibilidad con la función de pérdida de enfoque en los automóviles:

Diseño de alto nivel para la función de atenuación impuesta por el sistema

Figura 2: Diseño de alto nivel para la función de atenuación impuesta por el sistema.

  • Fondo difuminado segmentado: La aplicación forzosa del sistema de fundido en Android 15 está diseñada específicamente para situaciones en las que una app pierde el enfoque de audio, pero sigue reproduciendo audio.
  • Mecanismo de fundido de salida: Cuando una app pierde el foco de audio a favor de una app solicitante nueva, sucede lo siguiente:
    • El framework de audio atenúa automáticamente el audio de la app que pierde el foco.
    • Después de la atenuación, el sistema silencia la transmisión de audio.
    • Luego, la app recibe una notificación de pérdida de foco de audio.
    • Las apps que se comportan de forma incorrecta se silencian hasta que recuperan el foco de audio.
    • La lógica predeterminada es atenuar las apps que se atenúan después de 2 segundos. Sin embargo, los OEMs pueden configurarlo en cualquier valor de tiempo de espera.
    • El framework de audio usa la configuración del OEM para las operaciones de atenuación y atenuación.

  • Archivo de configuración del OEM: Android 15 incluye un nuevo archivo de configuración, car_audio_fade_configuration.xml:

    • Este archivo permite que los OEM definan criterios para cuándo se aplica la aplicación forzosa de enfoque de audio del sistema a una app que pierde el foco.
    • El framework de audio aplica la atenuación y el silenciamiento solo si la app que pierde coincide con las reglas definidas por el OEM en este archivo en formato XML.
    • Esto proporciona un mecanismo para que los OEM personalicen el comportamiento de la función en función de las características de la app o los tipos de uso de audio.

  • Control de funciones con RRO: Se introdujo una nueva marca de función de superposición de recursos de tiempo de ejecución (RRO), audioUseFadeManagerConfiguration, para habilitar o inhabilitar esta función:

    • La función está inhabilitada de forma predeterminada.
    • Para activar la pérdida de enfoque de audio impuesta por el sistema, los OEMs deben establecer esta marca en true.
    • Aunque el framework de audio para automóviles espera definiciones de configuración de atenuación válidas cuando la marca está habilitada, la ausencia de esas definiciones no genera automáticamente una excepción fatal.
    • Todas las apps de configuraciones de atenuación deben tener definiciones de atenuación coincidentes. Es un error fatal llamar a una configuración de atenuación (por su nombre) como parte de la configuración de audio para automóviles sin proporcionar una definición válida.
    • Cuando se inhabilita la marca, se ignoran todas las definiciones de configuración de atenuación y las referencias de configuración.

Configuración del administrador de atenuación

El framework de audio de Android 15 presenta un FadeManagerConfiguration unificado para proporcionar a los OEMs un control detallado sobre el comportamiento de atenuación del audio. Este framework se ilustra en la Figura 3:

Configuración del administrador de atenuación

Figura 3: Configuración del administrador de atenuación.

Esta configuración incluye lo siguiente:

  • Propiedades de transición de atenuación: Establece la configuración para la atenuación y la aparición.
    • Se puede definir con atributos o usos de audio específicos.
    • Permite establecer una duración personalizada.
    • Estos parámetros de configuración se usan para construir VolumeShaper.Configuration.
  • Políticas de atenuación: Son reglas que regulan cuándo se produce la atenuación.
    • Es un botón de activación global para habilitar o inhabilitar el desvanecimiento.
    • Es una lista configurable de usos de audio que se pueden atenuar (apto para atenuarse cuando se pierde el enfoque).
    • Las listas de exclusiones (no atenuables) evitan que se atenúen las fuentes de audio críticas o designadas. Estas listas pueden basarse en lo siguiente:
      • Tipos de contenido
      • Atributos de audio
      • UIDs de la app (solo se pueden configurar durante el tiempo de ejecución)

Configuraciones de OEM

En esta sección, veremos las personalizaciones de OEM disponibles.

Archivo en formato XML de configuración de atenuación del audio del automóvil

Android 15 presenta un nuevo archivo de configuración, car_audio_fade_configuration.xml, que permite una personalización extensa del OEM del comportamiento de atenuación de audio durante la pérdida de enfoque.

  • Este archivo en formato XML permite definir varias configuraciones de atenuación distintas, cada una de las cuales requiere un nombre único para las referencias cruzadas dentro de car_audio_configuration.xml.
  • Estas configuraciones se pueden aplicar de forma flexible en diferentes zonas de audio y configuraciones de zona.
  • En particular, cada configuración de atenuación solo acepta valores de duración en milisegundos, que el sistema luego usa para generar internamente el VolumeShaper.Configuration correspondiente.

Para obtener orientación práctica sobre la implementación, consulta las configuraciones de ejemplo proporcionadas para el emulador que se encuentra en device/generic/car/emulator/audio/car_audio_fade_configuration.xml.

Archivo en formato XML de configuración de audio para vehículos

En Android 15, se presenta un archivo car_audio_configuration.xml actualizado, ahora en la versión 4, que incorpora nuevas etiquetas applyFadeConfigs y fadeConfig. La etiqueta applyFadeConfigs puede contener varias definiciones de fadeConfig, lo que permite una configuración de atenuación flexible. Cada definición debe cumplir con los siguientes requisitos:

  • Debe incluir un fadeConfig predeterminado designado con isDefault = true.
  • Puede incluir varias definiciones fadeConfig transitorias. Estas configuraciones transitorias se aplican específicamente durante las interacciones de pérdida de foco de audio y solo cuando la app que obtiene el foco de audio coincide con los criterios definidos en la configuración transitoria.

Para obtener orientación práctica sobre la implementación, consulta las configuraciones de ejemplo proporcionadas para el emulador que se encuentra en device/generic/car/emulator/audio/car_audio_configuration.xml.

Extensión de servicio de foco de audio del OEM

Los OEMs que implementan un servicio de enfoque de audio para automóviles personalizado tienen la flexibilidad de configurar la atenuación de audio incluyéndola en OemCarAudioFocusResult. Esto se puede lograr con el método del compilador setAudioAttributesToCarAudioFadeConfigurationMap():

/** @see OemCarAudioFocusResult#getAudioAttributesToCarAudioFadeConfigurationMap() **/
@NonNull
public Builder setAudioAttributesToCarAudioFadeConfigurationMap(@NonNull
        Map<AudioAttributes, CarAudioFadeConfiguration> attrsToCarAudioFadeConfig) {
}

En particular, los OEMs pueden optar por usar la configuración preconfigurada de atenuación durante el inicio o aplicar configuraciones de forma dinámica a través de su servicio de enfoque de audio personalizado, lo que ofrece un control adaptable.

Diagrama de secuencias

En este diagrama de secuencias, se ilustra el comportamiento después de otorgar el foco de audio a App2 y la pérdida posterior del foco de audio por parte de App1:

  • Cuando el servicio de audio para vehículos envía la pérdida de enfoque de audio a App1, la reproducción del reproductor App1 se desvanece según lo definido por los FadeManagerConfiguration activos. Una vez que se completa la operación de atenuación, App1 recibe la devolución de llamada estándar de pérdida de enfoque de audio.
  • De manera opcional, el audio de App1 se puede atenuar después de una duración configurable. Los OEMs tienen la flexibilidad de establecer esta duración a través de Builder#setFadeInDurationForUsage(int, long) según sus requisitos específicos del producto.

Diagrama de secuencia para la función de atenuación de audio del automóvil

Figura 4: Diagrama de secuencias para la función de atenuación de audio del automóvil.

Administración de enfoque de varias zonas

En el caso de los vehículos con varias zonas de audio, el enfoque de audio se administra de forma independiente para cada zona. Por lo tanto, una solicitud a una zona no tiene en cuenta lo que mantiene el enfoque en otras zonas ni hace que los elementos que mantienen el enfoque en otras zonas pierdan el enfoque. Con esto, el enfoque de la cabina principal se puede administrar por separado de un sistema de entretenimiento para asientos traseros, por lo que no se interrumpe la reproducción de audio en una zona debido a los cambios realizados en el enfoque de otra.

Para todas las apps, CarAudioService administra automáticamente el enfoque. La zona de audio de una solicitud de enfoque se determina según su UserId o UID asociado (para obtener más información, consulta Enrutamiento de audio de varias zonas).

Cómo solicitar audio de varias zonas de forma simultánea

Si una app quiere reproducir audio en varias zonas de forma simultánea, debe solicitar el enfoque para cada zona. Para ello, incluye AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID en el paquete:

//Create attribute with bundle and AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID
Bundle bundle = new Bundle();
bundle.putInt(CarAudioManager.AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID,
               zoneId);

AudioAttributes attributesWithZone = new AudioAttributes.Builder()
     .setUsage(AudioAttributes.USAGE_MEDIA)
     .addBundle(bundle)
     .build();

//Create focus request using built attributesWithZone

Este parámetro del paquete permite que el solicitante anule las asignaciones automáticas de zonas de audio para usar el ID de zona especificado. Por lo tanto, una app podría emitir solicitudes separadas para diferentes zonas de audio.

Foco de audio de HAL

A partir de Android 11, el HAL está habilitado para solicitar el enfoque en nombre de las transmisiones externas. Si bien es opcional, se recomienda usar estas APIs para permitir que los sonidos externos sean participantes óptimos en el ecosistema de Android y proporcionar una experiencia del usuario fluida.

El HAL toma la decisión final sobre qué sonidos deben tener prioridad. En este sentido, los sonidos de emergencia y seguridad críticos deben reproducirse independientemente de si se le otorga o no enfoque de audio al HAL y deben seguir reproduciéndose según corresponda, incluso si el HAL pierde el enfoque de audio. Lo mismo sucede con cualquier sonido que exijan las reglamentaciones gubernamentales.

El HAL debe silenciar de forma proactiva las transmisiones de Android según corresponda cuando se reproduzcan sonidos de emergencia o de seguridad críticos para garantizar que se escuchen con claridad.

AudioControl@2.0

La versión 2.0 de la HAL de AudioControl presenta estas nuevas APIs:

API Propósito
IAudioControl#registerFocusListener Registra una instancia de IFocusListener con el HAL de AudioControl. Este objeto de escucha permite que el HAL solicite y abandone el foco de audio. El HAL proporciona una instancia de ICloseHandle que Android usará para cancelar el registro del objeto de escucha.
IAudioControl#onAudioFocusChange Notifica al HAL los cambios de estado para enfocar las solicitudes que realiza el HAL a través de IFocusListener, incluidas las respuestas a las solicitudes de enfoque iniciales.
IFocusListener#requestAudioFocus Las solicitudes se enfocan en nombre del HAL para un uso, un ID de zona y un tipo de ganancia de enfoque especificados.
IFocusListener#abandonAudioFocus Abandona las solicitudes de enfoque de HAL existentes para el uso y el ID de zona especificados.

El HAL puede tener varias solicitudes de enfoque al mismo tiempo, pero se limita a una solicitud por vinculación de ID de uso y zona. Android supone que el HAL comienza a reproducir sonidos de inmediato para un uso una vez que se realiza una solicitud y continúa haciéndolo hasta que abandona el enfoque.

Además de registerFocusListener, estas solicitudes son oneway para garantizar que Android no retrase el HAL mientras se procesa una solicitud de enfoque. El sistema HAL no debe esperar para enfocarse antes de reproducir sonidos esenciales para la seguridad. Es opcional que el sistema HAL escuche y responda a los cambios en el foco de audio a través de IAudioControl#onAudioFocusChange.

Servicio de enfoque de audio para automóviles del OEM

En Android 14, AAOS presentó los servicios de complementos de OEM de automóviles para habilitar la configurabilidad de algunos componentes de automóviles. En el caso del servicio de complementos de audio para automóviles, el servicio de complementos permite que los OEM administren las solicitudes de enfoque que intercepta el servicio de audio para automóviles. Esto les brinda a los OEMs más flexibilidad en términos de administración del enfoque según lo exijan las reglas y reglamentaciones. Por lo tanto, la interacción del enfoque de audio puede diferir entre los fabricantes y de una región a otra. La premisa básica del enfoque de audio sigue vigente, y las apps deben solicitar el enfoque para administrar mejor el audio y mejorar la experiencia del usuario. En general, aún se aplican ciertas reglas para las solicitudes de enfoque de audio de las apps:

  • Sin ningún enfoque de audio de alta prioridad permanente (incluida una llamada telefónica, una alerta de emergencia o una notificación de seguridad), las apps deberían poder obtener el enfoque de audio de forma transitoria o permanente.

  • Mientras un enfoque multimedia está activo, sucede lo siguiente:

    • Las apps que soliciten el enfoque de uso de llamadas deben poder recibir la llamada de forma simultánea o exclusiva.

    • Las apps que soliciten el enfoque de uso de navegación deben poder recibir el enfoque de navegación de forma simultánea o exclusiva.

    • Las apps que soliciten el enfoque de uso del asistente deben poder recibirlo de forma simultánea o exclusiva.

  • Mientras las apps de enfoque de audio de alta prioridad (incluidas las llamadas telefónicas, las alertas de emergencia o las notificaciones de seguridad) están activas, se debe otorgar o retrasar cualquier solicitud de enfoque de audio retrasado entrante según sea necesario.

Si bien estas sugerencias no son exhaustivas, pueden ayudar a las apps que solicitan enfoque a obtenerlo si no hay sonidos activos de alta prioridad. Incluso mientras los sonidos de prioridad alta están activos, se deben respetar las solicitudes de enfoque diferido y deben poder enfocarse cuando se detiene el sonido de prioridad alta.