Send and sync data on Wear OS

With Wear OS by Google, a watch has multiple ways to send and sync data. It is strongly recommended that you send and sync data directly from the network, rather than using the Wearable Data Layer API.

Send and sync data directly from the network

Build Wear OS apps to communicate directly with the network. You can use the same APIs as you would for mobile development, but you need to keep some minor 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 {
    compile ''

It's strongly recommended 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 are unable to 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 on 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 defines.
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 if 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/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 may 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 will be 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 should generally be 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. For example, when the user saves a note on a handheld, it automatically appears on all of 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.
Figure 1. A sample network of nodes with handheld and wearable 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.

Comparison table for each client

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

Data Client Message Client Channel Client
Data size greater than 100 kilobyte. Yes No Yes
Requires a network connection, such as saving data to the Cloud. Yes Use Bluetooth Use Bluetooth
Send messages to nodes which are not currently connected. Yes No No
Send from one device to another device, such as from wear to mobile. No, from the cloud to all the nodes Yes Yes, both for one way requests and bi-directional requests.
Support faning out data to all the devices Yes No No
Reliability Yes Yes, when the Bluetooth connection is established. Yes

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

Important: Your phone and Wear OS APK signatures and the signature schemes must be identical for the Wearable Data Layer API to successfully communicate between devices. This includes your usage of the v1 and/or v2 signature. Ensure the signature scheme is set correctly in build.gradle or when you use the Generate Signed APK wizard.