O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Áudio automotivo

O Android Automotive OS (AAOS) se baseia na pilha de áudio principal do Android para dar suporte aos casos de uso para operar como o sistema de infoentretenimento em um veículo. AAOS é responsável pelos sons de infoentretenimento (ou seja, mídia, navegação e comunicações), mas não é diretamente responsável por sinos e avisos que têm requisitos estritos de disponibilidade e tempo. Embora o AAOS forneça sinais e mecanismos para ajudar o veículo a gerenciar o áudio, no final cabe ao veículo decidir quais sons devem ser reproduzidos para o motorista e os passageiros, garantindo que os sons críticos de segurança e os sons regulatórios sejam ouvidos corretamente sem interrupção.

Como o Android gerencia a experiência de mídia do veículo, as fontes de mídia externas, como o sintonizador de rádio, devem ser representadas por aplicativos, que podem lidar com o foco de áudio e eventos principais de mídia para a fonte.

O Android 11 inclui as seguintes alterações no suporte de áudio automotivo:

Sons e streams do Android

Os sistemas de áudio automotivos lidam com os seguintes sons e fluxos:

Diagrama de arquitetura centrada em fluxo

Diagrama de arquitetura Figura 1. Corrente centrada

O Android gerencia os sons provenientes de aplicativos Android, controlando esses aplicativos e direcionando seus sons para dispositivos de saída no HAL com base no tipo de som:

  • Fluxos lógicos, conhecidos como fontes na nomenclatura áudio core, são marcados com Atributos de áudio .
  • Fluxos físicos, conhecidos como dispositivos na nomenclatura áudio núcleo, não têm informações de contexto depois de misturar.

Para confiabilidade, sons externos (provenientes de fontes independentes, tais como sinos de aviso de cinto de segurança) são geridos fora Android, abaixo do HAL ou mesmo em hardware separado. Os implementadores do sistema devem fornecer um mixer que aceite um ou mais fluxos de entrada de som do Android e, em seguida, combine esses fluxos de forma adequada com as fontes de som externas exigidas pelo veículo.

A implementação do HAL e o mixer externo são responsáveis ​​por garantir que os sons externos essenciais para a segurança sejam ouvidos e por mixar nos streams fornecidos pelo Android e encaminhá-los para alto-falantes adequados.

Sons Android

Apps pode ter um ou mais jogadores que interagem através das APIs do Android padrão (por exemplo, AudioManager para controle de foco ou MediaPlayer para streaming) para emitir um ou mais lógicos fluxos de dados de áudio. Esses dados podem ser mono de canal único ou surround 7.1, mas são roteados e tratados como uma única fonte. O fluxo aplicativo está associado com AudioAttributes que dão as dicas do sistema sobre como o áudio deve ser expressa.

Os streams lógicos são enviados por AudioService e roteados para um (e apenas um) dos streams de saída física disponíveis, cada um dos quais é a saída de um mixer dentro do AudioFlinger. Depois que os atributos de áudio foram mixados em um fluxo físico, eles não estão mais disponíveis.

Cada fluxo físico é então entregue ao HAL de áudio para renderização no hardware. Em aplicativos automotivos, o hardware de renderização pode ser codecs locais (semelhantes aos dispositivos móveis) ou um processador remoto na rede física do veículo. De qualquer forma, é função da implementação do Audio HAL fornecer os dados de amostra reais e torná-los audíveis.

Streams externos

Os streams de som que não devem ser roteados pelo Android (por motivos de certificação ou tempo) podem ser enviados diretamente para o mixer externo. A partir do Android 11, o HAL agora é capaz de solicitar o foco para esses sons externos para informar o Android de forma que ele possa realizar as ações apropriadas, como pausar a mídia ou impedir que outros obtenham o foco.

Se streams externos forem fontes de mídia que devem interagir com o ambiente de som que o Android está gerando (por exemplo, pare a reprodução de MP3 quando um sintonizador externo é ligado), esses streams externos devem ser representados por um aplicativo Android. Tal aplicativo solicitaria foco de áudio em nome da fonte de mídia em vez do HAL, e responderia às notificações de foco iniciando / parando a fonte externa conforme necessário para se ajustar à política de foco do Android. O aplicativo também é responsável por manipular eventos-chave de mídia, como reproduzir / pausar. Um mecanismo sugerido para controlar esses dispositivos externos é HwAudioSource .

Dispositivos de saída

No nível de áudio HAL, o tipo de dispositivo AUDIO_DEVICE_OUT_BUS fornece um dispositivo de saída genérico para uso em sistemas de áudio do veículo. O dispositivo de barramento oferece suporte a portas endereçáveis ​​(em que cada porta é o ponto final de um fluxo físico) e deve ser o único tipo de dispositivo de saída compatível em um veículo.

