查找附近的所有蓝牙设备(耳机、电话等),无需强制设备处于可发现模式 [英] Find all Bluetooth devices (headsets, phones etc) nearby, without forcing the devices in discoverable mode

查看:388
本文介绍了查找附近的所有蓝牙设备(耳机、电话等),无需强制设备处于可发现模式的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的目标:

从我的 Android 应用程序中检测所有附近的蓝牙设备(电话、耳机等).

To detect all nearby Bluetooth devices(phones, headsets, etc.) from my Android application.

这是 developer.android.com 的一个很好的例子,它发现附近的蓝牙设备带有已配对设备的列表.

Here's a nice example from developer.android.com which discovers the Bluetooth devices nearby along with the list of already paired devices.

我的情况:

我打开了两个蓝牙耳机,但在成功进行蓝牙扫描后没有检测到它们!所以我深入研究了这个问题,在某处发现蓝牙耳机需要切换到配对模式,以防被android检测到.

I had two Bluetooth headsets turned on and they were not being detected after a successful Bluetooth scan! So I dig into the problem and somewhere found that the Bluetooth headset needs to be switched to pairing mode in case of being detected by android.

要在配对模式下切换耳机,我必须在打开耳机时长按电源按钮.是的,最后,蓝牙耳机现在可以通过我的应用程序的扫描检测到.

To switch the headsets in pairing mode, I had to long-press the power button while turning them on. And yes, finally, the Bluetooth headsets are now detected by the scan from my application.

我的问题:

我希望无需将耳机切换到配对模式即可自动检测到它们.无法找到检测附近所有已开启蓝牙设备的方法.

I want my headsets will be detected automatically without switching them in pairing mode. Couldn't find a way to detect all nearby Bluetooth devices which are turned on.

推荐答案

所以,这是我在阅读有关 Android 蓝牙发现的博客、主题、文档、SO 答案等后发现的所有内容.认为这可能有助于在此处发布我的发现.

So, here's all I found after reading blogs, threads, documentations, SO answers etc. regarding Android's bluetooth discovery. Thought this might be useful to post my findings here.

因此,在有人开始阅读之前,我想澄清一下,我找不到任何方法来检测附近已打开但无法发现的蓝牙设备.

So before someone starts reading, I want to clarify that, I could not find any way to detect a bluetooth device nearby which is turned on but not discoverable.

我的主要目标是检测附近的所有蓝牙设备.为此,我们在 Android 中有一个 BluetoothAdapter 类,它有一个 startDiscovery 函数来扫描附近的蓝牙设备.因此,这不符合我的目的,因为蓝牙设备需要能够被 Android 的蓝牙扫描检测到.我想要的是检测附近的所有蓝牙设备而不强迫它们被发现.我开始寻找实现这一目标的解决方案.

My primary target is to detect all nearby bluetooth devices. To do so, we have a BluetoothAdapter class in Android which has a startDiscovery function to scan for bluetooth devices nearby. Hence, this doesn't serves my purpose, as the bluetooth devices need to be discoverable to be detected by a bluetooth scan by Android. What I want is to detect all Bluetooth devices nearby without forcing them to be discoverable. I started searching for a solution to achieve this goal.

我首先研究了蓝牙协议,并找到了用于蓝牙检测、连接和配对.对于 Android,我没有发现任何 API 可以发现/检测已开启但未处于可发现模式的 BT 设备.

I started with studying Bluetooth protocols and found the underlying protocols used for bluetooth detection, connection and pairing. For Android, I found no API to discover/detect BT devices which are turned on but not in discoverable mode.

在不强制蓝牙设备进入可发现模式的情况下深入研究这个检测问题,我们发现蓝牙设备在运行扫描附近的 BT 时会自动忽略标有 class 0×00 的蓝牙设备设备.这个问题在几个地方都有说明.我在这里列出了一些.

Digging into this detection problem without forcing the bluetooth devices to discoverable mode lead us to a point where we found Bluetooth device which advertises itself as class 0×00 is ignored automatically while running scan for nearby BT devices. This problem is stated in several places. Here I have listed some.

  1. Stackoverflow 问题
  2. Google 群组
  3. 讨论 DEV
  4. 在 HTC 设备中发现

