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](https://developer.android.com/training/monitoring-device-state/doze-standby#understand_doze) 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](https://developer.android.com/training/wearables/data/messages#advertise-capabilities) or
[configures dynamically at runtime](https://developers.google.com/android/reference/com/google/android/gms/wearable/CapabilityClient#addLocalCapability(java.lang.String)).

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.