Consignes de certification pour le switch audio

Préparation à la certification

1. Préparez les appareils de test.
   • Vous aurez besoin de cinq appareils Android.
     • Ces appareils doivent inclure: <ph type="x-smartling-placeholder">
       </ph>
       • Au moins un appareil Android T (13) et un Android S (12).
       • Au moins un Samsung et un Pixel.
       • Exemple :
         • 1 OnePlus (Android 10).
         • 3 Samsung (Android 11, 12, 13).
         • 1 Pixel (Android 13).
   • Un appareil sans switch audio: <ph type="x-smartling-placeholder">
     </ph>
     • Un iPhone, un PC, un ordinateur portable compatible Bluetooth (BT) ou un téléphone Android pour lequel le switch audio est désactivé.
       • Vous pouvez désactiver le switch audio dans les détails de l'appareil Bluetooth .
     • Le scénario de test multipoint 2.8 nécessite un appareil sans switch audio dans en plus des 5 téléphones de test.
2. Rejoignez le groupe de testeurs du switch audio avec vos comptes de test dans pour afficher les notifications de débogage sur les téléphones de test.
   • Cela permet également à Google de collecter des données de test via Google Analytics.
3. Assurez-vous que tous les appareils Android disposent de GmsCore version 23.xx.xx ou ultérieure installés.

Critères de certification

• Le taux de réussite du changement cible doit être supérieur à 95% dans tous les scénarios de test.
• Lors des tests nécessitant un commutateur, la connexion du profil et le changement d'état actif doit être terminée dans les 3 secondes suivant le déclenchement d'événements audio dans au moins 75% de cas.

Guide des tests

Préparation de l'appareil testé

• Vérifiez que l'appareil Bluetooth n'a été associé à aucun téléphone au préalable. connecté au compte Google de test.
  • Si l'appareil a été associé au compte Google de test, procédez comme suit : pour effacer l'association: <ph type="x-smartling-placeholder">
    </ph>
    • Sur les appareils associés: <ph type="x-smartling-placeholder">
      </ph>
      • Accédez aux paramètres Bluetooth.
      • Sélectionnez "Oublier l'appareil".
      • Activez et désactivez le mode Avion.
  • Assurez-vous que l'option "Enregistrer automatiquement les appareils" est activé.
    • Ce bouton est désactivé par défaut.
    • Cette option est disponible dans Paramètres > Google > Appareils > Enregistré (un par appareil testé).
  • Mettez l'appareil Bluetooth en mode Association.
  • Associez l'appareil Bluetooth initial (A).
  • Associez les appareils Bluetooth suivants à d'autres appareils (B, C, D, etc.).

Champ d'application

• Tous les casques permettent d'exécuter des tests à partir des différents onglets du Modèle d'autotest pour le switch audio
• Pour les casques qui n'acceptent que le mode SinglePoint (SP), exécutez la commande suivante: <ph type="x-smartling-placeholder">
  </ph>
  • Onglet Generic_test.
• Pour les casques compatibles avec le mode MP, procédez comme suit: <ph type="x-smartling-placeholder">
  </ph>
  • Onglet Generic_test.
  • Onglet "Multipoint_only" (Multipoint uniquement).
• Pour les casques MP qui peuvent être activés en mode SP, procédez comme suit: <ph type="x-smartling-placeholder">
  </ph>
  • Onglet "Generic_test" avec le protocole de contrôle désactivé
  • Onglet Generic_test avec MP activé.
  • Onglet "Multipoint_only" (Multipoint uniquement) avec le protocole de mesure activé

Repos et test automatique

• Exécutez tous les scénarios de test au moins deux fois.
• Les tests doivent être exécutés sous la forme suivante:

1. Appareil A=Android S (12) + Appareil B=Android T (13)
2. Appareil A=Android T (13) + Appareil B=Android S (12)
3. L'appareil B sera l'appareil testé principal.
   • Saisissez les détails de l'appareil B dans le "Téléphone" et « OS » des champs en haut de le modèle.

