Diretrizes de certificação da seleção de áudio

Preparação para a certificação

• Prepare dispositivos de teste.
  • Você vai precisar de cinco dispositivos Android.
    • Esses dispositivos precisam incluir:
      • Pelo menos um Android T (13) e um Android V (15).
      • Pelo menos um Samsung e um Pixel.
      • Por exemplo:
        • 1 OnePlus (Android 10).
        • 3 Samsung (Android 11, 12, 13).
        • 1 Pixel (Android 15).
  • Um dispositivo sem seleção de áudio:
    • Qualquer iPhone, PC, laptop com Bluetooth (BT) ou smartphone Android com o interruptor de áudio desativado.
      • É possível desativar a seleção de áudio na configuração de detalhes do dispositivo Bluetooth.
    • O caso de teste de multiponto (MP) 2.8 precisa de um dispositivo sem seleção de áudio, além dos cinco smartphones de teste.

• Participe do grupo de teste de chave de áudio com suas contas de teste para mostrar notificações de depuração nos smartphones de teste.

  • Isso também permite que o Google colete dados de teste pelo Google Analytics.

Clássico com A2DP+HFP

• Confira se todos os dispositivos Android têm a versão 23.xx.xx ou mais recente do GmsCore instalada.

BLE com LE Audio

• Pelo menos dois dos smartphones de referência precisam oferecer suporte ao LE Audio.
  • Por exemplo, um smartphone Samsung e um Pixel com suporte a LE Audio.
• Confira se todos os dispositivos Android têm a versão 24.33.xx ou mais recente do GmsCore instalada.

Critérios de certificação

• A taxa de sucesso da troca de destino precisa exceder 95% em todos os casos de teste.

• Em testes que exigem uma troca, a conexão do perfil e o estado ativo da troca precisam ser concluídos em até três segundos após acionar eventos de áudio em pelo menos 75% dos casos.

Clássico com A2DP+HFP

Os autotestes precisam ser realizados nas seguintes combinações:

• Smartphone A=Android S (12) + Smartphone B=Android T (13)
• Smartphone A=Android T (13) + Smartphone B=Android S (12)

BLE com LE Audio

Os autotestes precisam ser realizados nas seguintes combinações:

• Smartphone A: BT Classic, Smartphone B: BT Classic
• Smartphone A: LE Audio, Smartphone B: BT Classic
• Smartphone A: BT Classic, Smartphone B: LE Audio

Opcionalmente, os provedores que oferecem suporte a conexões Dual LE Audio precisam testar:

• Telefone A: LE Audio, Telefone B: LE Audio

Guia de teste

Preparação do dispositivo em teste (DUT)

• Verifique se o dispositivo Bluetooth não foi pareado anteriormente com nenhum smartphone conectado à Conta do Google de teste.
  • Se o dispositivo tiver sido pareado com a Conta do Google de teste, faça o seguinte para limpar o pareamento:
    • Nos dispositivos pareados:
      • Acesse as configurações de Bluetooth.
      • Escolha "Esquecer dispositivo".
      • Ative e desative o modo avião.
  • Verifique se a opção "Salvar dispositivos automaticamente" está ativada.
    • Essa chave fica DESLIGADA por padrão.
    • Essa opção pode ser encontrada em Configurações > Google > Dispositivos > Dispositivos salvos (um por DUT).
  • Coloque o dispositivo Bluetooth no modo de pareamento.
  • Parear o dispositivo Bluetooth inicial (A).
  • Parear dispositivos Bluetooth subsequentes com outros dispositivos (B, C, D etc.).

Escopo

• Todos os fones de ouvido executam testes nas várias guias do relatório de autoteste BT Classic ou BT LE Audio.
• Os fones de ouvido que oferecem suporte apenas ao modo SinglePoint (SP) executam o seguinte:
  • A guia "Generic_test".
• Os fones de ouvido com suporte ao modo MP executam o seguinte:
  • A guia "Generic_test".
  • A guia "Multipoint_only".
