Envoyer et synchroniser des données sur Wear OS

Avec Wear OS by Google, une montre peut envoyer et synchroniser des données de plusieurs façons. Nous vous recommandons d'envoyer et de synchroniser les données directement à partir du réseau, car l'application sera alors considérée comme autonome.

Envoyer et synchroniser des données directement à partir du réseau

Créez des applications Wear OS pour communiquer directement avec le réseau. Vous pouvez utiliser les mêmes API que pour le développement mobile, mais gardez à l'esprit certaines différences spécifiques à Wear OS.

Envoyer et synchroniser des données avec l'API Wearable Data Layer

L'API Wearable Data Layer, qui fait partie des services Google Play, offre un canal de communication facultatif pour les applications.

Cette API n'est disponible que sur les montres Wear OS et les appareils Android associés. Pour les montres Wear OS associées à des téléphones iOS, les applications peuvent interroger d'autres API dans le cloud si une connexion Internet est disponible.

L'API Wearable Data Layer dispose des dépendances suivantes :

Ajoutez la dépendance suivante dans le fichier build.gradle de votre module Wear : 

  dependencies {
    ...
    implementation 'com.google.android.gms:play-services-wearable:18.1.0'
  }

Il est recommandé que les applis connectées envoient et synchronisent les données directement à partir d'un réseau ou d'un téléphone connecté. Toutefois, si vous souhaitez communiquer directement entre des appareils dans un format de type RPC ou si vous ne pouvez pas vous connecter directement à un réseau pour les données, vous pouvez utiliser l'API Wearable Data Layer comme suit.

Annoncer et interroger des capacités à distance
Le CapabilityClient indique quels nœuds du réseau Wear OS prennent en charge quelles capacités d'applications personnalisées. Les nœuds représentent les accessoires connectés et les appareils mobiles qui sont connectés au réseau. Une capacité est une fonctionnalité définie par une application au moment de la compilation ou configurée dynamiquement au moment de l'exécution.
Par exemple, une application Android mobile peut annoncer qu'elle prend en charge la télécommande pour la lecture de vidéos. Lorsque la version de l'application pour accessoires connectés est installée, elle peut utiliser le CapabilityClient pour vérifier si la version mobile de l'application est installée et prend en charge cette fonctionnalité. Si c'est le cas, l'appli connectée peut afficher le bouton de lecture/pause pour contrôler la vidéo sur l'autre appareil à l'aide d'un message.
Cela peut également fonctionner dans le sens inverse, avec les capacités de fiche de l'appli connectée prises en charge.
Envoyer des messages
Le MessageClient peut envoyer des messages et convient pour les appels de procédure à distance (RPC), tels que le contrôle du lecteur multimédia d'un appareil portable depuis l'accessoire connecté ou le démarrage d'un intent sur l'accessoire connecté depuis l'appareil portable. Les messages conviennent également parfaitement pour les requêtes unidirectionnelles ou pour un modèle de communication requête ou réponse.
Si l'appareil portable et l'accessoire connecté sont connectés, le système met le message en file d'attente pour la diffusion et renvoie un code de résultat réussi. Si les appareils ne sont pas connectés, une erreur est renvoyée. Un code de résultat réussi n'indique pas que le message a bien été remis, car les appareils pourraient se déconnecter après avoir reçu le code de résultat.
Transférer les données
Le ChannelClient peut transférer des données depuis un appareil portable vers un accessoire connecté. Avec ChannelClient, vous pouvez effectuer les opérations suivantes :
  • Transférer des fichiers de données entre plusieurs appareils connectés lorsque la connexion Internet n'est pas disponible sans la synchronisation automatique fournie lors de l'utilisation des objets Asset associés aux objets DataItem. ChannelClient permet d'économiser de l'espace disque sur DataClient, ce qui crée une copie des éléments sur l'appareil local avant la synchronisation avec les appareils connectés.
  • Envoyer de manière fiable un fichier trop volumineux pour l'envoi à l'aide d'un MessageClient.
  • Transférer des données diffusées, telles que des données vocales depuis le micro.
