Manual do usuário do app LE Audio Validator

Esta página é específica para a versão LE Audio do app Validator. Consulte a página do app Validator para alternar o áudio para receber ajuda sobre a versão de alternância de áudio do app Validator.

Configuração

Para ativar os testes no app Validador:

  • Verifique se o dispositivo tem a versão 23.37.xx ou mais recente do GmsCore.
  • Verifique se os e-mails de teste fazem parte do grupo de teste do parceiro do Par rápido.
    • Pode levar de 6 a 24 horas para que os e-mails e smartphones recém-registrados sincronizem as permissões.
    • Fazer login e sair da Conta do Google associada também pode acionar uma sincronização imediata.

A versão do GMS pode ser encontrada na página de informações do app para o Google Play Services.

Dispositivos necessários

O teste requer pelo menos dois (2) smartphones:

  • Um com o Android 15 (U) e suporte ao LE Audio (por exemplo, um Pixel 7)
  • Um com o Android 6-13 (M-T), que não oferece suporte ao LE Audio.
    • Os dispositivos somente dados precisam usar apenas um desses smartphones.

Como se conectar ao perfil de áudio de baixa energia no Android 15 (V)

O áudio Bluetooth de baixa energia não é ativado de forma nativa no Android 15 (V). Para ativar essa opção:

  • Acesse a página "Opções do desenvolvedor" no smartphone.
    • Para ativar as Opções do desenvolvedor:
    • Navegue até Configurações > Sistema > Sobre o dispositivo > Número da versão.
    • Toque em "Número da versão" sete vezes.
  • Desative a opção "Desativar áudio Bluetooth LE".
  • Ative a opção "Ignorar lista de permissões de áudio Bluetooth LE".
  • Reinicie o smartphone.

Isso mostra as chaves de LEA na página "Opções do desenvolvedor".

Como ativar os testes de BLE para dispositivos somente de dados

O app Validador vai mostrar o menu de teste somente de dados se o ID do modelo do dispositivo tiver a opção "Conexão somente de dados" selecionada no Device Console. Observe que nem todos os tipos de dispositivo têm essa opção. O menu de teste para esse modo é mostrado abaixo:

O app atualiza automaticamente a lista de testes de um dispositivo somente de dados quando a chave é ativada.

Como ativar a especificação BLE e os testes de BT clássico para dispositivos sem suporte ao áudio LE

Os testadores precisam ativar a opção "Ativar teste de especificação LE" para ver os testes BLE. O testador precisa confirmar que o dispositivo em teste não oferece suporte ao LE Audio para ver os testes do BT Classic, conforme mostrado:

A lista de testes só é atualizada depois que o testador confirma que o dispositivo não oferece suporte ao LE Audio.

Ativar a especificação BLE e os testes de áudio LE em um smartphone Pixel com o Android 14 (U) ou mais recente

Os testadores precisam ativar a opção "Ativar teste de especificação LE" para ver os testes BLE. Em seguida, os testadores precisam confirmar os comandos restantes para acessar a tela de teste. O app vai preencher automaticamente os testes disponíveis para essa configuração, incluindo os testes de áudio LE, como mostrado:

O app pode preencher a lista de testes correta porque os smartphones Pixel são uma configuração conhecida.

Ativar a especificação BLE e os testes de áudio LE em um smartphone Pixel com o Android 13 (T) ou versões anteriores

Os testadores precisam ativar a opção "Ativar teste de especificação LE" para ver os testes BLE. Em seguida, os testadores precisam confirmar os comandos restantes para acessar a tela de teste. O app vai preencher automaticamente os testes disponíveis para essa configuração, incluindo os testes clássicos de BT, como mostrado:

O app pode preencher a lista de testes correta porque os smartphones Pixel são uma configuração conhecida.

Ativar a especificação BLE e os testes de LE Audio em um smartphone que não seja Pixel com suporte a LE Audio

Os testadores precisam ativar a opção "Ativar teste de especificação LE" para ver os testes BLE. Os testadores precisam informar ao app validador se o smartphone e o dispositivo (buscador) de teste são compatíveis com conexões com o LE Audio. O app não pode saber essas informações para smartphones que não são Pixel, já que a compatibilidade com o recurso é controlada pelo OEM. Selecionar a compatibilidade com LE Audio no pop-up ativa os testes de LE Audio, como mostrado:

