Áudio Bluetooth de baixa energia

O áudio Bluetooth de baixa energia (LEA) garante que os usuários recebam áudio de alta fidelidade sem sacrificar a duração da bateria e permite que eles alternem facilmente entre diferentes casos de uso. O Android 13 (nível 33 da API) inclui suporte integrado para o LEA.

A maioria dos fones de ouvido com LEA terá modo duplo até que a participação de mercado do dispositivo de origem com LEA cresça. Os usuários precisam conseguir parear e configurar os dois transportes nos fones de ouvido de modo duplo.

Casos de uso

Você pode integrar o LEA para os seguintes casos de uso:

• Compartilhamento de áudio: os usuários podem compartilhar simultaneamente vários streams de áudio com um ou mais dispositivos de coletor de áudio. O áudio é sincronizado entre o dispositivo de origem e os dispositivos conectados.

• Transmissão de áudio: os usuários podem transmitir áudio para amigos e familiares, além de se conectar a transmissões públicas para receber informações, entretenimento ou acessibilidade.

• Compatibilidade com o codec de áudio LC3: esse é o codec de áudio padrão e substitui o codec SBC usado para A2DP (mídia) e mSBC no HFP (voz). O LC3 é mais eficiente, reconfigurável e de maior qualidade.

• Melhorias na amostragem de áudio: os fones de ouvido podem manter a alta qualidade de áudio de saída ao usar microfones. O Bluetooth clássico reduz a qualidade do áudio ao usar microfones Bluetooth. Com o áudio BLE, a amostragem de entrada e saída pode chegar a 32 kHz.

• Microfone estéreo: os auditivos podem gravar áudio com microfones estéreo para melhorar o áudio espacial.

• Suporte ao perfil de acesso para aparelhos auditivos (HAP, na sigla em inglês): o HAP oferece aos usuários maior acessibilidade e uso do que os protocolos ASHA anteriores. Os usuários podem usar os aparelhos auditivos para ligações e aplicativos VoIP.

• Suporte ao protocolo Enhanced Attribute (EATT, na sigla em inglês): o EATT permite que os desenvolvedores enviem vários comandos de uma só vez para os dispositivos auditivos pareados.

Principais cenários

Há quatro categorias principais de casos de uso:

1. Conversacional: os aplicativos de discagem e VoIP que exigem roteamento de comunicação de baixa latência oferecem áudio de alta qualidade e menos uso da bateria.

2. Jogos: o microfone simultâneo e a reprodução de alta fidelidade permitem que os jogos transmitam áudio de alta qualidade para os wearables. Um app de jogos pode acessar a entrada de áudio BLE quando um jogo ativa o microfone Bluetooth como pronto para uso. Em seguida, quando um jogador inicia uma conversa ao vivo com outro jogador, o app do jogo pode usar os dados do microfone sem atraso.

3. Mídia: aplicativos de mídia podem configurar o dispositivo preferido do gerenciador de áudio. O usuário pode substituir isso mudando o dispositivo preferido nas configurações do sistema.

4. Acessibilidade: os aparelhos auditivos compatíveis com áudio BLE agora podem usar o microfone, permitindo que os usuários usem continuamente os aparelhos auditivos para uma chamada.

APIs e métodos de áudio BLE

As APIs e os métodos a seguir são necessários para oferecer suporte aos áudios BLE ouviáveis:

AudioManager

• setCommunicationDevice() seleciona o dispositivo de áudio que será usado para casos de uso de comunicação, por exemplo, chamadas de voz ou videochamadas. Esse método pode ser usado por aplicativos de chat por voz ou vídeo para selecionar um dispositivo de áudio diferente daquele selecionado por padrão pela plataforma. Esta API substitui as seguintes APIs descontinuadas: startBluetoothSco(), stopBluetoothSco() e setSpeakerphoneOn().
• clearCommunicationDevice() é chamada depois que o app termina uma chamada ou sessão para garantir que o usuário tenha uma ótima experiência ao alternar entre diferentes aplicativos.

BluetoothProfile

• BluetoothLeAudio controla o serviço Bluetooth pelo objeto proxy.

Telecom InCallService