我试图找到解决此问题的方法,是的,我找到了一个方法,尽管文档和评论以及此解决方法说,它不适用于所有类型的 Android 设备.无论如何,备用扫描与默认 BT 扫描相同,但它做了一些额外的工作.它会在 BT 扫描成功后读取 Android 日志,并检查是否有任何 BT 设备在操作过程中被跳过.这是此处描述的简单黑客.此处,有一个 google 小组讨论了相同的解决方法.

I tried to find a work-around of this problem and yes, I found one, though the documentation and reviews along with this work-around says, it doesn't work for all kind of Android devices. Anyway, the alternate scan is the same as the default BT scan, but it does some additional works. It reads the Android log after a successful BT scan and check if there's any BT device is skipped through out the operation. This is a simple hack described here . There's a google group discussing about the same work-around here.

上面的变通办法也不能解决我的问题.蓝牙耳机需要可被 BT 扫描检测到.当 Android 扫描附近的 BT 设备时,它们不会被跳过.他们根本找不到.

The work-around above doesn't solve my problem either. Bluetooth headsets need to be discoverable for being detected by a BT scan. They are not skipped while Android is scanning nearby BT devices. They are simply not found.

然而,我又开始寻找解决方案,又发现了一些有趣的东西!这是来自另一个 Stackoverflow 答案, 通过首先知道他的完整 MAC 地址,可以知道蓝牙设备是否在附近,即使他处于不可发现的模式中.我再次引用他的回答以供将来参考,

However, I started searching for a solution again and found something interesting again! This is from another Stackoverflow answer which says, It is possible to know whether a bluetooth device is around, even if he is in an undiscoverable mode, by knowing his full MAC address in the first place. I'm quoting again from his answer for future reference,

该技术是尝试 PAGE 请求,发送组成所寻找的蓝牙主机 MAC 标识符的所有 6 个字节.一个 PAGE 请求允许一个人在知道他的 BT ADDR 时与他的蓝牙从设备连接.处于不可发现模式的设备不会响应查询扫描(设备发现意图),但它们会响应要连接到另一个先前已知设备的设备所使用的页面扫描.

The technique is to try a PAGE request, sending all the 6 bytes that are composing the seeked Bluetooth host MAC identifier. A PAGE request allows one to connect with a Bluetooth slave when knowing his BT ADDR. Devices that are in undiscoverable mode does not respond to inquiry scan (device discovery intent), but they do respond to page scan which is used by a device wanting to connect to an another previously known device.

我找到了希望并开始寻找,我们如何在 Android 中启动页面扫描,但这次也失败了.找不到任何类型的 API 来启动页面扫描.从 BluetoothAdapter 类的 Android 文档中,我了解到,当 BT 扫描开始时,

I found hope and started searching for, how can we initiate a page scan in Android but failed this time too. Couldn't find any kind of APIs to initiate page scan. From Android documentation of BluetoothAdapter class, I came to know that, when a BT scan starts,

这通常涉及大约 12 秒的查询扫描,然后对每个新设备进行页面扫描以检索其蓝牙名称.

This usually involves an inquiry scan of about 12 seconds, followed by a page scan of each new device to retrieve its Bluetooth name.

Android 文档中有页面扫描的指示,但令人惊讶的是,在任何地方都没有关于页面扫描的其他文档.我提出了一个 Stackoverflow question 以供查询.

There is an indication of page scan in Android documentation, but, surprisingly, there is no other documentation regarding page scan anywhere. I put a Stackoverflow question for inquiry.

不,我没有找到任何方法.我阅读了 Android 的蓝牙配对是如何工作的.这是一个漂亮的流程图以及详细的阅读手册.我们试图使用 Android 的隐藏 API,并且可以使用反射来使用一些隐藏的 API.然后我们开始寻找可能用于实现我的目的的隐藏 API.但是,不幸的是,我们没有找到任何隐藏的 API 以编程方式在 Android 的已配对列表中添加 BT 设备.

No, I did not find any way to do so. I read about how Android's bluetooth pairing works. Here is a nice flow diagram along with detailed reading manual. We were trying to use Android's hidden APIs and could use some hidden APIs using Reflection. Then we started to look for hidden APIs which we might use to serve my purpose. But, unfortunately, we failed to find any hidden APIs to add a BT device in Android's already paired list programatically.

这里有一些有用的链接,用于检查蓝牙配对、隐藏的 API 以及如何通过反射调用它们以供将来参考.