Os testes de áudio de baixo consumo são mostrados se o usuário confirmar que o smartphone não Pixel oferece suporte a esse recurso.

Ativar a especificação BLE e os testes de áudio LE em um smartphone que não seja Pixel com suporte a A2DP e HFP

Os testadores precisam ativar a opção "Ativar teste de especificação LE" para ver os testes BLE. Os testadores precisam informar ao app validador se o smartphone e o dispositivo (buscador) de teste são compatíveis com conexões com o LE Audio. O app não pode saber essas informações para smartphones que não são Pixel, porque o suporte a recursos é controlado pelo OEM. A seleção do suporte A2DP + HFP no pop-up ativará os testes BT Classic, como mostrado:

Os testes do BT Classic são mostrados se o usuário selecionar o suporte a A2DP + HFP para o smartphone que não é Pixel.

Testes obrigatórios

Consulte a Seção de testes obrigatórios para saber quais testes são necessários para uma determinada versão do Par rápido e tipo de dispositivo. A tabela tem guias separadas para dispositivos somente de dados, smartphones com Android 13 ou versões anteriores e smartphones com Android 14 ou mais recente.

Verificação de UUID de serviço de áudio comum

Esse teste verifica se a propaganda conectável LE inclui o UUID do CAS, conforme exigido pelo Perfil de adaptador Bluetooth (BAP 1.0.1) e requisitos do Perfil de áudio comum.

Um teste bem-sucedido vai ficar assim:

Um teste bem-sucedido mostra os resultados de aprovação no registro.

Esse teste verifica se o provedor usa o tipo de endereço correto (dados de serviço do Fast Pair (0xFE2C)) ao anunciar durante as tentativas iniciais de pareamento (endereço de identidade) e de pareamento subsequente (RPA).

  • Os dispositivos que oferecem suporte à CTKD do Classic para o LE precisam anunciar o RPA durante o pareamento inicial.
  • Todos os outros dispositivos com suporte a CTKD de LE para Classic precisam anunciar o endereço de identidade durante o pareamento inicial.
  • Todos os dispositivos, independentemente do suporte ao CTKD, precisam anunciar o RPA durante o pareamento subsequente.

Um teste bem-sucedido vai ficar assim:

Um teste bem-sucedido mostra os resultados de aprovação no registro.

Testar mudanças no modo de especificação BLE

Alguns testes vão mudar quando a chave "Ativar testes de especificação LE" for ativada. Por exemplo, os testes "Battery Level Update" vão mudar para "Battery Level Update with LE audio connection" e "Battery Level Update with classic profile connection". Os testes modificados só vão aparecer nas respectivas versões do Android.

Qualquer teste que mude dessa forma precisa ser testado em dois smartphones para garantir a funcionalidade adequada, um sem LE Audio e outro com LE Audio. Para smartphones Pixel, isso significa testar em um smartphone com o Android 14 (U) ou mais recente e um smartphone com o Android 13 (T) ou anterior. Para telefones que não são Pixel, isso significa testar em um com áudio LE implementado e outro com apenas A2D + HFP.

Um exemplo da mudança:

O teste muda para o Audio LE no Android 14 ou mais recente, enquanto usa o BLE CLassic no Android 13 ou anterior.

Como fazer upload de resultados para o Device Console

Como enviar seus resultados

O botão "SUBMIT RESULT" (ENVIAR RESULTADO) apresenta um resumo dos resultados do teste, mas não envia os resultados para o Google.

O processo de envio começa pressionando o botão "SUBMIT RESULT".

Depois de analisar todos os resultados, pressione o botão "ENVIAR" na parte de baixo da página de resultados para enviar os resultados ao Google.

Os resultados são enviados depois de rolar até a parte de baixo da página de resultados e pressionar

Como conferir os resultados enviados no Device Console

Os resultados dos testes enviados podem ser encontrados no Nearby Console. As métricas de distância e de duração serão removidas dos casos de teste de comutação de áudio. Exemplo:

Os resultados dos testes são mostrados em uma tabela no Nearby Console.

Solução de problemas

Tente desativar e ativar o Bluetooth se todos os testes falharem.

O Bluetooth pode ser ativado e desativado no botão do menu suspenso.

Não receber KeyBasedPairingResponse

