Nesta página, descrevemos como ativar o framework de áudio e a HAL de áudio (AHAL) para gerenciar conexões síncronas orientadas à conexão (SCO, na sigla em inglês), um processo identificado como SCO gerenciado por áudio (AMSCO).
No Android 17 e mais recentes, o framework de áudio do Android usa o recurso de gerenciamento de SCO para gerenciar o roteamento de SCO, que era originalmente processado pelo framework Bluetooth (BT). Essa migração move o status da conexão SCO de um estado pertencente ao framework BT para uma consequência downstream da atividade de streaming de áudio.
Ao centralizar a propriedade do roteamento de áudio no framework de áudio, esse recurso alinha a implementação da camada de abstração de hardware de áudio (HAL) para SCO com outros perfis de BT, como o Advanced Audio Distribution Profile (A2DP) e o LE Audio. Essa refatoração simplifica a interação entre as pilhas de telecomunicações e BT, permitindo uma arquitetura de roteamento de áudio mais robusta e centralizada.
Visão geral da arquitetura
A arquitetura AMSCO centraliza o gerenciamento de conexões SCO no framework de áudio do Android, que baseia as decisões de roteamento na atividade de streaming de áudio. Essa arquitetura contrasta com o modelo anterior, em que a pilha de BT gerenciava as conexões. As funções de cada componente nessa arquitetura são as seguintes:
A AHAL inicia e suspende a sessão SCO somente se as seguintes condições forem atendidas:
- Um stream ativo é corrigido para um dispositivo SCO.
- O modo áudio está definido e existe um patch para um dispositivo SCO.
O framework de áudio impede que um dispositivo A2DP tenha um patch simultâneo quando esses critérios específicos são atendidos. O framework de áudio não envia mais mudanças de estado de SCO nem suspensões de A2DP para a AHAL.
O framework de áudio processa o gerenciamento de SCO, então a pilha de BT não chama mais o áudio de conexão ou desconexão. Em casos de desconexão ou erro de SCO preventivo, a pilha de BT informa o framework de áudio com AudioManager#onHfpAudioDisconnected.
Plano
Use as informações nesta seção para avaliar os seguintes requisitos de compatibilidade e arquitetura antes de implementar a refatoração do gerenciamento de SCO.
Compatibilidade com versões anteriores
Para permitir que o framework continue oferecendo suporte a dispositivos que podem receber atualizações do SO sem atualizar as AHALs ou AHALs de BT, use uma propriedade do sistema para indicar que o novo gerenciamento de SCO precisa ser ativado. O caminho legado é preservado por até seis anos nos casos em que a propriedade do sistema está desativada ou a versão da HAL está desatualizada.
Configurar a sessão HFP
A AHAL precisa usar o novo tipo de sessão de perfil mãos-livres (HFP) para iniciar ou suspender a reprodução, semelhante a outros tipos de sessão de BT. O estado do stream é gerenciado usando diferentes IBluetoothAudioProviders, que são enumerados e criados por uma classe Factory, dependendo dos caminhos disponíveis.
A pilha de BT usa um caminho de descarga de hardware sempre que possível. A preferência por codecs durante a negociação segue esta ordem: o hardware LC3 é preferível ao software LC3, seguido pelo hardware mSBC, depois o software mSBC e, por fim, o hardware CVSD é preferível ao software CVSD.
Os diagramas de sequência a seguir detalham as interações entre a AHAL e a pilha de BT necessárias para estabelecer o estado do stream.
Procedimento de descarga de hardware
A Figura 1 ilustra como a AHAL e a pilha de BT se coordenam para estabelecer um caminho de dados de hardware direto para o áudio SCO:
Figura 1. Procedimento de descarga de hardware.
Procedimento de caminho de dados de software
A Figura 2 ilustra o processo de tratamento de dados de áudio que exigem o processamento de software do sistema:
Figura 2. Procedimento de caminho de dados de software.
Procedimento de renegociação de codec
Quando o gateway de áudio (AG) recebe um novo comando de codec disponível de BT (AT+BAC), o AG reinicia o procedimento de negociação de codec. A Figura 3 ilustra o procedimento de renegociação de codec:
Figura 3. Procedimento de renegociação de codec.
Impacto no HeadsetStateMachine
A máquina de estado do headset da camada Java (representada pela classe HeadsetStateMachine) permanece praticamente inalterada, com exceção do estado AUDIO_CONNECTED, que é controlado por eventos de pilha nativa.
Na camada Java, o sistema não inicia mais
connectAudioNative ou disconnectAudioNative. Em vez disso, o sistema responde a mudanças de estado de conexão de áudio da pilha nativa. Essas mudanças são acionadas pelos comandos da AHAL em IBluetoothAudioProvider ou IBluetoothAudioPort.
Implementação
Para integrar a refatoração do gerenciamento de SCO, atualize a comunicação entre a pilha de BT e o framework de áudio.
Siga estas etapas para implementar o recurso:
Notifique o framework de áudio sobre mudanças no BT ativo para ajudar no gerenciamento adequado da iniciação e da desmontagem do SCO durante as conexões de dispositivos HFP e para processar mudanças de dispositivos ativos. Use
AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo)para fornecer essas informações ao framework de áudio.
Figura 4. Conectar dispositivo HFP.
O framework de áudio usa o callback
AudioManagerAudioDeviceCallback#onAudioDevicesAddedem vez de transmissões legadas para indicar o estado do dispositivo de áudio.Implemente o controle de stream AHAL usando
setCommunicationDevice(AudioDeviceInfodevice)como o ponto de controle principal para iniciar a conexão SCO.Se
HfpTransport::StartRequestretornarBluetoothAudioCtrlAck::PENDING, a AHAL precisará tentar novamente a solicitação porque a máquina de estado HFP não está estabelecida.
Casos de uso
As seções a seguir descrevem as jornadas ideais do usuário (CUJs) típicas.
Fluxo de chamadas de telecomunicações
A refatoração do gerenciamento de SCO muda phoneStateChanged para uma função de bloqueio. Essa modificação faz com que a telecomunicações aguarde a execução de phoneStateChanged no método BluetoothInCallService.onCallAdded para ser concluída antes de invocar a API do framework de áudio para iniciar a criação de SCO.
Figura 5. Atender ou iniciar uma chamada por telecomunicações.
Fluxo de chamadas VOIP
O framework de áudio inicia o processo chamando o método BluetoothHeadset.startScoUsingVirtualVoiceCall. Depois que a pilha de BT fornece um resultado ao framework de áudio, o framework direciona a AHAL para executar startStream. A figura a seguir ilustra esse fluxo:
Figura 6. Atender ou iniciar uma chamada por VOIP.
Reconhecimento de voz
Para o reconhecimento de voz iniciado por mãos-livres (HF) e AG, a pilha de BT precisa solicitar que o framework de áudio abra o SCO usando AudioManager.setCommunicationDevice. Isso é ilustrado na figura a seguir:
Figura 7. Iniciação de SCO de reconhecimento de voz.
Conexão de áudio
A pilha de BT inicia uma conexão SCO solicitando o framework de áudio com
AudioManager.setCommunicationDevice(AudioDeviceInfo) durante o reconhecimento de voz. Se uma chamada estiver ativa, a pilha de BT solicitará BluetoothInCallService#requestBluetoothAudio da pilha de telecomunicações.
Esse processo é mostrado na figura a seguir:
Figura 8. Conexão de áudio.
Validação e teste
Para validar se o recurso está integrado corretamente e atende aos padrões de qualidade, os fabricantes de dispositivos precisam executar os seguintes testes:
- CTS Verifier: use o CTS Verifier para testes interativos de roteamento de áudio durante chamadas.
- Pacote de testes de fornecedor (VTS): valide as interações AHAL e BT AHAL usando o VTS.
Requisitos
Esse recurso está sujeito aos seguintes requisitos:
- AHAL: a implementação exige uma AHAL compatível que ofereça suporte ao caminho de gerenciamento de SCO refatorado.