Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Audio automotriz

Android Automotive OS (AAOS) se basa en la pila de audio central de Android para admitir los casos de uso para operar como el sistema de información y entretenimiento en un vehículo. AAOS es responsable de los sonidos de información y entretenimiento (es decir, medios, navegación y comunicaciones), pero no es directamente responsable de las campanillas y advertencias que tienen requisitos estrictos de disponibilidad y tiempo. Si bien AAOS proporciona señales y mecanismos para ayudar al vehículo a administrar el audio, al final, es el vehículo quien decide qué sonidos deben reproducirse para el conductor y los pasajeros, lo que garantiza que los sonidos críticos para la seguridad y los sonidos regulatorios se escuchen correctamente sin interrupción.

A medida que Android gestiona la experiencia multimedia del vehículo, las fuentes de medios externas, como el sintonizador de radio, deben estar representadas por aplicaciones, que pueden gestionar el enfoque de audio y los eventos clave de medios para la fuente.

Android 11 incluye los siguientes cambios en el soporte de audio relacionado con la automoción:

Sonidos y transmisiones de Android

Los sistemas de audio para automóviles manejan los siguientes sonidos y transmisiones:

Diagrama de arquitectura centrada en la transmisión

Figura 1. Secuencia centrada en diagrama de la arquitectura

Android administra los sonidos provenientes de las aplicaciones de Android, controlando esas aplicaciones y enrutando sus sonidos a los dispositivos de salida en el HAL según el tipo de sonido:

  • Flujos lógicos, conocidos como fuentes en la nomenclatura de audio básico, etiquetados con Atributos de audio .
  • Flujos físicos, conocidos como dispositivos de nomenclatura audio núcleo, no tienen información de contexto después de la mezcla.

Para mayor fiabilidad, sonidos externos (procedentes de fuentes independientes, tales como campanillas de advertencia del cinturón de seguridad) se gestionan fuera de Android, por debajo de la HAL o incluso en hardware separado. Los implementadores del sistema deben proporcionar un mezclador que acepte uno o más flujos de entrada de sonido de Android y luego combine esos flujos de una manera adecuada con las fuentes de sonido externas requeridas por el vehículo.

La implementación de HAL y el mezclador externo son responsables de garantizar que se escuchen los sonidos externos críticos para la seguridad y de mezclar las transmisiones proporcionadas por Android y enrutarlas a los altavoces adecuados.

Sonidos de Android

Las aplicaciones pueden tener uno o más jugadores que interactúan a través de las API estándar de Android (por ejemplo, AudioManager para el control de enfoque o MediaPlayer para streaming) para emitir una o más lógicas corrientes de datos de audio. Estos datos pueden ser monocanal mono o envolvente 7.1, pero se enrutan y tratan como una sola fuente. La corriente aplicación está asociada con AudioAttributes que dan los consejos del sistema sobre cómo el audio debe ser expresada.

Los flujos lógicos se envían a través de AudioService y se enrutan a uno (y solo uno) de los flujos de salida físicos disponibles, cada uno de los cuales es la salida de un mezclador dentro de AudioFlinger. Una vez que los atributos de audio se han mezclado en una transmisión física, ya no están disponibles.

Luego, cada flujo físico se envía al Audio HAL para su procesamiento en el hardware. En las aplicaciones automotrices, el hardware de renderizado puede ser códecs locales (similares a los dispositivos móviles) o un procesador remoto a través de la red física del vehículo. De cualquier manera, el trabajo de la implementación de Audio HAL es entregar los datos de muestra reales y hacer que se vuelvan audibles.

Corrientes externas

Las transmisiones de sonido que no deben enrutarse a través de Android (por razones de certificación o sincronización) pueden enviarse directamente al mezclador externo. A partir de Android 11, HAL ahora puede solicitar el enfoque de estos sonidos externos para informar a Android de modo que pueda tomar las acciones adecuadas, como pausar los medios o evitar que otros se concentren.