• InCallService#requestCallEndpointChange() substitui as APIs InCallService.setAudioRoute() e InCallService.requestBluetoothAudio() descontinuadas para permitir que os apps solicitem o roteamento de áudio para um CallEndpoint específico. Os clientes não podem definir o próprio CallEndpoint ao solicitar uma mudança. Em vez disso, o novo endpoint precisa ser um dos válidos fornecidos por InCallService.onAvailableCallEndpointsChanged(java.util.List).
• CallEndpoint.TYPE_BLUETOOTH direciona o fluxo de áudio por Bluetooth.
• As APIs InCallService mencionadas acima foram projetadas para serem usadas pelo app de telefone padrão em um smartphone Android ou outras plataformas de chamada, como wearables, automóveis ou outros dispositivos Bluetooth que podem influenciar o roteamento de áudio.

Controle de chamadas de telecomunicações

• A nova classe CallControl foi introduzida no nível 34 da API para substituir Connection e ConnectionService apenas para aplicativos VoIP.
• CallControl.requestCallEndpointChange() também solicita uma mudança de CallEndpoint. Essa API substitui as APIs Connection.requestBluetoothAudio() e Connection.setAudioRoute() descontinuadas.
• Além das APIs atualizadas da plataforma de telecomunicações, a biblioteca de telecomunicações do Jetpack é altamente recomendada ao criar apps de chamada de voz e/ou vídeo. Essa biblioteca pode simplificar bastante o processo de integração e melhorar as chamadas VoIP em todas as plataformas Android.

Informações do dispositivo de áudio

• AudioDeviceInfo.TYPE_BLE_HEADSET descreve o tipo de dispositivo de áudio como um dispositivo LEA. Usado para identificar se o dispositivo auditivo é um dispositivo LEA.

Gravador de áudio

• setPreferredDevice() define o dispositivo preferencial para o roteamento de áudio. O usuário pode substituir essa configuração nas configurações do sistema.

Adaptador Bluetooth

• isLeAudioSupported() retornará se o hardware da plataforma oferecer suporte a LEA.
• isLeAudioBroadcastSourceSupported() retornará se o hardware da plataforma oferecer suporte a LEA.

Guias com base no caso de uso

Confira abaixo as diretrizes para implementar a LEA com base em casos de uso específicos.

Aplicativos de comunicação por voz

Os aplicativos de comunicação de voz têm a opção de gerenciar o roteamento de áudio e o estado do dispositivo gerenciando automaticamente o estado deles ou usando a API Telecom, que faz o roteamento de áudio e a lógica de estado para você.

• Autogerenciado: para aplicativos que usam startBluetoothSco(), stopBluetoothSco() e setSpeakerphoneOn() ou querem gerenciar automaticamente o estado do roteamento de áudio, siga o guia de chamadas autogerenciados do Gerenciador de áudio.

• Gerenciado: use a biblioteca Telecom Jetpack ou as APIs da plataforma Telecom para criar um aplicativo de ligações de áudio ou vídeo.

Essas duas soluções permitem controlar o roteamento de áudio e alternar entre dispositivos Bluetooth de maneira rápida e fácil. Para mais informações, consulte o Guia de chamadas gerenciadas de telecomunicações.

Aplicativos de gravação de áudio

• Gravador de mídia: ao gravar áudio usando o Gravador de mídia, agora você pode gravar em estéreo se o Bluetooth detectável for compatível com LEA. Confira o guia de gravação de áudio.

Recomendações de fone de ouvido LE Audio (LEA)

À medida que mais headsets de RA são lançados, descobrimos problemas em testes reais que prejudicam a experiência do usuário. A especificação não abrange todos esses problemas. A tabela a seguir fornece uma lista de recomendações que os fabricantes de fones de ouvido LEA precisam seguir para melhorar a experiência completa dos usuários do Android.

