好吧，交易到此为止。我有两部Galaxy Nexus手机，都启用了蓝牙。
我已经编写了一个蓝牙连接管理应用程序，用于设备发现和连接。它还输出设备可以支持的所有可用UUID。
从http://www.bluetooth.org/Technical/AssignedNumbers/service_discovery.htm以下标准UUID从Galaxy Nexus设备公开。
- 0x1116-NAP
- 0x112f-PBAP(电话簿访问配置文件)
- 0x111f-HFP(免提)
- 0x1105-OPP(对象推送配置文件)
- 0x1112-HSP(耳机模式)
- 0x110c-AVRCP
- 0x110a-A2DP
我正在尝试通过OPP配置文件(UUID 00001105-0000-1000-8000-00805F9B34FB)和设备之间的推送对象(文件)进行连接。我浏览了整个Android API文档，介绍如何发现、配对/绑定(线程等)和管理所有蓝牙连接。我已经成功地通过SPP(0x1101)配置文件连接并与传统板设备进行了交谈。
然而，当我尝试在两部galaxy nexus手机之间使用socket.connect()时，会显示配对对话框，并单击两台设备上的Pair按钮。之后，我立即得到了一个Connection Refused IOException。请注意，在配对后，我再也不会被问到这一点，因为安全链接是缓存的。
如果我不能使用这些标准UUID连接到这些标准配置文件，为什么会暴露它们？我如何从我的应用程序连接到这些配置文件并与它们交互？是因为我的应用程序在某种程度上不受信任吗？奇怪的是，即使是Android上的Share功能也根本不起作用。这是安卓系统上完全坏掉的东西吗？
请避免像文档中所说的那样提示我使用"众所周知的UUID SPP one 0x1101"。这不是我想要的。我对这些东西是如何工作的有相当好的理解，我正在寻找一个真正的解决方案或问题的解释。
我看到了典型的"反射"解决方案，但我不明白为什么这仍然是安卓系统上的一个问题？为什么人们会用反思来实现这一点？我们可以在安卓系统上提交一个bug来修复这个问题吗？
如果这些UUID是标准的，那么任何应用程序都应该能够与它们连接和交互。为什么这是一个问题，为什么我会得到这个例外？
提前谢谢。
更新
因此，出于某种原因，Android系统中的对象推送开始工作。实际上，我试图通过我的应用程序进行连接，但它不起作用。然后，我转到"联系人"应用程序，尝试共享一个神奇的联系人。然后，我回到我的应用程序，现在它工作了。。。哇！这很奇怪，必须对此做出解释。
我遇到了同样的问题，并设法找到了一个适合我的解决方案。
在我的情况下，我使用了三种不同的测试设备(Nexus 5、Galaxy S4和Note 2)，由于某种原因，Note 2无法连接到我的蓝牙模块，而其他两种会连接到。
我发现的原因是蓝牙驱动程序各不相同，在不同设备之间建立连接需要稍微不同的连接方法。
我使用的三种方法被称为"安全"、"不安全"one_answers"反射方法"/"最大"。
switch(connType)
{
case Secure:
tmpSocket = device.createRfcommSocketToServiceRecord(_uuid);
break;
case Insecure:
tmpSocket = device.createInsecureRfcommSocketToServiceRecord(_uuid);
break;
case Hax:
Method createSocket = device.getClass().getMethod("createRfcommSocket", new Class[] {int.class});
tmpSocket = (BluetoothSocket)createSocket.invoke(device, Integer.valueOf(1));
break;
}
就我而言，安全模式适用于Nexus 5和Galaxy S4，但不适用于Note 2。
经过一些测试，我发现Note 2只能使用"不安全"模式，因此为了满足这一点，我基本上会尝试连接，并在必要时循环使用不同的模式。当尝试不同的连接模式时，我只需提示"重试连接"。因此，如果使用secure连接失败，那么我将尝试使用Insecure，然后使用反射方法。
我还没有遇到过这三种方法中有一种不起作用的情况。
您尝试过使用非标准配置文件吗？即仅为您的应用程序定制的CCD_ 6。这也将帮助你知道你(很可能)只连接到自己的应用程序，而不是使用相同配置文件注册的其他应用程序。
根据我的经验，蓝牙配对在第一次尝试配对时非常麻烦。然而，使用自定义UUID在一定程度上有助于实现这一点。
反射方法(我认为)最初是试图用特定的设备修复错误，但我认为有些人在其他地方也成功地使用了它。这种设备被称为Spica或类似的东西。
正如其中一条评论所说，我也会在失败后再次尝试连接。
基本上，编写的代码计划在第一次尝试时失败，但如果失败，代码会在5秒内尝试再次连接。
这些都是不完美的解决方案，但Android上的蓝牙实现也不完美(IMHO)。希望能帮助
编辑
基于问题更新和评论：
我同意某些东西肯定有问题。我认为问题的一部分是BT驱动程序各不相同，每个驱动程序都有不同的BT堆栈，有不同的怪癖。我还发现了一个同时使用反射方法和自定义UUID以及其他标准方法的问题。这对我来说似乎很极端，但它确实涵盖了大部分领域。不幸的是，作为应用程序开发人员，我们无法控制低级别的堆栈/代码/驱动程序。
我发现我的两个蓝牙共享应用程序的第一次配对总是很棘手。
我很高兴知道不仅仅是我。