Si las transmisiones externas son fuentes de medios que deberían interactuar con el entorno de sonido que genera Android (por ejemplo, detener la reproducción de MP3 cuando se enciende un sintonizador externo), esas transmisiones externas deben estar representadas por una aplicación de Android. Dicha aplicación solicitaría el enfoque de audio en nombre de la fuente de medios en lugar de la HAL, y respondería a las notificaciones de enfoque iniciando / deteniendo la fuente externa según sea necesario para adaptarse a la política de enfoque de Android. La aplicación también es responsable de manejar eventos clave de medios como reproducir / pausar. Un mecanismo sugerido para controlar tales dispositivos externos es HwAudioSource .

Dispositivos de salida

En el nivel de audio HAL, el tipo de dispositivo AUDIO_DEVICE_OUT_BUS proporciona un dispositivo de salida genérico para su uso en sistemas de audio de vehículos. El dispositivo de bus admite puertos direccionables (donde cada puerto es el punto final de un flujo físico) y se espera que sea el único tipo de dispositivo de salida admitido en un vehículo.

Una implementación de sistema puede usar un puerto de bus para todos los sonidos de Android, en cuyo caso Android mezcla todo y lo entrega como una transmisión. Alternativamente, la HAL puede proporcionar un puerto de bus para cada CarAudioContext para permitir la entrega simultánea de cualquier tipo de sonido. Esto hace posible que la implementación de HAL mezcle y esquive los diferentes sonidos como se desee.

La asignación de los contextos de audio a los dispositivos de salida se realiza a través car_audio_configuration.xml .

Entrada de micrófono

Al capturar audio, el audio HAL recibe una openInputStream llamada que incluye un AudioSource argumento que indica la forma en la entrada del micrófono se debe procesar.

El VOICE_RECOGNITION fuente (específicamente el Asistente de Google) espera un flujo de entrada de micrófono estéreo que tiene un efecto de cancelación de eco (si está disponible) pero ningún otro procesamiento aplicado a la misma. Se espera que el Asistente realice la formación de haces.

Entrada de micrófono multicanal

Para la captura de audio desde un dispositivo con más de dos canales (estéreo), utilizar una máscara índice de canal en lugar de máscara índice posicional (como CHANNEL_IN_LEFT ). Ejemplo:

final AudioFormat audioFormat = new AudioFormat.Builder()
    .setEncoding(AudioFormat.ENCODING_PCM_16BIT)
    .setSampleRate(44100)
    .setChannelIndexMask(0xf /* 4 channels, 0..3 */)
    .build();
final AudioRecord audioRecord = new AudioRecord.Builder()
    .setAudioFormat(audioFormat)
    .build();
audioRecord.setPreferredDevice(someAudioDeviceInfo);

Cuando ambos setChannelMask y setChannelIndexMask se establecen, AudioRecord sólo utiliza el valor establecido por setChannelMask (máximo de dos canales).

Captura concurrente

A partir del androide 10, el marco Android soporta la captura simultánea de las entradas , pero con restricciones para proteger la privacidad del usuario. Como parte de estas restricciones, las fuentes virtuales como AUDIO_SOURCE_FM_TUNER se ignoran, y como tales se les permite ser capturado simultáneamente junto con una entrada regular (tal como el micrófono). HwAudioSources también no se consideran como parte de las restricciones de captura concurrentes.

Aplicaciones diseñadas para funcionar con AUDIO_DEVICE_IN_BUS dispositivos o secundarias AUDIO_DEVICE_IN_FM_TUNER dispositivos deben confiar en la identificación explícita esos dispositivos y el uso de AudioRecord.setPreferredDevice() para omitir la lógica de selección de fuente por defecto de Android.

Usos de audio

AAOS utiliza principalmente AudioAttributes.AttributeUsages para el encaminamiento, los ajustes de volumen, y la gestión de enfoque. Los usos son una representación del "por qué" se está reproduciendo la transmisión. Por lo tanto, todas las transmisiones y solicitudes de enfoque de audio deben especificar un uso para su reproducción de audio. Cuando no se establece específicamente en la construcción de un objeto AudioAttributes, el uso será por defecto en USAGE_UNKOWN . Si bien esto es tratada actualmente el mismo que USAGE_MEDIA , este comportamiento no debe ser invocado por la reproducción de medios.

Usos del sistema

