Áudio Bluetooth de baixa energia

O áudio de baixa energia (LEA, na sigla em inglês) com Bluetooth de baixa energia (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 alternar com facilidade entre diferentes casos de uso. O Android 13 (nível 33 da API) inclui suporte integrado à LEA.

A maioria dos headsets de LEA vai operar em modo duplo até que a participação de mercado de dispositivos de origem de LEA aumente. Os usuários precisam conseguir parear e configurar os dois transportes nos fones de ouvido de modo dual.

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 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 saída de áudio 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 atingir 32 kHz.

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

  • Compatibilidade com o perfil de aparelhos auditivos (HAP): o HAP oferece aos usuários maior acessibilidade e uso do que os protocolos ASHA anteriores. Os usuários podem utilizar 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 auditáveis pareados.

Principais cenários

Há quatro categorias principais de casos de uso:

  1. Conversacional: os aplicativos Telefone 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 façam streaming de áudio de alta qualidade para os ouvintes. Um app de jogos pode acessar a entrada de áudio BLE quando o jogo ativa o microfone Bluetooth como pronto para uso. Assim, quando um jogador iniciar uma conversa ao vivo com outra pessoa, o app de jogo poderá 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: aparelhos auditivos com suporte a áudio BLE agora podem usar o microfone, permitindo o uso contínuo dos 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:

Gerenciador de áudio

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

BluetoothProfile

Serviço de ligações em chamadas de telecomunicações

Informações do dispositivo de áudio

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

Gravador de áudio

  • O 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 de voz têm a opção de gerenciar o roteamento de áudio e o estado do dispositivo 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 com o Gravador de mídia, agora você pode gravar em estéreo se o dispositivo Bluetooth auditável for compatível com LEA. Confira o Guia de gravação de áudio.

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

Conforme mais headsets de LEA são lançados, descobrimos problemas no mundo real testes que prejudicam a experiência do usuário. A especificação não abrange todos sobre esses problemas. A tabela a seguir fornece uma lista de recomendações que Os fabricantes de headsets de LEA devem seguir para melhorar a experiência completa dos Android.

Descrição Contexto
Oferecer suporte à derivação de chaves de transporte cruzado (CTKD, na sigla em inglês) para Fones de ouvido dual modo:
  • Suporte à derivação de chaves para pareamento clássico-LE e Pareamento LE para clássico.
 A maioria dos novos headsets de LEA vai operar em modo duplo até que o dispositivo de origem da LEA a participação de mercado aumenta. É importante que os usuários possam parear os para os fones de ouvido dual-mode e configurar os dois meios de transporte. Isso é também importante para o Pareamento rápido do Google.

Ofereça compatibilidade com anúncios segmentados (TAs, na sigla em inglês), se você quiser para se reconectar aos dispositivos de origem de forma confiável.

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

Serão adicionados aos próximos BT SIG.

 Ao contrário do modelo de paginação BR/EDR, em que uma conexão pode ser iniciada pelo smartphone ou pelo fone de ouvido, é necessário ter uma conexão de LEA é iniciado pelo dispositivo central. Atualmente, muitos fones de ouvido não usam os TAs, o que significa que o dispositivo central pode não conseguir se reconecta ao periférico sem adicioná-lo a uma lista de permissões. No entanto, uma solução de lista de permissões pode impedir que o fone de ouvido conectando-se a um dispositivo central diferente. Por isso, é importante para que headsets de LEA ofereçam suporte a TAs adequadamente, de modo que o dispositivo central possam se reconectar de forma confiável sem soluções alternativas que possam falhar multiponto.
Detecção otimizada para fones de ouvido dual modo
  • Fone de ouvido principal: componente BR/EDR precisa ser anunciado usando seu endereço público e ativar consultas e verificação de página com seu disponível no EIR e defina o bit 14 como 1 do LE Audio na Principais classes de serviço de classe de dispositivo (CoD).
  • Fone de ouvido principal - Componente LE: o fone de ouvido principal deve realizar um teste Connectable e Detectable (Limitado ou geral) publicidade com o mesmo endereço público que o BR/EDR componente e o mesmo nome local completo que o BR/EDR com a categoria "Aparência" definida como um A categoria de aparência que corresponde ao tipo de dispositivo remoto com o expectativa de que o dispositivo central usará essas informações para ajustar as políticas de roteamento da interface e do áudio.
  • Fone de ouvido secundário - somente LE: o fone de ouvido secundário deve veicular um anúncio que pode ser conectado e não detectável com sua Categoria de aparência definida como uma categoria de aparência apropriada que corresponda ao tipo de dispositivo remoto com a expectativa de que dispositivo central usará essas informações para ajustar sua interface e políticas de roteamento de áudio

    Os fones de ouvido precisam eleger dinamicamente um líder do CSIP seja o dispositivo principal. Se o fone de ouvido estiver no modo duplo, o dispositivo principal deve ser dual modo para garantir que tanto o LE quanto o Classic funcionam corretamente após o pareamento.

 Isso evita que fones de ouvido LEA de modo duplo apareçam como duplicados. entradas nas configurações de Bluetooth, o que pode confundir os usuários e comprometer a experiência de pareamento de LEA.

A eleição dinâmica do líder é especialmente importante para modelos dual-mode. de dispositivos pareados de modo incremental. Por exemplo, se apenas um fone de ouvido está disponível no pareamento inicial, então ele deve se apresentar como um dispositivo de modo dual. Quando um usuário parear com o segundo fone, eles só precisam ser pareados com o componente LE, e o CSIP vai garantir eles são agrupados no Android.

O endereço de identidade é recomendado durante o pareamento porque o BR/EDR componente já expõe o endereço público do dispositivo para dispositivos próximos dispositivos.
Compatibilidade com o Protocolo de atributo avançado (EATT, na sigla em inglês). Reduz a latência do pareamento e da conexão.
Ofereça suporte ao armazenamento em cache robusto GATT. Reduz a latência da conexão, especialmente para fones de ouvido TWS.
Suporte à subclassificação da conexão. Permite programação de pacotes mais flexível e potencial de bateria. economia de energia.
Durante o pré e pós-processamento, os controles de reprodução e captura, o pipeline de processamento de sinal pode operar em 16, 24, 32 e 48 kHz, além de suporte a frequências mais altas. Aproveita as taxas de amostragem mais altas compatíveis com chamadas de LEA. ou VoIP, além da reprodução de mídia.
Suporte ao LE Power Control Melhor gerenciamento de energia

Suporte a tipos de contexto

Descrição Contexto
Usa todos os tipos de contexto especificados em Números atribuídos 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 contexto digite "Jogo" não for compatível, o Android vai enviar sons de jogos. Observe que o valor "Não especificado" contexto type não significa "qualquer tipo de contexto" e não cobre os recursos tipos de contexto.

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 pode usar LE Audio como streaming do aplicativo porque ele pode voltar a usar A2DP ou HFP. O periférico dispositivo pode usar a interação ASCS para indicar se o servidor o dispositivo vai usar LE Audio para fazer streaming.

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