Exemple de scénario de test:

• Téléphones de test:

  • Appareil 1: Samsung (Android 13)
  • Appareil 2: Pixel (Android 12 ou 13) et autres

• Tests exécutés:

  • Exécutez 1. Appareil A=Samsung S10+ (12), appareil B=Pixel 7 Pro (13) colonne D: Téléphone=Pixel 7 Pro, OS=Android 13
  • Exécutez 2. Appareil A=Pixel 7 Pro (13), appareil B=Pixel 6(12) colonne E: Phone=Pixel 6, OS=Android 12

Exemple de test terminé dans le modèle de test automatique:

Événements audio:

• Les quatre types d'événements audio testés et les applications de test recommandées sont les suivants: <ph type="x-smartling-placeholder">
  </ph>
  1. Appeler: <ph type="x-smartling-placeholder">
     </ph>
     1. L'application intégrée pour téléphone.
  2. VoIP: toutes les applications VoIP fonctionnent, par exemple: <ph type="x-smartling-placeholder">
     </ph>
     1. L'application de test du switch audio.
     2. Facebook Messenger.
     3. Ligne.
     4. WhatsApp
     5. Google Meet
     6. Google Meet
  3. Multimédia: tous les lecteurs audio sont compatibles, par exemple: <ph type="x-smartling-placeholder">
     </ph>
     1. L'application de test du switch audio.
     2. YouTube Music.
     3. Apple Music.
     4. Spotify
     5. Google Podcasts)
  4. Jeu: <ph type="x-smartling-placeholder">
     </ph>
     1. L'application de test du switch audio.

Remarque :Pour en savoir plus, consultez la section Application de test du switch audio. plus de détails.

Informations de débogage:

• Les notifications sont activées une fois que vous avez rejoint le fp-sass-partner-test. Voici quelques exemples :

  1. Dernière notification d'état:

  2. Aucune notification de changement:

Remarque : "Dernier état" correspond à l'état de la connexion lorsque l'événement audio se produit, et NON, l'événement le plus récent.

1. Notification de changement de latence:

Mesure de la latence

Remarque : "Seeker" téléphone ou tablette que vous utilisez pour connecter le casque également connu sous le nom d'appareil A, B, C, D ou E dans les scénarios de test.

• Il existe deux types de latence de commutateur: <ph type="x-smartling-placeholder">
  </ph>
  1. Connexion d'un profil Bluetooth à un Seeker déconnecté.
     • Cela inclut tous les cas SinglePoint, et certains cas MP dont la cible Le demandeur (appareil B) est déconnecté.
  2. Changement de l'utilisateur connecté actif.
     • Cela inclut certains cas de MP pour lesquels le demandeur cible (appareil B) est déjà connecté.
• Il existe deux façons de récupérer les informations de latence: <ph type="x-smartling-placeholder">
  </ph>
  1. Toute la latence peut être vidée par la commande adb.
     • Pour en savoir plus, consultez la section Latence de vidage.
     • Cette commande peut fournir et enregistrer une latence après au moins un scénario de test.
  2. Utiliser l'application de test du switch audio <ph type="x-smartling-placeholder">
     </ph>
     • L'application exécutée sur la cible Seeker affichera la latence après le changement d'appareil.
     • En l'absence de contacteur, l'application affichera le message "Aucun bouton bascule" ou motif.

Application de test du switch audio:

• Si vous utilisez l'application pour déclencher des événements audio VoIP/multimédia/jeu lors d'un test automatique, simplifier la configuration des tests et réduire la latence des événements du Seeker.
  • La version 1.03 peut être téléchargée sur cette page.

Remarque :Vous devez disposer d'un compte Google pour demander l'accès au lien de téléchargement. L'accès est une procédure manuelle qui peut prendre plusieurs jours.

