Switch audio

Les utilisateurs se servent de plus en plus de plusieurs sources audio les tâches quotidiennes, il y a de plus en plus de demandes pour une solution plus simple sur plusieurs appareils. Le switch audio bascule automatiquement sur la connexion du casque entre les appareils en fonction de l'activité de l'utilisateur (par exemple, lancer un film) et des priorités (un appel entrant, par exemple).

Principes de l'expérience utilisateur

1. Le changement de connexion doit être rapide et dépendre de l'action de l'utilisateur.
2. Le changement de connexion doit être transparent pour les utilisateurs, ce qui leur permet de ou l'inverser si l'interrupteur n'est pas souhaitable.
3. Le passage au Pixel doit respecter la confidentialité des utilisateurs.

Rôles

Audio Switch Seeker: il s'agit d'un appareil source audio (par exemple, téléphone ou tablette), à la recherche d'un casque à proximité, le cas échéant.

Audio Switch Provider: le fournisseur est normalement un casque faisant la promotion de son et l'état de la connexion pour permettre aux utilisateurs de passer au Pixel.

Présentation des conditions requises

Pour mettre en place la transition intelligente, les fournisseurs doivent respecter les exigences suivantes:

Charge utile publicitaire

Le Fournisseur doit indiquer l'état actuel de sa connexion dans l'annonce, basée sur les données du compte Association express décrites dans la section Publicité : lorsqu'elle n'est pas visible :

Notez que la version du tableau 4.2 est 0x1.

Champ "État de la connexion"