• Os fones de ouvido MP que podem ser alternados para o modo SP executam o seguinte:
  • A guia "Generic_test" com o MP desativado.
  • A guia "Generic_test" com MP ativado.
  • Guia "Multipoint_only" com MP ativado.

Como concluir o autoteste e o relatório de autoteste

• Faça uma cópia dos relatórios de autoteste do BT Classic ou do BT LE Audio.
• Execute todos os casos de teste pelo menos duas vezes.

• Os testes precisam ser executados da seguinte forma:

Clássico com A2DP+HFP

• O dispositivo B será o DUT principal.
  • Insira os detalhes do Dispositivo B nos campos "Phone" e "OS" na parte de cima do modelo.

Exemplo de caso de teste:

• Testar smartphones:

  • Dispositivo 1: Samsung (Android 13)
  • Dispositivo 2: Pixel (Android 12 ou 13) e outros.

• Testes executados:

  • Execução 1. Dispositivo A=Samsung S10+ (12), Dispositivo B=Pixel 7 Pro (13) Coluna D: Smartphone=Pixel 7 Pro, SO=Android 13
  • Execução 2. Dispositivo A=Pixel 7 Pro (13), Dispositivo B=Pixel 6(12) Coluna E: Telefone=Pixel 6, SO=Android 12

Exemplo de teste concluído no modelo de autoteste:

BLE com LE Audio

1. Dispositivo A=Android V (15) + Dispositivo B=Android T (13)
2. Dispositivo A=Android T (13) + Dispositivo B=Android V (15)
3. Dispositivo A=Android T (13) + Dispositivo B=Android S (12)
4. Dispositivo A=Android T (15) + Dispositivo B=Android V (15)
5. O dispositivo B será o DUT principal.
   • Insira os detalhes do Dispositivo B nos campos "Phone" e "OS" na parte de cima do modelo.

Exemplo de caso de teste:

• Testar smartphones:

  • Dispositivo 1: Samsung (Android 13)
  • Dispositivo 2: Pixel (Android 15) e outros.

• Testes executados:

  • [LEA+BT]: Dispositivo A= Pixel 8 (15), Dispositivo B=Pixel 7 Pro (13) Coluna D: Smartphone=Pixel 7 Pro, SO=Android 13
  • [BT+LEA]: Dispositivo A=Pixel 7 (13), Dispositivo B=Pixel 8 (Android 15) coluna E: Smartphone=Pixel 8, SO=Android 15
  • [BT+BT]: Dispositivo A=Pixel 7 pro (13), Dispositivo B=Samsung S10+ (12) coluna E: Telefone=Samsung S10+, SO=Android 12
  • [LEA+LEA]: Dispositivo A=Pixel 8 (15), Dispositivo B=Pixel 8(15) coluna E: Smartphone=Pixel 8, SO=Android 15

Exemplo de teste concluído no modelo de autoteste:

Eventos de áudio:

• Os quatro tipos de eventos de áudio testados e os apps de teste recomendados são:

  1. Ligação:
     1. O app de smartphone integrado.
  2. VoIP: qualquer app VoIP funciona, como:
     1. O app de teste da seleção de áudio.
     2. FB Messenger.
     3. Linha.
     4. WhatsApp.
     5. Google Meet
     6. Google Meet
  3. Mídia: qualquer player de áudio funciona, como:
     1. O app de teste da seleção de áudio.
     2. YouTube Music.
     3. Apple Music.
     4. Spotify.
     5. Google Podcasts
  4. Jogo:
     1. O app de teste da seleção de áudio.

Observação: consulte a seção App de teste de alternância de áudio para mais detalhes.

Informações de depuração:

• As notificações são ativadas após a adesão ao grupo fp-sass-partner-test. Veja alguns exemplos:

  • Notificação de estado mais recente:

  

  • Sem notificação de mudança:

  

  Observação: "Ultimo estado" é o estado de conexão quando o evento de áudio ocorre, e não o evento mais recente atual.
  • Notificação de latência da troca:

  