• Installation de l'application: <ph type="x-smartling-placeholder">
  </ph>
  • Copiez l'APK sur votre téléphone de test, puis ouvrez-le.
  • Vous pouvez également utiliser adb install audio_test_app.apk.

Avertissement :Accordez toutes les autorisations à la première ouverture de l'appli.

• Si une boîte de dialogue vous demande l'accès aux notifications: <ph type="x-smartling-placeholder">
  </ph>
  1. cliquez sur "OK".
  2. Sélectionnez "Test SASS FP". dans la liste des applications
  3. Autorisez l'accès aux notifications.

Présentation de l'application:

Fournisseur cible

Lorsque vous cliquez sur ce bouton, la liste des appareils Bluetooth associés s'affiche. Sélectionner celui que vous voulez tester.

Les boutons "Connecter" et "Déconnecter" fonctionnent comme ceux du Bluetooth "Settings" détails de l'appareil.

État actuel

Ce champ indique le dernier état de connexion que le demandeur a reçu d'un fournisseur. à l'aide de la publicité ou d'un flux d'événements BLE.

Les notifications de débogage du switch audio sont également affichées ici.

Type de demandeur

Cette option permet de changer de flux audio sur l'appareil.

Type audio

VoIP La sélection de ce mode modifie le mode audio en AudioManager.MODE_IN_COMMUNICATION et appeler AudioManager.startBluetoothSco, puis lire l'audio avec USAGE_VOICE_COMMUNICATION

• Le type de flux est STREAM_VOICE_CALL.
• L'état de la connexion du fournisseur devrait passer à CONNECTED_HFP dans un délai de 5 secondes.

Médias La sélection de ce mode permet de lire un contenu audio compatible avec le protocole AVRCP. Type d'utilisation audio est: USAGE_MEDIA.

• L'état de la connexion du fournisseur doit passer à CONNECTED_A2DP_WITH_AVRCP en moins de 5 secondes.
• L'état de la connexion peut passer brièvement à CONNECTED_A2DP_ONLY au démarrage ou arrêtés.

Jeu La sélection de ce mode permet de lire un contenu audio non compatible avec AVRCP. Utilisation du contenu audio le type est: USAGE_GAME.

• L'état de la connexion du fournisseur devrait passer à CONNECTED_A2DP_ONLY dans un délai de 5 secondes.

Boutons de lecture et d'arrêt

Les boutons LECTURE et ARRÊT permettent de lancer ou d'arrêter l'audio.

Changer de résultat

Ce champ affiche la latence active de Connect et Switch. Il affiche également la raison du refus d'un commutateur si un événement audio a été déclenché, mais que le commutateur n'a pas eu lieu.

• La latence est mesurée en millisecondes (ms).
• En général, la latence est mesurée entre le début du déclenchement du switch audio la réception d'un profil BT connecté ou un événement de commutateur multipoint.
• Les commutateurs déclenchés par le fournisseur mesurent la latence à partir du démarrage de l'audio.

Latence de vidage

• La commande suivante permet à un utilisateur d'enregistrer les mesures de latence lorsque l'exécution de tests manuels: adb shell dumpsys activity service com.google.android.gms/.nearby.discovery.service.DiscoveryService <ph type="x-smartling-placeholder">
  </ph>
  • Les mesures de latence sont affichées sous 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"

• Tout commutateur que GmsCore ne peut pas mesurer (par exemple, un commutateur actif pour HFP) enregistrée sous forme de latence de 0 ms.

Référence des modèles de journal:

Problèmes connus :

Voici les bugs connus causés par le Seeker:

1. Basculement audio incorrect du jeu
   • Sur les téléphones Samsung, la connexion est définie CONNECTED_A2DP_WITH_AVRCP, au lieu de CONNECTED_A2DP_ONLY lors de la lecture des jeux vidéo.
   • Certains jeux(Candy Crush, par exemple) peuvent relire une musique de fond et déclencher une nouvelle sans entrée utilisateur. Les téléphones connectés changent constamment sur tous les téléphones qui ouvrent le jeu.