En Android 11, se introdujeron los usos del sistema. Estos usos se comportan de manera similar a los usos anteriormente establecidos, si no se requieren las API del sistema a utilizar, así como android.permission.MODIFY_AUDIO_ROUTING . Los nuevos usos del sistema son:

  • USAGE_EMERGENCY
  • USAGE_SAFETY
  • USAGE_VEHICLE_STATUS
  • USAGE_ANNOUNCEMENT

Para construir un AudioAttributes con un uso del sistema, usar AudioAttributes.Builder#setSystemUsage en lugar de setUsage . Al llamar a este método con un sistema de uso no dará lugar a una IllegalArgumentException siendo lanzada. Además, si tanto el uso de un sistema y el uso han sido establecidas en un constructor, se lanzará una IllegalArgumentException en la construcción.

Para comprobar qué uso se asocia con un AudioAttributes ejemplo, llamar AudioAttributes#getSystemUsage . Esto devuelve el uso o el uso del sistema asociado.

Contextos de audio

Para simplificar la configuración de AAOS audio, usos similares se han agrupado en CarAudioContext . Estos contextos de audio se utilizan en todo CarAudioService para definir el enrutamiento, los grupos de volúmenes, y la administración de la selección de audio.

Los contextos de audio en Android 11 son:

CarAudioContext Usos de atributos asociados
MUSIC UNKNOWN, GAME, MEDIA
NAVIGATION ASSISTANCE_NAVIGATION_GUIDANCE
VOICE_COMMAND ASSISTANT, ASSISTANCE_ACCESSIBILITY
CALL_RING NOTIFICATION_RINGTONE
CALL VOICE_COMMUNICATION, VOICE_COMMUNICATION_SIGNALING
ALARM ALARM
NOTIFICATION NOTIFICATION, NOTIFICATION_*
SYSTEM_SOUND ASSISTANCE_SONIFICATION
EMERGENCY EMERGENCY
SAFETY SAFETY
VEHICLE_STATUS VEHICLE_STATUS
ANNOUNCEMENT ANNOUNCEMENT

Mapeo entre usos y contextos de audio. Filas resaltadas son para los nuevos usos del sistema .

Audio multizona

Con la industria automotriz viene un nuevo conjunto de casos de uso en torno a usuarios concurrentes que interactúan con la plataforma y buscan consumir medios separados. Por ejemplo, un conductor puede reproducir música en la cabina mientras los pasajeros en el asiento trasero miran un video de YouTube en la pantalla trasera. El audio multizona permite esto al permitir que diferentes fuentes de audio se reproduzcan simultáneamente a través de diferentes áreas del vehículo.

El audio multizona que se inicia en Android 10 permite a los fabricantes de equipos originales configurar el audio en zonas separadas. Cada zona es una colección de dispositivos dentro del vehículo con sus propios grupos de volumen, configuración de enrutamiento para contextos y administración de enfoque. De esta manera, la cabina principal podría configurarse como una zona de audio, mientras que las tomas de auriculares de la pantalla trasera podrían configurarse como una segunda zona.

Las zonas se definen como parte de car_audio_configuration.xml . CarAudioService continuación, lee la configuración de audio y ayuda a AudioService ruta secuencias basadas en su zona asociada. Cada zona aún define reglas para el enrutamiento según los contextos y el uid de las aplicaciones. Cuando se crea un jugador, CarAudioService determina para qué zona el jugador se asocia con, y entonces basándose en el uso, cuyo dispositivo la AudioFlinger debe enrutar el audio a.

El enfoque también se mantiene de forma independiente para cada zona de audio. Esto permite que las aplicaciones en diferentes zonas produzcan audio de forma independiente sin interferir entre sí mientras que las aplicaciones aún respetan los cambios de enfoque dentro de su zona. CarZonesAudioFocus dentro CarAudioService es responsable de la gestión de enfoque para cada zona.

Configurar audio multizona

Figura 2. Configurar audio multizona

Audio HAL

Implementaciones de audio para automóviles se basan en el estándar de Android Audio HAL , que incluye lo siguiente:

  • IDevice.hal . Crea flujos de entrada y salida, maneja el volumen maestro y el silenciamiento, y usa:
    • createAudioPatch . Para crear parches externos-externos entre dispositivos.
    • IDevice.setAudioPortConfig() para proporcionar volumen para cada flujo físico.
  • IStream.hal . Junto con las variantes de entrada y salida, gestiona la transmisión de muestras de audio hacia y desde el hardware.

