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 a seleção de áudio desativada.
        • Você pode desativar a seleção de áudio nas configurações de detalhes do dispositivo Bluetooth.
      • O caso de teste 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 seleção de áudio com suas contas de teste para mostrar notificações de depuração em 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 ser compatíveis com LE Audio.
    • Por exemplo, um smartphone Samsung e um Pixel compatíveis com 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 ser superior a 95% em todos os casos de teste.

  • Em testes que exigem uma troca, a conexão de perfil e a troca de estado ativo precisam ser concluídas em até 3 segundos após a ativação de 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:

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

Guia de teste

Preparação do dispositivo em teste (DUT)

  • Verifique se o dispositivo Bluetooth não foi pareado 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 opção fica DESATIVADA por padrão.
      • Essa opção está disponível em Configurações > Google > Dispositivos > Dispositivos salvos (um por DUT).
    • Coloque o dispositivo Bluetooth no modo de pareamento.
    • Pareie o dispositivo Bluetooth inicial (A).
    • Pareie os dispositivos Bluetooth subsequentes com outros dispositivos (B, C, D etc.).

Escopo

  • Todos os headsets executam testes nas várias guias do relatório de auto teste do BT Classic ou do BT LE Audio.
  • Os headsets que oferecem suporte apenas ao modo SinglePoint (SP) executam o seguinte:
    • A guia "Generic_test".
  • Os headsets compatíveis com o modo MP executam o seguinte:
    • A guia "Generic_test".
    • A guia "Multipoint_only".
  • Os headsets 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 o MP ativado.
    • A guia "Multipoint_only" com o MP ativado.

Como concluir o auto descanso e o relatório de autoteste

  • Faça uma cópia dos relatórios de autoavaliação 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 "Telefone" e "SO" na parte de cima do modelo.

Exemplo de caso de teste:

  • Smartphones de teste:

    • 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
    • Execute 2. Dispositivo A=Pixel 7 Pro (13), Dispositivo B=Pixel 6(12) Coluna E: Smartphone=Pixel 6, SO=Android 12

Exemplo de um teste concluído no modelo de autoavaliação:

Esta imagem mostra os resultados de um exemplo de teste

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 "Telefone" e "SO" na parte de cima do modelo.

Exemplo de caso de teste:

  • Smartphones de teste:

    • 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]: Device A=Pixel 7 (13), Device B=Pixel 8 (Android 15) column E: Phone=Pixel 8, OS=Android 15
    • [BT+BT]: coluna Device A=Pixel 7 pro (13), Device B=Samsung S10+ (12) E: Phone=Samsung S10+, OS=Android 12
    • [LEA+LEA]: Device A=Pixel 8 (15), Device B=Pixel 8(15) column E: Phone=Pixel 8, OS=Android 15

Exemplo de um teste concluído no modelo de autoavaliação:

Esta imagem mostra os resultados de um exemplo de teste

Eventos de áudio:

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

    1. Ligue para:
      1. O app de telefone integrado.
    2. VoIP: qualquer app de VoIP funciona, como:
      1. O app de teste de 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 de seleção de áudio.
      2. YouTube Music.
      3. Apple Music.
      4. Spotify.
      5. Google Podcasts
    4. Jogo:
      1. O app de teste de seleção de áudio.

Informações de depuração:

  • As notificações são ativadas depois que você entra no grupo fp-sass-partner-test. Veja alguns exemplos:

    • Última notificação de estado:

    Figura 1: mostra a mensagem "notificação do estado mais recente".

    • Sem notificação de troca:

    Figura 2: mostra a mensagem "sem notificação de troca".

    • Notificação de latência de troca:

    Figura 3: mostra a mensagem "Notificação de latência de troca".

