Foco de audio

Antes de iniciar una transmisión lógica, una app solicita un foco de audio con el mismo atributos de audio, tal como se usan para la transmisión lógica. La app debe respetar el enfoque de datos 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 manera forzosa. Por lo tanto, considera el enfoque como un medio para controlar y evitar indirectamente los conflictos. durante la reproducción, y no como mecanismo principal de control de audio. El vehículo no debería depender del sistema de enfoque para el funcionamiento del subsistema de audio.

Enfocar interacciones

Para admitir AAOS, las solicitudes de foco de audio se manejan según parámetros interacciones entre el CarAudioContext de la solicitud y el de la configuración contenedores de enfoque. Existen tres tipos de interacciones:

  • Exclusivo
  • Rechazar
  • Concurrent

Interacción exclusiva

Este es el modelo de interacción que se usa con mayor frecuencia en Android.

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

Rechazar interacción

Con las interacciones de tipo reject, las solicitudes entrantes se rechazan siempre. Para por ejemplo, cuando se intenta reproducir música mientras hay una llamada en curso. En este si el Teléfono mantiene el foco de audio para una llamada y otra 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 foco, no se despacha ninguna pérdida de foco al contenedor de enfoque actual.

Interacción simultánea

Las interacciones simultáneas son exclusivas de AAOS. De esta manera, las apps que solicitan audio el enfoque en el vehículo y la capacidad de mantenerlo al mismo tiempo que otras apps Para un interacción simultánea, se deben cumplir las siguientes condiciones. La

Si se cumplen estos criterios, la solicitud de enfoque muestra AUDIOFOCUS_REQUEST_GRANTED mientras que el contenedor de enfoque actual no tiene cambios en tu enfoque. Sin embargo, si el contenedor de foco actual opta por recibir eventos de pato o pausa cuando se atenúa, el contenedor de enfoque actual pierde el foco, como ocurre con una interacción exclusiva.

Cómo controlar transmisiones simultáneas

Si bien la interacción simultánea tiene varios usos, ten cuidado con la combinación y disminución automática del nivel de hardware en los dispositivos de salida. Te recomendamos que lo hagas Los CarAudioContext que pueden reproducirse simultáneamente deben enrutarse a diferentes dispositivos de salida.

Como hay dispositivos de salida separados para transmisiones simultáneas, se habilita la HAL para ocultar una de las transmisiones antes de mezclarlas, o para enrutar las transmisiones físicas a diferentes bocinas del vehículo. Si las transmisiones lógicas se mezclan Android, las ganancias no se modifican y se entregan como parte de la misma transmisión física.

Por ejemplo, cuando la navegación y el contenido multimedia se entregan simultáneamente, la ganancia de la transmisión de medios podrían reducirse temporalmente (o atenuarse) para que las instrucciones de navegación se escuchen con mayor claridad. De manera alternativa, la navegación transmisión podría enrutarse a las bocinas del lado del conductor mientras el contenido multimedia continúa jugar en el resto de la cabina.

Matriz de interacción

En la siguiente tabla, se muestra la matriz de interacción según lo define CarAudioService. Cada fila representa el CarAudioContext del contenedor de enfoque actual y cada columna representa la de la solicitud entrante.

Por ejemplo, cuando una app de música multimedia mantiene el enfoque como una solicitud de una app de navegación. enfoque, la matriz indica que las dos interacciones pueden reproducirse al mismo tiempo, suponiendo que los otros criterios para interacciones simultáneas.

Debido a las interacciones simultáneas, es posible tener más de una elemento de foco. En este caso, una solicitud de enfoque entrante se compara con cada los contenedores de enfoque actuales antes de determinar qué interacción aplicar. En este caso, la interacción más conservadora gana. Rechazar, luego, excluir por fin son simultáneas.

Matriz de interacción del foco de audio

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

En Android 11, se introdujo un nuevo parámetro de configuración para los usuarios que les permite modificar la 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 las CALL actuales contenedores de enfoque de simultáneo a rechazos. Si un usuario prefiere que las instrucciones de navegación no interrumpen la llamada, pueden habilitar la configuración. Esta se conserva para el usuario y se puede configurar dinámicamente para que externas respetan la nueva configuración.

Enfoque de audio retrasable

En Android 11, AAOS agregó compatibilidad para solicitar foco de audio retrasable. Esta permite que las solicitudes de enfoque no transitorias se retrasen cuando su interacción con los contenedores de enfoque actuales, por lo general, los rechazarían. Una vez por el cambio de enfoque genera un estado en el que la solicitud retrasada puede obtener el foco se otorga la solicitud.

Reglas para solicitudes de foco de audio retrasado

  • Solo solicitudes no transitorias. Una solicitud demorada solo puede realizarse en fuentes no transitorias para evitar que un sonido transitorio reproduzca después de que son relevantes.

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

  • Las solicitudes retardables deben tener un OnAudioFocusChangeListener. se retrasa, el objeto de escucha se usa para notificar al solicitante cuando la solicitud se otorga (AUDIOFOCUS_GAIN) o si más tarde se rechaza AUDIOFOCUS_LOSS.

