使用数据层 API 发现网络上的设备
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
设备可以直接使用 Wi-Fi 或移动网络连接,也可以通过配对的蓝牙设备间接建立互联网连接。
可达的附近节点
当设备处于在线状态且可用于与其他设备通信(直接通过蓝牙或间接使用云端作为中介)时,即被视为“可连接”。
如果某个设备可以直接通过蓝牙连接而不使用云端,则会被视为附近设备。
影响重新连接时间的活动
在某些情况下,设备最多可能需要 4 分钟才能重新建立连接。这些场景包括:
- Wear OS 设备处于非活跃状态:如果将 Wear OS 设备从用户手腕上取下,或由于其他原因长时间闲置,重新连接时间可能会延长。
- 低电耗模式状态:手持设备的节能低电耗模式状态可能会限制后台进程,从而可能会增加设备的重新连接时间。
- 用户互动:如果用户大致同时开始与手持设备和 Wear OS 设备互动,通常会加快重新连接过程。
使用节点客户端发现所有设备
NodeClient
对象会识别连接到网络的一系列 Android 设备,并向其广播设备列表,而不管每个设备的功能如何。设备上的所有应用都会收到这些事件通知,例如有新设备加入网络或现有设备离线。
NodeClient
类特别适用于发现未安装应用的设备。
使用功能客户端发现特定设备
CapabilityClient
对象可提供有关 Wear OS 网络上的哪些设备支持特定应用功能的信息。功能是应用在构建时定义或在运行时动态配置的功能。
例如,移动 Android 应用可以通告其支持远程控制视频播放。该应用的 Wear OS 版本可以使用 CapabilityClient
检查该应用的移动版是否安装在附近的设备上并支持该功能。如果支持,Wear OS 应用可以显示播放和暂停按钮,以便用户通过 Wear OS 设备控制在移动设备上播放的视频。功能广播的运行方向也是相反的;Wear OS 应用可以列出其支持的功能。
检查应用的新功能
您可以使用 CapabilityClient
确定需要通信的设备的节点 ID。例如,如果您需要检查手持设备上的应用中是否存在某项新功能,请在手持式设备端为该新功能创建一项 capability。然后,您的 Wear OS 应用可以查询支持该功能的设备。如果所有设备上都缺少该功能,则意味着用户的应用版本不支持此功能,您应在应用逻辑中妥善处理该功能。如果您假定手持设备始终是与其通信的正确节点,那么您的消息可能最终可能无法传送,因为手机应用不支持该功能。
确定 Wear OS 设备是否是网络中唯一的设备
您可以使用 CapabilityClient
检查您的应用是否必须在独立模式下运行,因为附近没有其他 Android 设备。通过传入 FILTER_ALL
,结果中不应出现任何其他设备。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[null,null,["最后更新时间 (UTC):2025-07-27。"],[],[],null,["# Discover devices on a network using Data Layer APIs\n\nDevices may establish a connection to the internet either\ndirectly using a Wi-Fi or cellular connection, or indirectly through a paired\nBluetooth device.\n\nReachable and nearby nodes\n--------------------------\n\nA device is considered *reachable* when it's online and available to communicate\nwith another device, either directly through Bluetooth or indirectly using the\ncloud as an intermediary.\n\nA device is considered *nearby* if it can be connected directly through\nBluetooth, without using the cloud.\n\nActivities that affect reconnection time\n----------------------------------------\n\nUnder certain circumstances, devices may require up to 4 minutes to re-establish\na connection. These scenarios include the following:\n\n- **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.\n- **Doze state:** A handheld's [power-saving Doze state](/training/monitoring-device-state/doze-standby#understand_doze) can limit background processes, potentially increasing the device's reconnection time.\n- **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.\n\nDiscover all devices using a node client\n----------------------------------------\n\nA `NodeClient` object identifies and broadcasts to the list of Android-powered\ndevices connected to a network, regardless of the capability of each device. All\napps on a device receive these event notifications, such as a new device joining\nthe network or an existing device going offline.\n\nThe `NodeClient` class is particularly helpful for discovering devices that\ndon't have your app installed.\n\nDiscover specific devices using a capability client\n---------------------------------------------------\n\nA `CapabilityClient` object provides information about which devices on the\nWear OS network support specific app capabilities. A *capability* is a feature\nthat an app either [defines at build time](/training/wearables/data/messages#advertise-capabilities) or\n[configures dynamically at runtime](https://developers.google.com/android/reference/com/google/android/gms/wearable/CapabilityClient#addLocalCapability(java.lang.String)).\n\nFor example, a mobile Android app could advertise that it supports remote\ncontrol of video playback. The Wear OS version of that app can use the\n`CapabilityClient` to check whether the mobile version of the app is installed\non a nearby device and supports that feature. If it does, the Wear OS app can\nshow play and pause buttons so that users can control a video, which is playing\non their mobile device, from their Wear OS device. The capability broadcast\nworks in the opposite direction, too; Wear OS apps can list the capabilities\nthat they support.\n\nCheck for your app's new capabilities\n-------------------------------------\n\nUse the `CapabilityClient` to determine the node ID of a device you need to\ncommunicate with. For example, if you need to check for the presence of a new\nfeature in your app on\nhandheld devices, create a capability for that new feature on the\nhandheld side. Your Wear OS app can then query for the devices that support that\ncapability. If the capability is missing on all devices, it means that the user\ndoesn't have a version of your app that supports this feature, which you should\ngracefully handle in your app's logic. If you assume that the handheld device is\nalways the correct node to communicate with, your messages might end up not\nbeing delivered, because the phone app does not support the feature.\n\nDetermine whether a Wear OS device is the only one on a network\n---------------------------------------------------------------\n\nYou can use the `CapabilityClient` to check if your app must operate in\nstandalone mode because no other Android-powered devices are nearby. By\npassing in `FILTER_ALL`, no other devices should appear in the results."]]