Descrição	Contexto
Suporte à Derivação de chaves entre transportes (CTKD, na sigla em inglês) para fones de ouvido de modo duplo: Suporte à derivação de chaves para pareamento de clássico para LE e pareamento LE para clássico.	A maioria dos novos headsets de LEA funcionará no modo duplo até que a participação de mercado de dispositivos de origem de LEA aumente. É importante que os usuários possam parear os fones de ouvido de modo duplo sem problemas e configurar os dois modos. Isso também é importante para o Pareamento rápido do Google.
Ofereça suporte a avisos direcionados (TAs, na sigla em inglês) se quiser que os fones de ouvido LEA se conectem com segurança aos dispositivos de origem. Os fones de ouvido LE Audio precisam usar TAs para solicitar uma conexão de entrada dos dispositivos centrais. Será adicionado ao próximo SIG de BT.	Ao contrário do modelo de paginação de BR/EDR, em que uma conexão pode ser iniciada pelo telefone ou pelo fone de ouvido, uma conexão em LEA precisa ser iniciada pelo dispositivo central. Atualmente, muitos headsets não usam TAs, o que significa que o dispositivo central pode não conseguir se reconectar ao periférico sem adicioná-lo a uma lista de permissões. No entanto, uma solução alternativa de lista de permissões pode impedir que o headset se conecte a um dispositivo central diferente. Portanto, é importante que os headsets de LEA ofereçam suporte a TAs corretamente para que o dispositivo central possa se reconectar de maneira confiável sem soluções alternativas que possam interromper conexões multiponto.
Melhoria na descoberta de fones de ouvido de modo duplo O fone de ouvido principal: componente BR/EDR precisa anunciar usando o endereço público e ativar a consulta e a verificação de página com o nome disponível pelo EIR, além de definir o bit de áudio LE 14 como 1 nas classes de serviço principais da classe de dispositivo (CoD). Fone de ouvido principal - Componente LE: o fone de ouvido principal precisa exibir uma publicidade conectável e detectável (seja limitada ou geral) usando o mesmo endereço público que o componente BR/EDR e o mesmo nome local completo que o componente BR/EDR, com a categoria de aparência definida como uma categoria de aparência apropriada que corresponde ao tipo de dispositivo remoto com a expectativa de que o dispositivo central usará essas informações para ajustar as políticas de roteamento de áudio. Auricular secundário: somente LE: o fone de ouvido secundário precisa executar um anúncio conectável e não detectável com a categoria de aparência definida como uma categoria de aparência adequada que corresponda ao tipo de dispositivo remoto, com a expectativa de que o dispositivo central use essas informações para ajustar a interface e as políticas de roteamento de áudio. Os fones de ouvido precisam eleger dinamicamente um líder do grupo CSIP para ser o dispositivo principal. Se o fone de ouvido tiver modo duplo, o dispositivo principal também precisa ter modo duplo para garantir que as funcionalidades LE e Classic funcionem corretamente após o pareamento.	Isso evita que fones de ouvido LEA de modo duplo apareçam como entradas duplicadas nas configurações do Bluetooth, o que pode confundir os usuários e comprometer a experiência de pareamento do LEA. A eleição de líder dinâmica é especialmente importante para dispositivos de modo duplo pareados incrementalmente. Por exemplo, se apenas um fone de ouvido estiver disponível no pareamento inicial, ele vai se apresentar como um dispositivo de modo duplo. Quando um usuário parear com o segundo fone de ouvido mais tarde, ele só vai precisar parear com o componente LE, e o CSIP vai garantir que eles estejam agrupados no Android. O endereço de identidade é recomendado durante o pareamento porque o componente BR/EDR já expõe o endereço público do dispositivo aos dispositivos próximos.
Compatibilidade com o Protocolo de atributo avançado (EATT, na sigla em inglês).	Reduz a latência do pareamento e da conexão.
Suporte a armazenamento em cache robusto do GATT.	Reduz a latência de conexão, especialmente para fones TWS.
Suporte para subclassificação de conexão.	Permite uma programação de pacotes mais flexível e possíveis economias de bateria.
Verifique se, durante o pré-processamento e o pós-processamento para reprodução e captura, o pipeline de processamento de sinal pode operar em 16, 24, 32 e 48 kHz, além de oferecer suporte a frequências mais altas.	Aproveita as taxas de amostragem mais altas com suporte para caminhos de captura de chamadas LEA ou VoIP e reprodução de mídia.
Suporte a LE Power Control	Melhor gerenciamento de energia

Suporte a tipos de contexto

Descrição	Contexto
Use todos os tipos de contexto especificados em Números atribuídos 6.12.3, a menos que o fone de ouvido não ofereça suporte a um determinado tipo de contexto.	Por exemplo, se o tipo de contexto "Jogo" não tiver suporte, o Android vai enviar sons de jogo. Em particular, o tipo de contexto "Não especificado" não significa "qualquer tipo de contexto" e não abrange tipos de contexto sem suporte.
Quando o dispositivo central interage com o ASCS do dispositivo periférico, o periférico precisa se conectar ao MCS e ao TBS do dispositivo central. O dispositivo central nem sempre usa o áudio LE como a rota de streaming porque pode voltar a usar A2DP ou HFP. O dispositivo periférico pode usar a interação ASCS como uma indicação de que o dispositivo central vai usar áudio LE para streaming. Alguns exemplos de interações com o ASCS são ler, gravar e se registrar para notificações.