Cómo solicitar un enfoque retrasable

Para crear una solicitud que se puede retrasar, sigue estos pasos:

  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 de 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 del foco maneja 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 del enfoque multizona

Para vehículos con varias zonas de audio, el foco 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 foco en otras zonas ni hace que los titulares de foco de otras zonas a perder el foco. De esta forma, el foco de la cabina principal se puede controlar de forma independiente desde un trasero, sin interrumpir la reproducción de audio en una zona por cambios realizados en otra.

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

Solicita audio de varias zonas de forma simultánea

Si una app quiere reproducir audio en varias zonas de forma simultánea, debe solicitar para cada zona incluyendo 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 de paquete permite que el solicitante anule la zona de audio automática asignaciones, para usar en su lugar el ID de zona especificado. Por lo tanto, una app podría generar solicitudes separadas para diferentes zonas de audio.

Foco de audio de la HAL

A partir de Android 11, la HAL está habilitada para solicitar foco en nombre de transmisiones externas. Si bien es opcional, se recomienda el uso de estas APIs para permitir que los sonidos externos participen óptimos en el ecosistema de Android y para brindar una experiencia del usuario fluida.

La HAL toma la decisión final sobre qué sonidos deben tener prioridad. Los sonidos críticos de emergencia y seguridad deben reproducirse independientemente de si se le otorgó foco de audio a la HAL y debería seguir recibiendo se reproducirá de manera apropiada, incluso si la HAL pierde el foco de audio. Lo mismo sucede con los sonidos que exigen las reglamentaciones gubernamentales.

La HAL debe silenciar proactivamente las transmisiones de Android durante la reproducción, según corresponda. los sonidos esenciales o de emergencia para garantizar que se escuchen con claridad.

Control de audio@2.0

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

API Propósito
IAudioControl#registerFocusListener Registra una instancia de IFocusListener con el HAL de AudioControl Este objeto de escucha permite que la HAL solicite y abandone audio. tu enfoque. La HAl proporciona una instancia de ICloseHandle para que la use. Android para cancelar el registro del objeto de escucha.
IAudioControl#onAudioFocusChange Notifica a la HAL los cambios de estado en las solicitudes de enfoque que realiza la HAL. hasta el IFocusListener, incluidas las respuestas a los correos de enfoque.
IFocusListener#requestAudioFocus Las solicitudes se enfocan en la HAL para un uso específico, un ID de zona y el tipo de ganancia de enfoque.
IFocusListener#abandonAudioFocus Abandona las solicitudes de enfoque de HAL existentes para el uso y la zona especificados. ID

La HAL puede tener varias solicitudes de enfoque al mismo tiempo, pero se limita a una solicitud por uso y vinculación de ID de zona. Android asume la HAL de inmediato comienza a reproducir sonidos para un uso una vez que se ha realizado una solicitud y continúa hacerlo hasta que abandone el foco.

Además de registerFocusListener, estas solicitudes son oneway para garantizar que Android no retrasa la HAL mientras se procesa una solicitud de enfoque. La HAL debe no esperar a obtener enfoque antes de reproducir sonidos críticos para la seguridad. Este campo es opcional. de modo que la HAL detecte y responda a los cambios en el foco de audio mediante IAudioControl#onAudioFocusChange

Servicio de foco de audio para automóviles del OEM

En Android 14, AAOS introdujo los servicios de complementos del OEM de vehículos para permitir la configuración de algunos componentes del vehículo. Para Car Audio Plugin Service, el complemento permite que los OEMs administren las solicitudes de foco interceptadas por el audio del vehículo. servicio. Esto les brinda a los OEM más flexibilidad en cuanto a la administración del enfoque según sea necesario. por las reglas y reglamentaciones. Por lo tanto, la interacción del foco de audio puede diferir entre fabricantes y de una región a otra. La premisa básica del foco de audio se mantiene, que las apps deben seguir solicitando enfoque para mejorar la administración del audio para mejorar la experiencia del usuario. En general, se siguen aplicando ciertas reglas para el audio solicitud de enfoque por aplicaciones:

  • Sin posición de pie, el foco de audio de alta prioridad (incluida una llamada telefónica, las apps de alertas de emergencia o de seguridad), de forma transitoria o permanente.

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

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

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

    • Las apps que solicitan enfoque en el uso del Asistente deben poder recibir ese enfoque de forma simultánea o exclusiva.

  • Mientras está de pie, el foco de audio de alta prioridad (incluida una llamada telefónica, apps de alertas de emergencia o notificaciones de seguridad) estén activas, cualquier mensaje entrante la solicitud de foco de audio retrasado se debe otorgar o retrasar según sea necesario.

Si bien las sugerencias anteriores no son exhaustivas, pueden ayudar a las apps que solicitan enfoque para obtenerlo si no existen sonidos activos de prioridad alta. Incluso con niveles altos Los sonidos prioritarios están activos, se deben seguir respetando las solicitudes de enfoque demorado. y debería obtener enfoque cuando se detenga el sonido de prioridad alta.