Medição de latência

Observação: "Seeker" significa o smartphone ou tablet usado para conectar o fone de ouvido no teste, também conhecido como dispositivo A, B, C, D ou E nos casos de teste.

• Há dois tipos de latência de chaveamento:
  1. Conectar um perfil Bluetooth a um Seeker desconectado.
     • Isso inclui todos os casos de ponto único e alguns casos de MP em que o Seeker de destino (dispositivo B) está desconectado.
  2. Alterar o Seeker conectado ativo.
     • Isso inclui alguns casos de MP em que o Seeker de destino (dispositivo B) já está conectado.
• Há duas maneiras de extrair informações de latência:
  1. Toda a latência pode ser descartada pelo comando adb.
     • Consulte a seção Latência de despejo para mais detalhes.
     • Esse comando pode fornecer e registrar a latência após a conclusão de pelo menos um caso de teste.
  2. Usando o app de teste da seleção de áudio.
     • O app em execução no Seeker de destino vai mostrar a latência após a troca.
     • Se não houver uma troca, o app vai mostrar o motivo "sem troca".

App de teste de seleção de áudio:

• Usar o app para acionar eventos de áudio VoIP/mídia/jogo durante um autoteste simplifica a configuração do teste e reduz a latência do evento do Seeker.
  • Faça o download da versão mais recente.
  • O teste de VoIP de áudio LE precisa de uma política para ser ativado manualmente: > adb root > adb shell settings put global hidden_api_policy 1 > adb reboot

Observação: você vai precisar de uma Conta do Google para solicitar acesso ao link de download. O acesso é um processo manual e pode levar vários dias.

• Instalação do app:
  • Copie o apk para o smartphone de teste e abra.
  • Como alternativa, use adb install audio_test_app.apk.

Aviso: conceda todas as permissões ao abrir o app pela primeira vez.

• Se uma caixa de diálogo pedir acesso às notificações:
  1. Clique em "OK".
  2. Escolha "FP SASS test" na lista de apps.
  3. Permita o acesso às notificações.

Visão geral do app:

• Provedor de destino

  • Esse botão vai mostrar uma lista de dispositivos Bluetooth pareados quando clicado. Selecione o que você quer testar.
  • Os botões "Conectar" e "Desconectar" funcionam como o botão de detalhes do dispositivo nas configurações do Bluetooth.

• Estado atual

  • Esse campo mostra o último estado de conexão que o Seeker recebeu de um provedor usando publicidade BLE ou transmissão de eventos.
  • As notificações de depuração do interruptor de áudio também são mostradas aqui.

• Tipo de candidato

  • Essa opção é usada para alternar o dispositivo entre fluxos de áudio.

Tipo de áudio

Clássico com A2DP+HFP

• VoIP
  • A seleção desse modo vai mudar o modo de áudio para AudioManager.MODE_IN_COMMUNICATION e chamar AudioManager.startBluetoothSco, depois reproduzir o áudio com USAGE_VOICE_COMMUNICATION.
  • O tipo de transmissão é STREAM_VOICE_CALL.
  • O estado da conexão do provedor deve mudar para CONNECTED_HFP em até 5 segundos.
• Mídia
  • A seleção desse modo reproduz áudio com suporte a AVRCP. O tipo de uso de áudio é: USAGE_MEDIA.
  • O estado da conexão do provedor precisa mudar para CONNECTED_A2DP_WITH_AVRCP em até 5 segundos.
  • O estado da conexão pode mudar brevemente para CONNECTED_A2DP_ONLY quando iniciada ou interrompida.
• Jogo
  • A seleção desse modo reproduz áudio que não tem suporte para AVRCP. O tipo de uso do áudio é: USAGE_GAME.
  • O estado da conexão do provedor precisa mudar para CONNECTED_A2DP_ONLY em até 5 segundos.

BLE com LE Audio

