Reestruturação do SCO gerenciado por áudio

Nesta página, descrevemos como ativar o framework de áudio e a HAL de áudio (AHAL) para gerenciar conexões síncronas orientadas a conexão (SCO), um processo identificado como SCO gerenciado por áudio (AMSCO).

No Android 17 e versões 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 à estrutura do BT para uma consequência de downstream da atividade de streaming de áudio.

Ao centralizar a propriedade do roteamento de áudio na estrutura de áudio, esse recurso alinha a implementação da camada de abstração de hardware (HAL) de áudio 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:

O AHAL inicia e suspende a sessão SCO somente se as condições a seguir forem atendidas:

• Um stream ativo é corrigido para um dispositivo SCO.
• O modo áudio está definido, e há 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. A estrutura de áudio não envia mais mudanças de estado do SCO nem suspensões do A2DP para o AHAL.

A estrutura de áudio gerencia o SCO, então a pilha BT não chama mais conectar ou desconectar áudio. Em casos de desconexão ou erro preemptivo de SCO, a pilha 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 os 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

O 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 BT. O estado do fluxo é gerenciado usando diferentes IBluetoothAudioProviders, que são enumerados e criados por uma classe Factory, dependendo dos caminhos disponíveis.

A pilha 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 é preferido em relação ao software LC3, seguido pelo hardware mSBC, depois o software mSBC e, por fim, o hardware CVSD é preferido em relação ao software CVSD.

Os diagramas de sequência a seguir detalham as interações entre o AHAL e a pilha BT necessárias para estabelecer o estado do fluxo.

Procedimento de descarga de hardware

A Figura 1 ilustra como as pilhas AHAL e BT se coordenam para estabelecer um caminho de dados de hardware direto para á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 exige 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 BT disponível (AT+BAC), ele 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 em HeadsetStateMachine

A máquina de estado do headset da camada Java (representada pela classe HeadsetStateMachine) permanece praticamente inalterada, exceto pelo 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 da conexão de áudio da pilha nativa. Essas mudanças são acionadas pelos comandos do 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:

1. Notifique o framework de áudio sobre mudanças no BT ativo para ajudar no gerenciamento adequado de início e encerramento de SCO durante 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. Conecte o dispositivo HFP.

   O framework de áudio usa o callback AudioManagerAudioDeviceCallback#onAudioDevicesAdded em vez de transmissões legadas para indicar o estado do dispositivo de áudio.

2. Implemente o controle de fluxo AHAL usando setCommunicationDevice(AudioDeviceInfodevice) como o ponto de controle principal para iniciar a conexão SCO.

   Se HfpTransport::StartRequest retornar BluetoothAudioCtrlAck::PENDING, o AHAL precisará tentar novamente a solicitação porque a máquina de estado HFP não foi estabelecida.

Casos de uso

As seções a seguir descrevem 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 o telecom aguarde a conclusão da execução de phoneStateChanged no método BluetoothInCallService.onCallAdded() 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, ele direciona o 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 viva-voz (HF) e AG, a pilha BT precisa solicitar que a estrutura de áudio abra o SCO usando AudioManager.setCommunicationDevice(). Isso é ilustrado na figura a seguir:

Figura 7. Início do SCO de reconhecimento de voz.

Conexão de áudio

A pilha BT inicia uma conexão SCO solicitando a estrutura de áudio com AudioManager.setCommunicationDevice(AudioDeviceInfo) durante o reconhecimento de voz. Se uma chamada estiver ativa, a pilha de BT vai 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:

• Verificador do CTS: use o verificador do CTS para testes interativos de roteamento de áudio durante as chamadas.
• Vendor Test Suite (VTS): valide as interações de AHAL e BT AHAL usando o VTS.

Requisitos

Este recurso está sujeito aos seguintes requisitos:

• AHAL: a implementação requer uma AHAL compatível que ofereça suporte ao caminho de gerenciamento de SCO refatorado.