Tipos de dispositivos automotrices

Los siguientes tipos de dispositivos son relevantes para plataformas automotrices.

Tipo de dispositivo Descripción
AUDIO_DEVICE_OUT_BUS Salida principal de Android (así es como todo el audio de Android se envía al vehículo). Se utiliza como dirección para eliminar la ambigüedad de los flujos de cada contexto.
AUDIO_DEVICE_OUT_TELEPHONY_TX Se utiliza para el audio enrutado a la radio celular para su transmisión.
AUDIO_DEVICE_IN_BUS Se utiliza para insumos no clasificados de otra manera.
AUDIO_DEVICE_IN_FM_TUNER Se utiliza solo para la entrada de radiodifusión.
AUDIO_DEVICE_IN_TV_TUNER Se utiliza para un dispositivo de TV, si está presente.
AUDIO_DEVICE_IN_LINE Se utiliza para la toma de entrada AUX.
AUDIO_DEVICE_IN_BLUETOOTH_A2DP Música recibida por Bluetooth.
AUDIO_DEVICE_IN_TELEPHONY_RX Se utiliza para el audio recibido de la radio celular asociada con una llamada telefónica.

Configurar dispositivos de audio

Los dispositivos de audio visibles para Android deben definirse en /audio_policy_configuration.xml , que incluye los siguientes componentes:

  • Nombre del módulo. Admite "primario" (utilizado para casos de uso automotriz), "A2DP", "remote_submix" y "USB". El nombre del módulo y el controlador de audio correspondientes deben compilarse a audio.primary.$(variant).so .
  • devicePorts. Contiene una lista de descriptores de dispositivo para todos los dispositivos de entrada y salida (incluye dispositivos conectados permanentemente y dispositivos extraíbles) a los que se puede acceder desde este módulo.
    • Para cada dispositivo de salida, puede definir un control de ganancia que consta de valores mínimos / máximos / predeterminados / escalonados en milibelios (1 milibel = 1/100 dB = 1/1000 bel).
    • El atributo de dirección en una instancia DevicePort se puede utilizar para encontrar el dispositivo, incluso si hay varios dispositivos con el mismo tipo de dispositivo como AUDIO_DEVICE_OUT_BUS .
  • mixPorts. Contiene una lista de todos los flujos de entrada y salida expuestos por la HAL de audio. Cada instancia de mixPort se puede considerar como una transmisión física para Android AudioService.
  • rutas. Define una lista de posibles conexiones entre dispositivos de entrada y salida o entre flujo y dispositivo.

El siguiente ejemplo define un dispositivo de salida bus0_phone_out en el que todas las transmisiones de audio de Android se mezclan mediante mixer_bus0_phone_out. La ruta toma el flujo de salida de mixer_bus0_phone_out al dispositivo bus0_phone_out .

<audioPolicyConfiguration version="1.0" xmlns:xi="http://www.w3.org/2001/XInclude">
    <modules>
        <module name="primary" halVersion="3.0">
            <attachedDevices>
                <item>bus0_phone_out</item>
<defaultOutputDevice>bus0_phone_out</defaultOutputDevice>
            <mixPorts>
                <mixPort name="mixport_bus0_phone_out"
                         role="source"
                         flags="AUDIO_OUTPUT_FLAG_PRIMARY">
                    <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
                            samplingRates="48000"
                            channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
                </mixPort>
            </mixPorts>
            <devicePorts>
                <devicePort tagName="bus0_phone_out"
                            role="sink"
                            type="AUDIO_DEVICE_OUT_BUS"
                            address="BUS00_PHONE">
                    <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
                            samplingRates="48000"
                            channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
                    <gains>
                        <gain name="" mode="AUDIO_GAIN_MODE_JOINT"
                                minValueMB="-8400"
                                maxValueMB="4000"
                                defaultValueMB="0"
                                stepValueMB="100"/>
                    </gains>
                </devicePort>
            </devicePorts>
            <routes>
                <route type="mix" sink="bus0_phone_out"
                       sources="mixport_bus0_phone_out"/>
            </routes>
        </module>
    </modules>
</audioPolicyConfiguration>