Android NDK development explains in detail how Wear sends and synchronizes data on Wear OS

With Wear OS by Google, your watch can send and sync data in a variety of ways. We recommend that you send and sync data directly over the network, as doing so allows the app to be treated as a standalone app.

Send and sync data directly over the network

Build Wear OS apps to communicate directly with the network. You can use the same APIs used for mobile development, but there are some Wear OS-specific differences to be aware of.

Send and sync data using the Wearable Data Layer API

The Wearable Data Layer API (part of Google Play Services) provides an optional communication channel for applications.

This API only works on Wear OS watches and paired Android devices. For Wear OS watches paired with an iOS phone, apps can query other cloud APIs when there is an internet connection.

The dependencies of the Wearable Data Layer API are as follows:

Latest version of Google Play services.
Wear OS device or Wear OS emulator.
Please add the following dependencies in your Wear module's build.gradle file:

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

We recommend that wearable apps send and sync data directly over the web or a connected phone. However, if you want to communicate directly between devices in the form of RPC type, or cannot directly connect to the network to get the data, you can use the Wearable Data Layer API in the following ways.

Announcement and Query Remote Functions

CapabilityClient provides information about which nodes on the Wear OS network support which custom app features. Nodes represent mobile and wearable devices that are connected to the network. Features are capabilities that an application can define at build time or be dynamically configured at runtime.
For example, a mobile Android app might advertise that it supports remote control of video playback. Once the wearable version of the app is installed, it can use the CapabilityClient to check whether its mobile version is installed and supports the feature. If installed and supported, wearable apps can display play/pause buttons to control video on another device through messages.
The reverse operation is also possible using the supported wearable app details feature.

Send a message

The MessageClient can send messages and is ideal for making remote procedure calls (RPCs), such as controlling a media player on a handheld device through the wearable device, or initiating an intent on a wearable device through the handheld device. Messages also work with one-way requests or request/response communication models.
If the handheld and wearable devices are connected, the message is queued for delivery and a successful result code is returned. If the device is not connected, an error will be returned. Returning a successful result code does not indicate that the message was successfully delivered, as the device may disconnect after receiving the result code.

transfer data

ChannelClient can transfer data from handheld devices to wearable devices. With ChannelClient, you can do the following:
If automatic synchronization is not provided when using an Asset object attached to a DataItem object, you can synchronize between two or more connected devices when the Internet connection is not available. Transfer data files between devices. ChannelClient is more disk space efficient than DataClient, which creates a copy of the resource on the local device before synchronizing with the connected device.
Reliably send files that are too large to send using MessageClient.
Transmit streaming data, such as voice data from a microphone.

Synchronous Data

DataClient provides an API for components to read or write data to a DataItem or Asset.
DataItems are synced across all devices on a Wear OS network. Data items can be set without being connected to any node. These data items are synchronized when the node is connected to the network.
Data items are only visible to the application that created them, and can only be accessed by that application on other nodes. They are usually small. Use Assets to transfer larger, more persistent data objects such as images.
Wear OS allows multiple wearable devices to be connected to a single handheld device. For example, if a user saves a note on their handheld device, it will automatically appear on all of the user's Wear OS devices. To synchronize data between devices, Google servers host a cloud node within the device network. The system synchronizes data to directly connected devices, cloud nodes, and wearable devices connected to cloud nodes via Wi-Fi.
Warning: Content will be transferred to all available Wear OS devices, even ones that don't have your app installed. For handhelds and Wear OS devices, if you are syncing a large amount of data, consider checking that the Receiver app is installed and online to avoid wasting resources on both devices.

Listen to important data layer events (for services)

By extending WearableListenerService, you can listen to important data layer events in your service. The system manages the life cycle of the WearableListenerService, binding to the service when data items or messages need to be sent, and unbinding the service when no action is required.

Listen to important data layer events (for foreground activities)

By implementing OnDataChangedListener in an activity, you can listen for important data layer events while the activity is in the foreground. Using this listener instead of a WearableListenerService allows you to listen for changes only while the user is using your app.
Warning: Because these APIs are designed to communicate between handheld and wearable devices, you can only use these APIs to establish communication between these devices. For example, don't try to open the underlying socket to create a communication channel.

Client comparison

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

数据客户端	消息客户端	通道客户端
数据大小超过 100 KB。	是	否	是
可以向当前未连接的节点发送消息	是	否	否
通信模式	基于网络的共享资源	一对一消息传递（含响应）	一对一流式传输

Connectivity

The data layer has two communication options:

Exchange data directly after establishing a Bluetooth connection between the watch and other devices.
Exchange data over available networks such as LTE or Wi-Fi.

Figure 1. Example of a node network containing handheld and wearable devices.
All data layer clients can exchange data using Bluetooth or Google Cloud Sync, depending on the connectivity available to the device. Google uses the Cloud Sync service to communicate and exchange data between wearables and phones when Bluetooth is not available.

safety

Both communication methods, Bluetooth and the Cloud Sync service, are end-to-end encrypted.

To ensure secure and app-to-app communication between your phone and your watch, Google Play Services enforces the following restrictions.

Package names must be consistent across devices.
Package signatures must be consistent across devices.

Bluetooth

This connection is used by the data layer when connecting to a device using Bluetooth. When using Bluetooth, an encrypted channel is established between devices using standard Bluetooth encryption mechanisms (managed by Google Play services).

Cloud

It is assumed that data transferred using the data layer may sometimes use servers owned by Google. For example, when Bluetooth is not available, DataClient, MessageClient, or ChannelClient are automatically routed through Google Cloud. All data transmitted through Google Cloud is end-to-end encrypted.

Generate and store keys
The end-to-end key used for cloud communication is generated by the phone, and when the phone and watch are connected via Bluetooth, the key is exchanged directly to the watch. This process occurs during device setup. At no time will Google-owned servers receive these keys.

Communication via Google-owned servers is not possible until end-to-end keys are generated. The key is stored in the Google Play services private file store on all paired devices.

Device Backup
Keys are not backed up or exposed. If a new key is required (for example, for a new phone), the new key is generated and shared to the devices the user still owns.

The content and code examples on this page are subject to the license described in the Content License section. Java and OpenJDK are registered trademarks of Oracle and/or its affiliates.

Last updated (UTC): 2023-11-27.