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 que se inició recientemente se muestra con AUDIOFOCUS_REQUEST_GRANTED, mientras que la app que reproduce música 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. Como 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 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 titular 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.

Cómo controlar transmisiones simultáneas

Si bien la interacción simultánea tiene muchos usos, ten cuidado con la combinación y la atenuación a nivel del hardware en todos los dispositivos de salida. Te recomendamos que los 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 se sigue reproduciendo en el resto de la cabina.

Matriz de interacción

En la siguiente 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, se compara una solicitud de enfoque entrante 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.

Figura 1: Matriz de interacción del 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 titulares 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 diferido

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 provocarí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 diferido

  • 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 un OnAudioFocusChangeListener. Una vez 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).

Solicita foco demorable

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

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 desea 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 reproducen 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 HAL escuche y responda a los cambios en el enfoque 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 para el 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, ocurre 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 (incluida una llamada telefónica, una alerta de emergencia o una notificación de seguridad) están activas, se debe otorgar o retrasar cualquier solicitud de enfoque de audio retrasado entrante según sea necesario.

Si bien las sugerencias anteriores 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 retrasadas y deben poder enfocarse cuando se detiene el sonido de prioridad alta.