Áudio Bluetooth de baixa energia

O áudio Bluetooth Low Energy (LEA, na sigla em inglês) garante que os usuários recebam áudio de alta fidelidade sem sacrificar a duração da bateria e permite que eles alternem entre diferentes casos de uso. O Android 13 (nível 33 da API) inclui suporte integrado ao LEA.

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

Casos de uso

Talvez você queira integrar o LEA para os seguintes casos de uso:

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

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

• Suporte ao codec de áudio LC3: esse é o codec de áudio padrão e substitui o codec SBC usado para A2DP (mídia) e mSBC em 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 aparelhos auditivos podem gravar áudio com microfones estéreo para melhorias de áudio espacial.

• Suporte ao perfil de aparelho auditivo (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 chamadas telefônicas e aplicativos VoIP.

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

Principais cenários

Há quatro categorias principais de casos de uso:

1. Conversacional: aplicativos de discador e VoIP que exigem roteamento de comunicação de baixa latência oferecem áudio de alta qualidade e menor 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 aparelhos auditivos. Um app de jogos pode acessar a entrada de áudio BLE quando um jogo arma o microfone Bluetooth como pronto para uso. Em seguida, quando um jogador inicia uma conversa ao vivo com outro jogador, o app de jogos pode usar os dados do microfone sem atraso.

3. Mídia: os aplicativos de mídia podem definir 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 que oferecem suporte ao áudio BLE agora podem usar o microfone, permitindo que os usuários usem os aparelhos auditivos continuamente 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 a aparelhos auditivos de áudio BLE:

AudioManager

• setCommunicationDevice() seleciona o dispositivo de áudio que deve ser usado para casos de uso de comunicação, por exemplo, chamadas de voz ou vídeo. Esse método pode ser usado por aplicativos de chat de voz ou chat por vídeo para selecionar um dispositivo de áudio diferente daquele selecionado por padrão pela plataforma. Essa API substitui as seguintes APIs obsoletas: startBluetoothSco(), stopBluetoothSco(), e setSpeakerphoneOn().
• clearCommunicationDevice() é chamado 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 obsoletas InCallService.setAudioRoute() e InCallService.requestBluetoothAudio() para permitir que os apps solicitem o roteamento de áudio para um CallEndpointespecífico. Os clientes não devem definir o próprio CallEndpoint ao solicitar uma mudança. Em vez disso, o novo endpoint precisa ser um dos endpoints válidos fornecidos por InCallService.onAvailableCallEndpointsChanged(java.util.List).
• CallEndpoint.TYPE_BLUETOOTH direciona o stream de áudio pelo Bluetooth.
• Essas APIs InCallService mencionadas acima foram projetadas para serem usadas pelo app de telefone padrão em um smartphone Android ou outras superfícies de chamada, como wearables, automóveis ou outros dispositivos Bluetooth que podem influenciar o roteamento de áudio.

Telecom CallControl

• 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 CallEndpoint mudança. Essa API substitui as APIs obsoletas Connection.requestBluetoothAudio() e Connection.setAudioRoute().
• Além das APIs atualizadas da plataforma Telecom, a biblioteca Telecom Jetpack é altamente recomendada ao criar aplicativos de chamada de voz e/ou vídeo. Essa biblioteca pode simplificar muito o processo de integração e melhorar as chamadas VoIP em todas as superfícies do 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 preferido para o roteamento de áudio. O usuário pode substituir isso nas configurações do sistema.

Adaptador Bluetooth

• isLeAudioSupported(): retorna uma @BluetoothStatusCodesconstante (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED ou um código de erro) indicando se o hardware do dispositivo oferece suporte ao LE Audio.
• isLeAudioBroadcastSourceSupported(): Retorna uma constante @BluetoothStatusCodes (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED ou um código de erro) indicando se o hardware do dispositivo oferece suporte à fonte de transmissão de LE Audio.

Guias com base no caso de uso

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

Aplicativos de comunicação por voz

Os aplicativos de comunicação por voz podem gerenciar o roteamento de áudio e o estado do dispositivo gerenciando o próprio estado ou usando a API Telecom, que faz o roteamento de áudio e a lógica de estado para você.

• Gerenciado por conta própria: para aplicativos que estão usando startBluetoothSco(), stopBluetoothSco(), e setSpeakerphoneOn() ou querem gerenciar o estado de roteamento de áudio por conta própria, siga o guia de chamadas gerenciadas por conta própria do gerenciador de áudio.

• Gerenciado: use a biblioteca Telecom Jetpack ou as APIs da plataforma Telecom para criar um aplicativo de chamada 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 da Telecom.

Aplicativos de gravação de áudio

• Gravador de mídia: ao gravar áudio usando o gravador de mídia, agora é possível gravar em estéreo se o aparelho auditivo Bluetooth oferecer suporte ao LEA. Confira o guia de gravação de áudio.

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

À medida que mais fones de ouvido LEA 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 de ponta a ponta dos usuários do Android.

Descrição	Contexto
Suporte à derivação de chaves de transporte cruzado (CTKD, na sigla em inglês) para fones de ouvido de modo duplo: Suporte à derivação de chaves para pareamento clássico para LE e LE para clássico.	A maioria dos novos fones de ouvido LEA será de modo duplo até que a participação de mercado do dispositivo de origem LEA cresça. É importante que os usuários possam parear os fones de ouvido de modo duplo e configurar os dois transportes. Isso também é importante para o Google Fast Pair.
Ofereça suporte a anúncios segmentados (TAs, na sigla em inglês) se quiser que seus fones de ouvido LEA se reconectem de forma confiável aos dispositivos de origem. Os fones de ouvido de áudio LE precisam usar TAs para solicitar uma conexão recebida dos dispositivos centrais. Será adicionado ao próximo BT SIG.	Ao contrário do modelo de paginação do BR/EDR, em que uma conexão pode ser iniciada pelo smartphone ou pelo fone de ouvido, uma conexão no LEA precisa ser iniciada pelo dispositivo central. Atualmente, muitos fones de ouvido não usam TAs, o que significa que o dispositivo central talvez não consiga 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 fone de ouvido se conecte a um dispositivo central diferente. Portanto, é importante que os fones de ouvido LEA ofereçam suporte adequado a TAs para que o dispositivo central possa se reconectar de forma confiável sem soluções alternativas que possam interromper conexões multiponto.
Descoberta otimizada para 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 e definir o bit 14 de áudio LE como 1 nas classes de serviço principais da classe de dispositivo (CoD, na sigla em inglês). Fone de ouvido principal – componente LE: o fone de ouvido principal precisa realizar um anúncio conectável e detectável (limitado ou geral) usando o mesmo endereço público do componente BR/EDR e o mesmo nome local completo do componente BR/EDR, 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 as políticas de interface e roteamento de áudio. Fone de ouvido secundário – somente LE: o fone de ouvido secundário precisa realizar 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 as políticas de interface e 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 for de modo duplo, o dispositivo principal precisa ser de modo duplo para garantir que as funcionalidades LE e clássicas funcionem corretamente após o pareamento.	Isso impede que os fones de ouvido LEA de modo duplo apareçam como entradas duplicadas nas configurações de Bluetooth, o que pode confundir os usuários e comprometer a experiência de pareamento LEA. A eleição dinâmica de líder é especialmente importante para dispositivos de modo duplo que são pareados incrementalmente. Por exemplo, se apenas um fone de ouvido estiver disponível no pareamento inicial, ele precisará se apresentar como um dispositivo de modo duplo. Quando um usuário pareia com o segundo fone de ouvido mais tarde, eles só precisam parear com o componente LE, e o CSIP vai garantir que eles sejam 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 a dispositivos próximos.
Suporte ao protocolo de atributo aprimorado (EATT, na sigla em inglês).	Reduz a latência de pareamento e conexão.
Suporte ao armazenamento em cache GATT robusto.	Reduz a latência de conexão, especialmente para fones de ouvido TWS.
Suporte à subclassificação de conexão.	Permite um agendamento de pacotes mais flexível e possível economia de bateria.
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 ou VoIP e reprodução de mídia LEA.
Suporte ao controle de energia LE	Melhor gerenciamento de energia

Suporte ao tipo 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 for compatível, o Android vai enviar sons de jogos. Em particular, observe que o tipo de contexto "Não especificado" não significa "qualquer tipo de contexto" e não abrange tipos de contexto não compatíveis.
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 rota de streaming porque ele pode voltar a usar A2DP ou HFP. O dispositivo periférico pode usar a interação ASCS como uma indicação de se o dispositivo central vai usar o áudio LE para streaming. Alguns exemplos de interações ASCS são leitura, gravação e registro para notificação.

Observação: de acordo com a especificação, os fones de ouvido podem remover tipos de contexto dos tipos de contexto disponíveis a qualquer momento e para todos os dispositivos conectados, mesmo um dispositivo que esteja transmitindo um determinado tipo de contexto. Recomendamos que o fone de ouvido não remova o tipo de contexto de streaming atual dos tipos de contexto disponíveis no dispositivo que está transmitindo esse tipo de contexto.