Se o pareamento for bem-sucedido, mas a mensagem de erro ainda aparecer como mostrado, provavelmente o problema é causado por uma versão antiga do núcleo do GMS. Verifique se o telefone foi configurado conforme descrito na seção de configuração.

As capturas de tela a seguir mostram como esse erro pode se manifestar em diferentes testes.

O app mostra um erro KeyBasedPairingResponse no teste de integração E2E. O app mostra um erro KeyBasedPairingResponse nos testes de pareamento automático e de pareamento automático subsequente.

Tipo KeyBasedPairingResponse incorreto

Isso pode acontecer porque o provedor enviou o tipo de mensagem errado. Um Seeker que ofereça suporte ao áudio LE precisa receber o tipo de mensagem 2, com todos os outros casos que recebem o tipo de mensagem 1.

As capturas de tela a seguir mostram como esse erro pode se manifestar em diferentes testes.

O app mostra um erro KeyBasedPairingResponseType no teste de integração E2E. O app mostra um erro KeyBasedPairingResponseType nos testes de pareamento automático e de pareamento automático subsequente.

KeyBasedPairingExtensionResponse Wrong Address Length

Isso pode ser causado pela escolha do tipo incorreto de suporte ao CSIP para um dispositivo de áudio LE. Os dispositivos com suporte a CSIP e LE Audio precisam receber um endereço de comprimento 2, e todos os outros casos precisam receber um endereço de comprimento 1.

As capturas de tela a seguir mostram como esse erro pode se manifestar em diferentes testes.

O app mostra um erro de comprimento de endereço KeyBasedPairingExtensionResponse no teste de integração E2E. O app mostra um erro de comprimento de endereço KeyBasedPairingExtensionResponse nos testes de pareamento automático e pareamento automático subsequente.

Erro de estado

Isso geralmente é causado por falha na conexão do provedor (dispositivo). Para dispositivos CSIP, é necessário que haja dois (2) eventos de conexão.

As capturas de tela a seguir mostram como esse erro pode se manifestar em diferentes testes.

O app mostra um erro de estado no teste de integração E2E. O app mostra um erro de estado nos testes de pareamento automático e de pareamento subsequente automático.

Evento de recebimento de conexão de apenas 1 endereço

Isso ocorre quando um Seeker recebe apenas um endereço de um dispositivo CSIP. Os dispositivos compatíveis com CSIP precisam fornecer dois endereços.

As capturas de tela a seguir mostram como esse erro pode se manifestar em diferentes testes.

O app mostra o único evento de recebimento de conexão de um erro de endereço nos testes de pareamento automático e de pareamento automático subsequente.

Não receber UUID

O Buscador não recebeu um UUID de qualquer tipo.

As capturas de tela a seguir mostram como esse erro pode se manifestar em diferentes testes.

O app mostra um erro de UUID no teste de integração E2E. O app mostra um erro de UUID nos testes de pareamento automático e de pareamento automático subsequente.

Não receber o UUID esperado

O Seeker espera receber um tipo específico de UUID para diferentes cenários. A tabela a seguir define qual deve ser o UUID nesses casos.

O provedor oferece suporte ao áudio LE O provedor não oferece suporte ao LE Audio O provedor é um dispositivo somente de dados
O Seeker não oferece suporte a BLE 110B ou 1108 ou 111E 110B ou 1108 ou 111E N/A
O Seeker oferece suporte a BLE 110B ou 1108 ou 111E 110B ou 1108 ou 111E 1812
O Seeker oferece suporte a BLE e LEA 184E 110B ou 1108 ou 111E 1812

As capturas de tela a seguir mostram como esse erro pode se manifestar em diferentes testes.

O app mostra o erro UUID inesperado no teste de integração E2E. O app mostra o erro UUID inesperado nos testes de pareamento automático e de pareamento automático subsequente.

Só receber o UUID correto de um endereço

Isso ocorre quando um Seeker recebe apenas um endereço de um dispositivo CSIP. Os dispositivos compatíveis com CSIP precisam fornecer dois endereços.

As capturas de tela a seguir mostram como esse erro pode se manifestar em diferentes testes.

O app mostra que só recebeu um erro de UUID no teste de integração E2E. O app mostra que só recebe um erro de UUID nos testes de pareamento automático e de pareamento subsequente automático.