Áudio Bluetooth de baixa energia

O Bluetooth de baixa energia (LEA, na sigla em inglês) garante que os usuários possam receber áudio de alta fidelidade sem sacrificar a duração da bateria e permite alternar facilmente entre diferentes casos de uso. O Android 13 (nível 33 da API) inclui suporte integrado para LEA.

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

Casos de uso

É recomendável integrar o LEA aos seguintes casos de uso:

  • Compartilhamento de áudio: os usuários podem compartilhar simultaneamente vários streams de áudio com um ou mais dispositivos coletores 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 e, ao mesmo tempo, se conectar a transmissões públicas para fins de informação, entretenimento ou acessibilidade.

  • Compatibilidade com codec de áudio LC3: este é 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 uma alta qualidade de áudio na saída ao usar microfones. O Bluetooth clássico diminui 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 fones de ouvido podem gravar áudio com microfones estéreo para melhorias no áudio espacial.

  • Compatibilidade com perfil de aparelho auditivo (HAP): a HAP oferece aos usuários maior acessibilidade e uso do que os protocolos ASHA anteriores. Os usuários podem usar aparelhos auditivos para chamadas telefônicas e aplicativos VoIP.

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

Principais cenários

Há quatro categorias principais de casos de uso:

  1. Conversa: os aplicativos Telefone 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 escutas. Um app de jogo pode acessar a entrada de áudio BLE quando um jogo ativar o microfone Bluetooth como pronto para uso. Assim, quando um jogador inicia uma conversa ao vivo com um jogador, o app do jogo pode usar os dados do microfone sem atraso.

  3. Mídia: apps de mídia têm permissão para definir o dispositivo preferido do gerenciador de áudio. O usuário pode substituir isso alterando o dispositivo preferido nas configurações do sistema.

  4. Acessibilidade: aparelhos auditivos compatíveis com áudio BLE agora podem usar o microfone. Isso permite que os usuários usem continuamente os aparelhos auditivos durante uma ligação.

APIs e métodos de áudio BLE

As APIs e os métodos abaixo são necessários para oferecer suporte a escutas de áudio BLE:

Gerenciador de áudio

  • setCommunicationDevice() seleciona o dispositivo de áudio que será usado para casos de uso de comunicação, como ligações ou videochamadas. Esse método pode ser usado por aplicativos de chat por voz ou vídeo para selecionar um dispositivo de áudio diferente do selecionado por padrão pela plataforma. Essa API substitui as seguintes APIs descontinuadas: 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 apps.

BluetoothProfile

Serviço de telecomunicações em chamadas

Informações do dispositivo de áudio

Gravador de áudio

  • setPreferredDevice() define o dispositivo preferido para uso do roteamento de áudio. O usuário pode modificar isso nas configurações do sistema.

Adaptador Bluetooth

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 têm a opção de gerenciar o roteamento de áudio e o estado do dispositivo gerenciando o estado por conta própria ou usando a API Telecom, que faz o roteamento de áudio e a lógica de estado para você.

Apps 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 dispositivo Bluetooth compatível com LEA for compatível com 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 abaixo oferece 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
Compatibilidade com a Derivação de chaves entre transporte (CTKD, na sigla em inglês) para fones de ouvido duplos:
  • Compatibilidade com a derivação de chaves para pareamento clássico para LE e do LE para o clássico.
 A maioria dos novos fones de ouvido LEA vai ter modo duplo até que a participação de mercado do dispositivo de origem aumente. É importante que os usuários possam parear os fones de ouvido duplos sem problemas e configurar os dois meios de transporte. Isso também é importante para o Pareamento rápido do Google.

Ofereça suporte a Targeted Warnings (TAs) se quiser que seus fones de ouvido LEA se reconectem de maneira confiável aos dispositivos de origem.

Os fones de ouvido de áudio LE precisam usar TAs para solicitar uma conexão de entrada dos dispositivos centrais.

Será adicionado aos próximos BT SIG.

 Diferentemente do modelo de paginação da BR/EDR, em que uma conexão pode ser iniciada pelo smartphone ou pelo fone de ouvido, uma conexão na LEA precisa ser iniciada pelo dispositivo central. Atualmente, muitos fones de ouvido 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 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 tenham suporte aos TAs corretamente para que o dispositivo central possa se reconectar de forma confiável, sem soluções alternativas que possam interromper as conexões multipontos.
Detecção otimizada para fones de ouvido no modo duplo
  • O fone de ouvido principal: componente BR/EDR precisa anunciar usando o endereço público e permitir a consulta e a verificação de página com o nome disponível pelo EIR, além de definir o bit 14 do áudio de LE como 1 nas Principais classes de serviço do dispositivo (CoD, na sigla em inglês).
  • Fone principal - componente LE: o fone de ouvido principal precisa veicular um anúncio conectável e detectável (limitado ou geral) usando o mesmo endereço público que o 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 áudio e o dispositivo central.
  • Fone de ouvido secundário: somente LE: o fone de ouvido secundário precisa exibir 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 roteamento de áudio e IU.

    Os fones de ouvido precisam eleger dinamicamente um líder do grupo do CSIP para ser o dispositivo principal. Se o fone de ouvido estiver no modo duplo, o dispositivo principal vai precisar estar no modo duplo para garantir que as funcionalidades LE e Classic funcionem corretamente após o pareamento.

 Isso evita que os fones de ouvido LEA no 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âmico é especialmente importante para dispositivos de modo duplo pareados de forma incremental. Por exemplo, se apenas um fone estiver disponível no pareamento inicial, ele vai se apresentar como um dispositivo de modo duplo. Quando um usuário faz o pareamento com o segundo fone de ouvido, só é necessário fazer isso 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 a dispositivos próximos.
Suporte ao Protocolo de atributo avançado (EATT, na sigla em inglês). Reduz a latência do pareamento e da conexão.
Compatibilidade com armazenamento em cache robusto de GATT. Reduz a latência da conexão, especialmente para fones TWS.
Ofereça suporte à subclassificação de conexão. Permite uma programação de pacotes mais flexível e uma possível economia de bateria.
Verifique se, durante o pré e o pós-processamento, para reprodução e captura, o pipeline de processamento de sinal pode operar a 16, 24, 32 e 48 kHz, além de oferecer suporte a frequências mais altas. Aproveita as taxas de amostragem mais altas compatíveis com caminhos de captura de LEA ou VoIP e reprodução de mídia.
Suporte ao LE Power Control Melhor gerenciamento de energia

Suporte ao tipo de contexto

Descrição Contexto
Use todos os tipos de contexto especificados em Assigned Numbers 6.12.3, a menos que o fone de ouvido não seja explicitamente compatível com um determinado tipo de contexto. Por exemplo, se o tipo de contexto "Jogo" não tiver suporte, o Android vai enviar sons de jogos. Especificamente, observe que o tipo de contexto "Não especificado" não significa "qualquer tipo de contexto" nem abrange tipos de contexto incompatíveis.

Quando o dispositivo central interage com o ASCS do dispositivo periférico, ele precisa se conectar ao MCS e TBS do dispositivo central.

O dispositivo central nem sempre usa o áudio LE como rota de streaming porque pode voltar a usar A2DP ou HFP. O dispositivo periférico pode usar a interação do ASCS como indicação se o dispositivo central vai usar áudio de baixo consumo para streaming.

Alguns exemplos de interações do ASCS são leitura, gravação e registro para notificação.