Medição de latência

  • Há dois tipos de latência de troca:
    1. Conectar um perfil Bluetooth a um Seeker desconectado.
      • Isso inclui todos os casos SinglePoint e alguns casos MP em que o Seeker (dispositivo B) de destino está desconectado.
    2. Alternar 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 recuperar informações de latência:
    1. Toda a latência pode ser despejada pelo comando adb.
      • Consulte a seção Latência de despejo para mais detalhes.
      • Esse comando pode fornecer e registrar a latência depois de concluir 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 depois da troca.
      • Se não houver 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 de eventos do Seeker.
    • A versão mais recente pode ser baixada aqui.
    • O teste de VoIP do LE Audio precisa de uma política para ser ativada manualmente: > adb root > adb shell settings put global hidden_api_policy 1 > adb reboot
  • Instalação de apps:
    • Copie o apk para o smartphone de teste e abra-o.
    • Se preferir, use adb install audio_test_app.apk.
  • Se aparecer uma caixa de diálogo pedindo acesso às notificações:
    1. clique em "OK".
    2. Escolha "Teste de SASS de FP" na lista de apps.
    3. Permita o acesso às notificações.

Visão geral do app:

Esta imagem é um exemplo do app em execução

  • Provedor de destino

    • Ao clicar nesse botão, uma lista de dispositivos Bluetooth pareados será exibida. Selecione o que você quer testar.
    • Os botões "Conectar" e "Desconectar" funcionam como os detalhes do dispositivo nas configurações de Bluetooth.

  • Estado atual

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

  • Tipo de buscador

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

Tipo de áudio

Clássico com A2DP+HFP

  • VoIP
    • Selecionar esse modo muda o modo de áudio para AudioManager.MODE_IN_COMMUNICATION e chama AudioManager.startBluetoothSco. Em seguida, reproduz o áudio com USAGE_VOICE_COMMUNICATION.
    • O tipo de stream é STREAM_VOICE_CALL.
    • O estado da conexão do provedor deve mudar para CONNECTED_HFP em até 5 segundos.
  • Mídia
    • Selecionar esse modo vai reproduzir áudio compatível com AVRCP. O tipo de uso de áudio é: USAGE_MEDIA.
    • O estado da conexão do provedor deve mudar para CONNECTED_A2DP_WITH_AVRCP em até 5 segundos.
    • O estado da conexão pode mudar brevemente para CONNECTED_A2DP_ONLY quando iniciado ou interrompido.

  • Jogo

    • Selecionar esse modo reproduz áudio que não é compatível com AVRCP. O tipo de uso do áudio é: USAGE_GAME.
    • O estado da conexão do provedor deve mudar para CONNECTED_A2DP_ONLY em até 5 segundos.

BLE com LE Audio

  • VoIP

    • Ao selecionar esse modo, o áudio muda para AudioManager.MODE_IN_COMMUNICATION e é reproduzido com USAGE_VOICE_COMMUNICATION.
    • O tipo de stream é STREAM_VOICE_CALL.
    • O estado da conexão do provedor deve mudar para CONNECTED_LE_AUDIO_CALL em até 5 segundos.

  • Mídia

    • Ao selecionar esse modo, o áudio será reproduzido com o tipo de stream STREAM_MUSIC. O tipo de uso do áudio é: USAGE_MEDIA.
    • O estado da conexão do provedor deve 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 ela é iniciada ou interrompida.

  • Jogo

    • Selecionar esse modo reproduz áudio que o usuário não controla diretamente. O tipo de uso do áudio é: USAGE_GAME.
    • O estado da conexão do provedor deve mudar para CONNECTED_LE_AUDIO_MEDIA_WITHOUT_CONTROL em até 5 segundos.

  • Botões "Reproduzir" e "Parar"

    • Os botões "TOCAR" e "PARAR" iniciam ou interrompem o áudio.

  • Resultado da troca

    • Esse campo mostra a latência ativa de conexão e troca. Ele também mostra o motivo da negação de uma troca se um evento de áudio foi acionado mas a troca não aconteceu.
    • A latência é medida em milissegundos (ms).
    • Em geral, a latência é medida desde o início do acionador de seleção de áudio até o recebimento de um perfil BT conectado ou um evento de troca 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 NearbyDeviceManager's SwitchHistory:
            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 troca que o GmsCore não puder medir (por exemplo, troca ativa para HFP) será registrada como latência de 0 ms.

Referência de padrões de registro:

Exemplos de registros do teste de latência

Problemas conhecidos:

Estes são os bugs conhecidos causados pelo Seeker:

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