Il est recommandé que le fournisseur LE Audio gère tous les types de contextes spécifiés dans Assigned Numbers 6.12.3 (sauf si le fournisseur n'accepte pas explicitement un type de contexte donné) et mappez le type de contexte à l'état de connexion, comme ci-dessous.

• Conversationnelle: 0 x 9
• Contenu multimédia: 0 x 8
• Jeu: 0 x 7
• Pédagogique: 0 x 7
• Assistants vocaux: 0 x 9
• En direct: 0 x 9
• Effets sonores: 0 x 2
• Notifications: 0x2
• Sonnerie: 0 x 9
• Alertes: 0 x 7
• Alerte d'urgence: 0x9

Pour les contextes de type LE Audio mixte, par exemple pour lire des contenus multimédias pendant le fournisseur doit utiliser l'état de connexion ayant la priorité la plus élevée, c'est-à-dire 0x9 (appel) pour le scénario ci-dessus au lieu de 0x8 (média).

Bitmap de l'appareil connecté

Pour éviter tout basculement indésirable entre les connexions, il peut avoir besoin de savoir quel le ou les appareils auxquels le casque est actuellement connecté. Par exemple, lorsque le casque est connecté au téléphone, l'utilisateur ne veut pas être interrompu par changement de connexion quand l'un des membres de sa famille lance YouTube sur le tablette.

Notez que ce bitmap est anonyme. Il ne peut donc pas savoir appareils sont liés au Fournisseur. Prenons l'exemple de cinq appareils associés:

• 0: ordinateur portable (0bx0000000)
• 1: phoneA (0b0x000000)
• 2: téléphoneB (0b00x00000)
• 3: tablette (0b000x0000)
• 4: Télévision (0b0000x000)

Si les appareils actuellement connectés sont un ordinateur portable et une tablette, la valeur du le bitmap est 0b10010000. Le changement de commande est acceptable si elle est inévitable. Ex. : Lorsque les utilisateurs rétablissent la configuration d'usine du casque ou lorsque le nombre d'appareils associés atteint la limite supérieure.

Annonce pouvant être résolue de manière aléatoire

Pour éviter le suivi et respecter la confidentialité des utilisateurs, le Fournisseur doit alterner et chiffrez le champ par la clé de compte à l'aide d'AES-CTR:

 encrypted_connection_status_field = connection_status_raw_data ^ AES(Key, IV)

où

1. La clé est dérivée de la clé de compte en cours d'utilisation, est défini dans la section suivante.

   • La clé est générée par la fonction HKDF, IETF RFC 5869, à l'aide de l'algorithme SHA-256 de hachage.

       Key = HKDF(account_key, NULL, UTF8("SASS-RRD-KEY"),16)
     

   • Le fournisseur doit utiliser ici la clé de compte d'origine, c'est-à-dire le premier octet de la clé est 0x04. Elle n'est pas incluse dans le modèle d'utilisation.

2. IV (vecteur initial) correspond à la valeur de salage de 2 octets des données de clé de compte avec zéro une marge intérieure, c'est-à-dire que IV est concat(salt, Zéro sur 14 octets).

3. Les données brutes sur l'état de la connexion sont définies dans le tableau 4.1, si les les changements d'état de la connexion, le salage et le RPA doivent être régénérés au la même période publicitaire.

Ainsi, le champ d'état de la connexion chiffrée est alterné en même temps que le champ Les données de clé de compte sont alternées.

La publicité BLE sera structurée comme suit:

Par exemple, si l'élément Random Resolvable Data contient une connexion chiffrée, "status", le résultat déchiffré est le résultat champ d'état de la connexion.

Pour éviter toute falsification, les données de la clé de compte ci-dessus doivent être légèrement modifiées. lorsque les données aléatoires pouvant être résolues sont incluses dans l'annonce. Normalement, lorsque création du filtre de clé de compte, une valeur V est générée en combinant les variables de compte un filtre de clé avec un salage. Au lieu de cela, lorsque des données aléatoires résolubles sont également la valeur V doit être définie comme suit:

 V = concat(account_key, salt, random_resolvable_data)

Si des données de batterie et des données pouvant être résolues de manière aléatoire sont annoncées, V doit se présenter comme suit:

 V = concat(account_key, salt, battery_data, random_resolvable_data)

Clé de compte en cours d'utilisation

Le changement de connexion s'effectue en fonction du compte. Le fournisseur doit donc inclure le les informations de compte de la connexion actuelle dans l’annonce BLE. Si le l'appareil connecté actuel est un chercheur de switch audio, le fournisseur doit être en mesure pour obtenir la clé de compte associée à ce Seeker et utiliser cette clé de compte pour chiffrer le champ d’état de la connexion. Si la source audio connectée n'est pas de type audio switch Seeker, le fournisseur doit utiliser la dernière clé de compte utilisée.

Avant de calculer le filtre de clé de compte, le fournisseur doit modifier la première des clés de compte pour inclure l'un des formats d'utilisation suivants:

1. 0b00000100
   Cette clé de compte n'est pas utilisée.
   Il s'agit de la clé par défaut (voir Clé de compte).
2. 0b00000101
   Cette clé de compte est la dernière utilisée.
   Le champ d'état de la connexion est chiffré par cette clé de compte. Il n'y a aucun des informations clés de votre compte sur l'état actuel de la connexion, cela peut signifier appareils connectés ou l'appareil connecté n'est pas un chercheur de switch audio.
3. 0b00000110
   Cette clé de compte est la clé de compte en cours d'utilisation.
   Le champ d'état de la connexion est chiffré par cette clé de compte, et la valeur actuelle l'appareil connecté est associé à cette clé de compte.

Schéma de la charge utile du switch audio

La figure ci-dessous illustre le schéma de la charge utile du switch audio.

Messages

Une fois connectés, le demandeur et le fournisseur peuvent synchroniser l'audio à l'aide du flux de messages déclencher un commutateur de connexion, configurer et obtenir le basculement l'état de la connexion, etc. Nous créons un groupe de messages et codes de message spécifiques au switch audio, comme indiqué ci-dessous.

Vous trouverez des informations supplémentaires sur chaque code de message dans les sections suivantes.

Pour assurer l'authentification des messages, tous les messages de switch audio avec des les données envoyées du demandeur au fournisseur nécessitent un code d'authentification de message. Quand ? un message avec MAC est reçu, il doit être confirmé afin que le demandeur sait si le fournisseur a réagi ou non au message.

Si l'authentification du message réussit, le fournisseur envoie l'ACK pour message:

En cas d'échec, le Fournisseur envoie la clé NAK pour le message:

Notez que si l'expéditeur est le fournisseur, l'adresse MAC n'est pas requise.

Exploitez les fonctionnalités du switch audio

Le fournisseur de switch audio et le demandeur peuvent vérifier si l'Association express est connectée Le demandeur/fournisseur prend ou non en charge le switch audio à l'aide du message ci-dessous:

À la réception de messages de switch audio , le demandeur/fournisseur de commutateurs audio répond avec l'un des éléments suivants : options:

À la réception de ce message, le Fournisseur doit répondre par le code de message 0x34, notifier l'état de la connexion.

Informer l'état de la connexion

Comme défini dans la charge utile publicitaire BLE, par les fournisseurs multipoints, si l'état de la connexion change, sauf en cas de modification le paquet publicitaire, le Fournisseur doit également informer les demandeurs connectés qui utilisent la même clé de compte pour la modification. Si le fournisseur est connecté avec un demandeur de switch audio et un demandeur de switch audio non audio, si Switch Seeker est actif, le fournisseur doit également en informer l'utilisateur basculez l'utilisateur sur l'état de la connexion (à l'aide de sa clé de compte).

 encrypted_connection_status = connection_status_raw_data ^ AES(Key, IV)

• La clé est dérivée de la clé du compte en cours d'utilisation. Random Resolvable Publicité.

   Key = HKDF(account_key, NULL, UTF8("SASS-RRD-KEY"),16)
  

• IV est concat(Session_nonce, Message_nonce)

• connection_status_raw_data = concat(connection_state, custom_data, Connected_devices), ce qui est défini en BLE charge utile publicitaire Notez que l'octet de longueur et de type de champ ne doit pas être inclus, car nous avons ici le code du message et la longueur des données.

Envoyer une notification pour l'établissement d'une connexion avec le switch audio

Les fournisseurs de switch audio peuvent avoir besoin de savoir si le changement de connexion est déclenché. par le switch audio pour avoir des réactions différentes, par exemple désactiver les icônes sonores pour l'audio les événements de commutateur. Le demandeur envoie un message pour avertir le fournisseur que était une connexion initiée par le commutateur audio.

Reportez-vous à la bibliothèque de SDK intégrés Nearby pour l'implémentation de référence.