Uma implementação de sistema pode usar uma porta de barramento para todos os sons do Android, caso em que o Android mistura tudo e entrega como um único fluxo. Alternativamente, o HAL pode proporcionar uma porta de barramento para cada CarAudioContext para permitir a entrega concomitante de qualquer tipo de som. Isso possibilita que a implementação do HAL mixe e abaixe os diferentes sons conforme desejado.

A atribuição de contextos de áudio para dispositivos de saída é feito através car_audio_configuration.xml .

Entrada de microfone

Ao capturar áudio, o HAL áudio recebe um openInputStream chamada que inclui uma AudioSource argumento indicando como a entrada de microfone devem ser processados.

O VOICE_RECOGNITION fonte (especificamente o Assistente Google) espera um fluxo de microfone estéreo que tem um efeito de cancelamento de eco (se disponível), mas nenhum outro processamento aplicado a ele. Espera-se que a formação de feixes seja feita pelo assistente.

Entrada de microfone multicanal

Para capturar áudio de um dispositivo com mais de dois canais (estéreo), use uma máscara índice de canal em vez de máscara índice posicional (como CHANNEL_IN_LEFT ). Exemplo:

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);

Quando ambos setChannelMask e setChannelIndexMask são definidas, AudioRecord utiliza apenas o valor ajustado por setChannelMask (máximo de dois canais).

Captura simultânea

A partir do Android 10, o quadro Android suporta captura simultânea de entradas , mas com restrições para proteger a privacidade do usuário. Como parte destas restrições, fontes virtuais como AUDIO_SOURCE_FM_TUNER são ignorados, e como tal estão autorizados a ser capturado simultaneamente, juntamente com uma entrada regular (tal como o microfone). HwAudioSources também não são considerados como parte das restrições de captura simultâneos.

Aplicativos projetados para trabalhar com AUDIO_DEVICE_IN_BUS dispositivos ou com secundários AUDIO_DEVICE_IN_FM_TUNER dispositivos devem confiar em identificar explicitamente os dispositivos e usando AudioRecord.setPreferredDevice() para ignorar a lógica de seleção de fonte padrão Android.

Usos de áudio

AAOS utiliza principalmente AudioAttributes.AttributeUsages para roteamento, ajustes de volume e gerenciamento de foco. Os usos são uma representação do "por que" o fluxo está sendo reproduzido. Portanto, todos os streams e solicitações de focus de áudio devem especificar um uso para sua reprodução de áudio. Quando não especificamente definido quando a construção de um objeto AudioAttributes, o uso será padronizada para USAGE_UNKOWN . Enquanto isso está actualmente tratados da mesma forma USAGE_MEDIA , este comportamento não deve ser invocado para reprodução de mídia.

Usos do sistema

No Android 11, os usos do sistema foram introduzidos. Esses usos comportam de forma semelhante aos usos previamente estabelecidos, exceto que eles exigem APIs do sistema a utilizar, bem como android.permission.MODIFY_AUDIO_ROUTING . Os novos usos do sistema são:

  • USAGE_EMERGENCY
  • USAGE_SAFETY
  • USAGE_VEHICLE_STATUS
  • USAGE_ANNOUNCEMENT

Para construir um AudioAttributes com o uso do sistema, use AudioAttributes.Builder#setSystemUsage vez de setUsage . Chamar esse método com um uso não-sistema irá resultar em um IllegalArgumentException sendo lançada. Além disso, se tanto um uso e uso do sistema foram definidos em um construtor, que irá lançar uma IllegalArgumentException quando a construção.

Para verificar o uso está associado a um AudioAttributes exemplo, chamar AudioAttributes#getSystemUsage . Isso retorna o uso ou o uso do sistema que está associado.

Contextos de áudio

Para configuração simplificado de AAOS áudio, usos semelhantes foram agrupados em CarAudioContext . Estes contextos de áudio são utilizados em todo CarAudioService para definir encaminhamento, grupos de volume e gerenciamento de foco de áudio.

Os contextos de áudio no Android 11 são:

CarAudioContext AttributeUsages associados
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

Mapeamento entre contextos e usos de áudio. Linhas destacadas estão para novos usos do sistema .

Áudio multi-zona

Com o automotivo, vem um novo conjunto de casos de uso em torno de usuários simultâneos interagindo com a plataforma e procurando consumir mídia separada. Por exemplo, um motorista pode tocar música na cabine enquanto os passageiros no banco de trás assistem a um vídeo do YouTube no display traseiro. O áudio de várias zonas permite isso, permitindo que diferentes fontes de áudio sejam reproduzidas simultaneamente em diferentes áreas do veículo.