Synchroniser les données
Un DataClient expose une API pour que les composants puissent lire ou écrire un DataItem ou un Asset.
Un DataItem est synchronisé sur tous les appareils d'un réseau de Wear OS. Il est possible de définir des éléments de données sans être connecté à des nœuds. Ces éléments de données sont synchronisés lorsque les nœuds se connectent.
Les éléments de données sont privés au niveau de l'application qui les a créés. Cette application peut uniquement y accéder sur les autres nœuds. Ils sont généralement de petite taille. Utilisez Assets pour transférer des objets de données plus volumineux et persistants, tels que des images.
Wear OS prend en charge plusieurs accessoires connectés qui sont connectés à un appareil portable. Par exemple, lorsque l'utilisateur enregistre une note sur un appareil portable, celle-ci s'affiche automatiquement sur tous ses appareils Wear OS. Pour permettre la synchronisation des données entre les appareils, les serveurs de Google hébergent un nœud cloud sur le réseau d'appareils. Le système synchronise les données avec les appareils connectés directement, le nœud cloud et les accessoires connectés qui sont connectés à ce nœud cloud via le Wi-Fi.
Écouter les événements importants de couche de données (pour les services)
L'extension de WearableListenerService vous permet d'écouter les événements importants de couche de données dans un service. Le système gère le cycle de vie du WearableListenerService en l'associant au service lorsqu'il doit envoyer des éléments de données ou des messages et en le dissociant en l'absence de travail.
Écouter les événements importants de couche de données (pour les activités de premier plan)
L'implémentation de OnDataChangedListener dans une activité vous permet d'écouter les événements importants de couche de données lorsqu'une activité se trouve au premier plan. L'utilisation de cette méthode à la place de WearableListenerService vous permet d'écouter les modifications uniquement lorsque l'utilisateur utilise activement votre application.

Avertissement : Étant donné que ces API sont conçues pour la communication entre les appareils portables et les accessoires connectés, ces API sont les seules que vous pouvez utiliser pour configurer la communication entre ces appareils. Par exemple, n'essayez pas d'ouvrir des sockets de bas niveau pour créer un canal de communication.

Comparaison des clients

Le tableau suivant présente les différentes exigences et les différents cas d'utilisation pour chaque client.

Client de données Client de messages Client de canaux
Taille des données supérieure à 100 ko Oui Non Oui
Peut envoyer des messages à des nœuds qui ne sont actuellement pas connectés Oui Non Non
Schéma de communication Ressource partagée basée sur le réseau Transmission d'un message privé (avec réponse) Streaming privé

Connectivité

La couche de données propose deux options de communication :

  1. Échanger directement les données lorsqu'une connexion Bluetooth est établie entre la montre et un autre appareil
  2. Échanger des données sur un réseau disponible tel que LTE ou Wi-Fi
Figure 1 : Exemple de réseau de nœuds avec des appareils portables et des accessoires connectés

Tous les clients de la couche de données peuvent échanger des données via le Bluetooth ou Google Cloud Sync), en fonction des connexions disponibles pour les appareils. Le service de synchronisation cloud est le mécanisme de communication et d'échange de données de Google entre les accessoires connectés et les téléphones lorsque le Bluetooth n'est pas disponible.

Sécurité

Les deux options de communication, Bluetooth et GCDS, sont chiffrées de bout en bout.

Les services Google Play appliquent les restrictions suivantes pour garantir que la communication entre le téléphone et la montre est sécurisée et a lieu d'une application à une autre.

  • Le nom du package doit être identique sur tous les appareils.
  • La signature du package doit être identique sur tous les appareils.

Bluetooth

Lorsque les appareils sont connectés via le Bluetooth, la couche de données utilise cette connexion. Lorsque vous utilisez le Bluetooth, il existe un seul canal chiffré entre les appareils, qui utilise le chiffrement Bluetooth standard, géré par les services Google Play.

Cloud

Supposons que les données transmises à l'aide de la couche de données puissent à un moment donné utiliser les serveurs de Google. Par exemple, DataClient, MessageClient ou ChannelClient sont automatiquement acheminés via Google Cloud lorsque le Bluetooth n'est pas disponible. Toutes les données transférées via Google Cloud sont chiffrées de bout en bout.

Génération de clé et stockage

Les clés de bout en bout pour la communication dans le cloud sont générées par le téléphone et échangées directement avec la montre lorsque les deux appareils sont connectés via le Bluetooth. Cela se produit pendant la configuration de l'appareil. Les serveurs appartenant à Google ne reçoivent ces clés à aucun moment.

La communication via les serveurs de Google ne peut pas avoir lieu tant que la génération de clés de bout en bout n'est pas terminée. Les clés sont stockées dans l'espace de stockage de fichiers privé des services Google Play sur tous les appareils associés.

Sauvegarde de l'appareil

Les clés ne sont pas sauvegardées et ne quittent pas l'appareil. Si de nouvelles clés sont requises, par exemple pour un nouveau téléphone, le système en génère de nouvelles et les partage avec les appareils dont l'utilisateur dispose toujours.