Devices may establish a connection to the internet either directly using a Wi-Fi or cellular connection, or indirectly through a paired Bluetooth device.
Reachable and nearby nodes
A device is considered reachable when it's online and available to communicate with another device, either directly through Bluetooth or indirectly using the cloud as an intermediary.
A device is considered nearby if it can be connected directly through Bluetooth, without using the cloud.
Activities that affect reconnection time
Under certain circumstances, devices may require up to 4 minutes to re-establish a connection. These scenarios include the following:
- Wear OS device inactivity: If a Wear OS device is removed from the user's wrist or otherwise isn't actively used for an extended period, the reconnection time might be extended.
- Doze state: A handheld's power-saving Doze state can limit background processes, potentially increasing the device's reconnection time.
- User interaction: If the user starts interacting with both a handheld device and a Wear OS device at approximately the same time, it often expedites the reconnection process.
Discover all devices using a node client
A NodeClient object identifies and broadcasts to the list of Android-powered
devices connected to a network, regardless of the capability of each device. All
apps on a device receive these event notifications, such as a new device joining
the network or an existing device going offline.
The NodeClient class is particularly helpful for discovering devices that
don't have your app installed.
Discover specific devices using a capability client
A CapabilityClient object provides information about which devices on the
Wear OS network support specific app capabilities. 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. The Wear OS version of that app can use the
CapabilityClient to check whether the mobile version of the app is installed
on a nearby device and supports that feature. If it does, the Wear OS app can
show play and pause buttons so that users can control a video, which is playing
on their mobile device, from their Wear OS device. The capability broadcast
works in the opposite direction, too; Wear OS apps can list the capabilities
that they support.
Check for your app's new capabilities
Use the CapabilityClient to determine the node ID of a device you need to
communicate with. For example, if you need to check for the presence of a new
feature in your app on
handheld devices, create a capability for that new feature on the
handheld side. Your Wear OS app can then query for the devices that support that
capability. If the capability is missing on all devices, it means that the user
doesn't have a version of your app that supports this feature, which you should
gracefully handle in your app's logic. If you assume that the handheld device is
always the correct node to communicate with, your messages might end up not
being delivered, because the phone app does not support the feature.
Determine whether a Wear OS device is the only one on a network
You can use the CapabilityClient to check if your app must operate in
standalone mode because no other Android-powered devices are nearby. By
passing in FILTER_ALL, no other devices should appear in the results.