O áudio de várias zonas a partir do Android 10 permite que os OEMs configurem o áudio em zonas separadas. Cada zona é uma coleção de dispositivos dentro do veículo com seus próprios grupos de volume, configuração de roteamento para contextos e gerenciamento de foco. Desta forma, a cabine principal pode ser configurada como uma zona de áudio, enquanto os conectores de fone de ouvido do display traseiro podem ser configurados como uma segunda zona.

As zonas são definidas como parte de car_audio_configuration.xml . CarAudioService em seguida, lê a configuração e ajuda áudio rota AudioService córregos com base em sua zona associada. Cada zona ainda define regras para roteamento com base nos contextos e no uid dos aplicativos. Quando um jogador é criado, CarAudioService determina para qual zona o jogador está associado, e, em seguida, com base no uso, o dispositivo que o AudioFlinger deve encaminhar o áudio para.

O foco também é mantido independentemente para cada zona de áudio. Isso permite que aplicativos em zonas diferentes produzam áudio de forma independente, sem interferir uns nos outros, enquanto os aplicativos ainda respeitam as mudanças de foco dentro de sua zona. CarZonesAudioFocus dentro CarAudioService é responsável pela gestão de foco para cada zona.

Configurar áudio multi-zona

Figura 2. Configure o áudio de várias zonas

Áudio HAL

Implementações de áudio automotivos contar com o padrão Android Áudio HAL , que inclui o seguinte:

  • IDevice.hal . Cria fluxos de entrada e saída, lida com o volume mestre e mudo e usa:
    • createAudioPatch . Para criar patches externos-externos entre dispositivos.
    • IDevice.setAudioPortConfig() para proporcionar um volume para cada fluxo físico.
  • IStream.hal . Junto com as variantes de entrada e saída, gerencia o streaming de amostras de áudio de e para o hardware.

Tipos de dispositivos automotivos

Os seguintes tipos de dispositivos são relevantes para plataformas automotivas.

Tipo de dispositivo Descrição
AUDIO_DEVICE_OUT_BUS Saída primária do Android (é assim que todo o áudio do Android é entregue ao veículo). Usado como o endereço para eliminar a ambiguidade de streams para cada contexto.
AUDIO_DEVICE_OUT_TELEPHONY_TX Usado para áudio roteado para o rádio celular para transmissão.
AUDIO_DEVICE_IN_BUS Usado para entradas não classificadas de outra forma.
AUDIO_DEVICE_IN_FM_TUNER Usado apenas para transmissão de entrada de rádio.
AUDIO_DEVICE_IN_TV_TUNER Usado para um dispositivo de TV, se houver.
AUDIO_DEVICE_IN_LINE Usado para entrada AUX.
AUDIO_DEVICE_IN_BLUETOOTH_A2DP Música recebida por Bluetooth.
AUDIO_DEVICE_IN_TELEPHONY_RX Usado para áudio recebido do rádio celular associado a uma chamada telefônica.

Configurando dispositivos de áudio

Dispositivos de áudio visíveis para Android deve ser definido no /audio_policy_configuration.xml , que inclui os seguintes componentes:

  • nome do módulo. Suporta "primário" (usado para casos de uso automotivos), "A2DP", "remote_submix" e "USB". O nome do módulo eo controlador de áudio correspondente deve ser compilado para audio.primary.$(variant).so .
  • devicePorts. Contém uma lista de descritores de dispositivo para todos os dispositivos de entrada e saída (inclui dispositivos permanentemente conectados e dispositivos removíveis) que podem ser acessados ​​a partir deste módulo.
    • Para cada dispositivo de saída, você pode definir o controle de ganho que consiste em valores mín. / Máx. / Padrão / passo em milibel (1 milibel = 1/100 dB = 1/1000 bel).
    • O atributo de endereço em uma instância DevicePort pode ser usado para localizar o dispositivo, mesmo se houver vários dispositivos com o mesmo tipo de dispositivo como AUDIO_DEVICE_OUT_BUS .
  • mixPorts. Contém uma lista de todos os fluxos de saída e entrada expostos pelo HAL de áudio. Cada instância mixPort pode ser considerada como um fluxo físico para Android AudioService.
  • rotas. Define uma lista de conexões possíveis entre dispositivos de entrada e saída ou entre stream e dispositivo.

O exemplo a seguir define um dispositivo de saída bus0_phone_out no qual todos os fluxos de áudio Android são mixados por mixer_bus0_phone_out. O percurso leva o fluxo de saída mixer_bus0_phone_out para o 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>