• VoIP

  • A seleção desse modo vai mudar o modo de áudio para AudioManager.MODE_IN_COMMUNICATION e reproduzir áudio com USAGE_VOICE_COMMUNICATION.
  Observação: para versões do Android anteriores ao Tiramisu (Android 13), o app de teste chama AudioManager.startBluetoothSco para iniciar uma conexão de áudio SCO Bluetooth. Caso contrário, o app de teste chama AudioManager.setCommunicationDevice para selecionar o dispositivo de áudio usado para comunicação.
  • O tipo de transmissão é STREAM_VOICE_CALL.
  • O estado da conexão do provedor precisa mudar para CONNECTED_LE_AUDIO_CALL em até 5 segundos.

• Mídia

  • A seleção desse modo vai reproduzir áudio com o tipo de stream STREAM_MUSIC. O tipo de uso do áudio é: USAGE_MEDIA.
  • O estado da conexão do provedor precisa mudar para CONNECTED_LE_AUDIO_MEDIA_WITH_CONTROL em até 5 segundos.
  • O estado da conexão pode mudar brevemente para CONNECTED_LE_AUDIO_MEDIA_WITHOUT_CONTROL quando iniciado ou interrompido.

• Jogo

  • A seleção desse modo reproduz áudios que o usuário não controla diretamente. O tipo de uso do áudio é: USAGE_GAME.
  • O estado da conexão do provedor precisa mudar para CONNECTED_LE_AUDIO_MEDIA_WITHOUT_CONTROL em até 5 segundos.

• Botões "Reproduzir" e "Parar"

  • Os botões PLAY e STOP iniciam ou interrompem o áudio.

• Mudar resultado

  • Esse campo mostra a latência ativa do Connect e do Switch. Ele também mostra o motivo da negação de uma troca se um evento de áudio foi acionado mas não aconteceu.
  • A latência é medida em milissegundos (ms).
  • Em geral, a latência é medida desde o início do acionador de alternância de áudio até o recebimento de um perfil BT conectado ou um evento de alternância multiponto de notificação.
  • As mudanças acionadas pelo provedor medem a latência desde o início do áudio.

Latência de despejo

• O comando a seguir permite que um usuário capture medições de latência ao executar testes manuais: adb shell dumpsys activity service com.google.android.gms/.nearby.discovery.service.DiscoveryService
  • As medições de latência são mostradas na seção SwitchHistory de NearbyDeviceManager:

            NearbyDeviceManager
              Nearby Sass device count: 1
                Sass device - address:XX:XX:XX:XX:XX:XX, name:Googler's Pixel Buds, accountKey:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, modelId:6edaf7
                  SwitchHistory
                    15:30:21:166 - 15:30:25:201, latency 3035ms, Succeed, SASS_TRIGGERED_CONNECT, SASS switch, A2DP
                    15:34:58:568 - 15:34:58:568, latency 0ms, Succeed, SWITCH_ACTIVE_TO_SELF, SASS switch, HFP
                    15:36:26:615 - 15:36:31:603, latency 1988ms, Succeed, SASS_TRIGGERED_CONNECT, SASS switch, A2DP
                    15:37:56:108 - 15:37:56:250, latency 142ms, Succeed, SWITCH_ACTIVE_TO_SELF, SASS switch, A2DP"

• Qualquer chave que o GmsCore não possa medir (por exemplo, chave ativa para HFP) será registrada como latência de 0ms.

Referência de padrões de registro:

Problemas conhecidos:

Confira a seguir os bugs conhecidos causados pelo Seeker:

1. Troca de áudio do jogo incorreta.
   • Os smartphones Samsung vão definir o estado de conexão como CONNECTED_A2DP_WITH_AVRCP, em vez de CONNECTED_A2DP_ONLY, ao jogar jogos.
   • Alguns jogos (como o Candy Crush) podem reproduzir música em segundo plano e acionar um novo evento de áudio sem a entrada do usuário. Os smartphones conectados podem mudar constantemente o áudio em todos os smartphones que abrirem o jogo.