Send and sync data on Wear OS

With Wear OS by Google, a watch has multiple ways to send and sync data. We recommend that you send and sync data directly from the network, as this allows the app to be considered a standalone app.

Send and sync data directly from the network

Build Wear OS apps to communicate directly with the network. You can use the same APIs that you use for mobile development, but keep some Wear-OS-specific differences in mind.

Send and sync data with the Wearable Data Layer API

The Wearable Data Layer API, which is part of Google Play services, provides an optional communication channel for apps.

This API is only available on Wear OS watches and paired Android devices. For Wear OS watches paired with iOS phones, apps can query other cloud-based APIs if internet connectivity is available.

The Wearable Data Layer API has the following dependencies:

Include the following dependency in the build.gradle file of your Wear module: 

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

We recommend that Wearable apps send and sync data directly from a network or connected phone. However, if you want to communicate directly between devices in an RPC-type format or you can't connect directly to a network for data, you can use the Wearable Data Layer API in the following ways.

Advertise and query remote capabilities
The CapabilityClient provides information about which nodes on the Wear OS network support which custom app capabilities. Nodes represent both mobile and wearable devices that are connected to the network. A capability is a feature that an app either defines at build time, or configures dynamically at runtime.
For example, a mobile Android app could advertise that it supports remote control of video playback. When the wearable version of that app is installed, it can use the CapabilityClient to check whether the mobile version of the app is installed and supports that feature. If it does, the wearable app can show the play/pause button to control the video on the other device using a message.
This can also work in the opposite direction, with the wearable app listing capabilities it supports.
Send messages
The MessageClient can send messages and is good for remote procedure calls (RPC), such as controlling a handheld's media player from the wearable or starting an intent on the wearable from the handheld. Messages are also great for one-way requests or for a request or response communication model.
If the handheld and wearable are connected, the system queues the message for delivery and returns a successful result code. If the devices aren't connected, an error is returned. A successful result code doesn't indicate that the message was delivered successfully, as the devices might disconnect after receiving the result code.
Transfer data
The ChannelClient can transfer data from a handheld to a wearable device. With ChannelClient, you can do the following things:
  • Transfer data files between two or more connected devices when the internet isn't available without the automatic synchronization provided when using Asset objects attached to DataItem objects. ChannelClient saves disk space over DataClient, which creates a copy of the assets on the local device before synchronizing with connected devices.
  • Reliably send a file that is too large to send using a MessageClient.
  • Transfer streamed data, such as voice data from the microphone.
Synchronize data
A DataClient exposes an API for components to read or write to a DataItem or Asset.
A DataItem is synchronized across all devices in a Wear OS network. It is possible to set data items while not connected to any nodes. Those data items are synchronized when the nodes come online.
Data items are private to the application that created them and are only accessible by that application on other nodes. They are generally small in size. Use Assets for the transfer of larger, more persistent data objects, such as images.
Wear OS supports multiple wearables connected to a handheld device. So, for example, when the user saves a note on a handheld, it automatically appears on all the user's Wear OS devices. To help synchronize data between devices, Google’s servers host a cloud node in the network of devices. The system synchronizes data to directly connected devices, the cloud node, and to wearable devices connected to the cloud node using Wi-Fi.

Warning: Items are transferred to all available Wear OS devices, even those that don't have your app installed. If syncing a large amount of data, consider checking whether a "receiver" app is installed and online to avoid wasting resources on both handheld devices and Wear OS devices.

Listen for important data layer events (for services)
Extending WearableListenerService lets you listen for important data layer events in a service. The system manages the lifecycle of the WearableListenerService, binding to the service when it needs to send data items or messages and unbinding the service when no work is needed.
Listen for important data layer events (for foreground activities)
Implementing OnDataChangedListener in an activity lets you listen for important data layer events when an activity is in the foreground. Using this instead of the WearableListenerService lets you listen for changes only when the user is actively using your app.

Warning: Because these APIs are designed for communication between handhelds and wearables, these are the only APIs you can use to set up communication between these devices. For instance, don't try to open low-level sockets to create a communication channel.

Client comparison

The following table shows the different requirements and use cases for each client.

Data Client Message Client Channel Client
Data size greater than 100 kb Yes No Yes
Can send messages to nodes that aren't currently connected Yes No No
Communication pattern Shared network-based resource 1:1 message passing (with response) 1:1 streaming

Connectivity

Data Layer has two options for communication:

  1. Directly exchange data when there is an established Bluetooth connection between the watch and another device.
  2. Exchange data over an available network such as LTE or WiFi.
Figure 1. A sample network of nodes with handheld and wearable devices.

All Data Layer clients may exchange data either using Bluetooth or Google Cloud Sync, depending on connections available to the devices. Cloud Sync Service is Google’s mechanism for communication and exchange of data between wearables and phones when Bluetooth is not available.

Security

Both communication options, Bluetooth and Cloud Sync Service, are end-to-end encrypted.

Google Play Services enforces the following restrictions to ensure that communication between the phone and watch is secure and app-to-app.

  • The package name must match across devices.
  • The signature of the package must match across devices.

Bluetooth

When devices are connected using Bluetooth, Data Layer uses this connection. When using Bluetooth, there is a single encrypted channel between the devices, using standard Bluetooth encryption, managed by Google Play Services.

Cloud

Assume that data transmitted using Data Layer may at some point use Google-owned servers. For example, DataClient, MessageClient or ChannelClient automatically route through Google cloud when Bluetooth is unavailable. All data transferred through Google cloud is end-to-end encrypted.

Key generation and storage

End-to-End keys for cloud-based communication are generated by the phone, and are exchanged directly with the watch when the two devices are connected using Bluetooth. This happens during device setup. Google-owned servers don't receive these keys at any point.

Communication through Google-owned servers cannot take place until the end-to-end key generation is completed. Keys are stored in Google Play services's private file storage on all paired devices.

Device backup

Keys are not backed up and don't leave the device. If new keys are required, such as for a new phone, the system generates fresh keys and shares them with the devices that the user still has.