Here are some helpful links to check for bluetooth pairing, hidden APIs and how to invoke them via reflection for future reference.

  1. 如何启动配对
  2. 如何使用反射来处理 Android 的隐藏 API
  3. 这是我关注的一个谷歌小组讨论,有些人面临同样的问题我们遇到的问题

因此,当 BT 设备处于可发现模式且不在 Android 的配对列表中时,我可以将其配对.就我而言,我使用了蓝牙耳机.它已打开并处于可发现模式.耳机的 BT 地址(MAC 地址)是已知的.所以我使用反射从我的代码中调用了函数 createBond 并且它工作得很好.该设备已成功添加到Android已配对"列表中.在四处寻找解决方案以达到我的目的时,我发现了一些有趣的事情......

So I could pair a BT device when it was in discoverable mode and was not in the paired list in Android. In my case, I used a bluetooth headset. It was turned on and put in discoverable mode. The BT Address (MAC address) of the headset was known. So I called the function createBond from my code using reflection and it worked perfectly. The device was added in the "already-paired" list of Android successfully. While roaming around for solutions to serve my purpose I found something interesting...

我发现,即使我从已经配对的列表中删除了之前配对的设备,android 也会在其内存中保留以前配对的设备.让我们分享一个案例研究以及这里的发现,以便更好地理解.就我而言,耳机之前已配对.

I found that, android preserves a previously paired device in its memory even if I remove it from the already-paired list. Let us share a case study along with the findings here for a better understanding. In my case the headset was paired previously.

  1. 从 Android 取消配对/忘记耳机
  2. 然后关闭耳机.
  3. 然后开始扫描附近的蓝牙设备
  4. 当然,没有找到耳机
  5. 但是我们查看了 Android 日志发现,Android 记住了该耳机的绑定状态(配对状态)的变化.
  6. 它扫描了之前绑定的耳机并报告远程设备已关闭

这里是打印了我们之前配对然后取消配对的耳机的MAC地址的日志.

Here is the log that printed along with the MAC address of the headset we paired before and then unpaired.

PREV_BOND_STATE = 11 // BOND_BONDING    (BluetoothDevice.java)
BOND_STATE = 10      // BOND_NONE
REASON = 4           // UNBOND_REASON_REMOTE_DEVICE_DOWN

然后,我再次进行了相同的测试,但这次我们打开了蓝牙耳机(无法发现).在这种情况下也没有发现耳机,但有趣的是,这次打印了不同的日志.

Then again, I ran the same test, but this time we turned the bluetooth headset on (not discoverable). The headset was not found in this case too, but the interesting thing is, this time a different log was printed.

PREV_BOND_STATE = 11 // BOND_BONDING    (BluetoothDevice.java)
BOND_STATE = 10      // BOND_NONE
REASON = 2           // UNBOND_REASON_AUTH_CANCELLED

REASON 已更改,因此我可以理解 Android 尝试与蓝牙耳机连接.耳机未处于可发现模式,但 Android 可以找到它并尝试与其连接,因为它之前在配对列表中.

The REASON is changed and hence I can understand Android tried to connect with the bluetooth headset. The headset was not in discoverable mode, yet Android could find it and tried to connect with it as it was in paired list before.

此日志是在运行蓝牙扫描时打印的,添加了 ACTION_BOND_STATE_CHANGED 操作和 intent.addAction.

This log was printed while a bluetooth scan was running with adding ACTION_BOND_STATE_CHANGED action with intent.addAction.

是的,但在这种情况下,Android 也需要将自己宣传为 BLE.这是 Android 中的新功能,目前并非所有设备都支持此功能.这是支持蓝牙 LE 广告的设备列表能力.但是,由于低功耗蓝牙广告具有非常低的功耗和高性能,我认为这将是 Android 的下一个大趋势.

Yes, but in that case Android needs to advertise itself as a BLE too. This is what new in Android and not all devices support this functionality till now. Here is a list of devices which support Bluetooth LE advertisement capability. But, as Bluetooth LE advertisement has a very low power consumption along with a high performance, I think this will be the next big thing in Android.

这里有一些对未来研究有用的链接.

Here are some helpful links for future research.

这篇关于查找附近的所有蓝牙设备(耳机、电话等),无需强制设备处于可发现模式的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