我在一个需要通过蓝牙连接到打印机的项目中工作。打印机制造商指出,只有具有SPP(串行端口配置文件)的android手机才能与打印机连接。

这是我最初打开连接的方式:

        UUID uuid = UUID.fromString("00001101-0000-1000-8000-00805F9B34FB"); //SPP long UUID
        BluetoothSocket socket = device.createRfcommSocketToServiceRecord(uuid);

从JellyBean开始,使用UUID是使用Android公共(public)API打开RFCOMM连接的唯一方法。之前在不需要UUID的BlackBerry和JavaME中使用SPP连接进行过工作,我发现这有点奇怪。 UUID与服务发现有关,即,使用SDP查询有关设备中存在的服务的信息。我真的不需要启动发现,因为我已经预先配对了打印机,而且我知道它支持SPP。但是,这正是BluetoothDevice.createRfcommSocketToServiceRecord方法和不安全版本所做的。这是SPP堆栈,在这里我们可以看到SDP在同一层如何是不同的协议(protocol),因此应该可以使用RFCOMM而不先启动发现:
        -----------------------------------
        |        My Application           |
        -----------------------------------
        |     Serial Port Emulation       |
        |          or other API           |
        -----------------------------------
        |      RFCOMM          |    SDP   |
        -----------------------------------
        |  LMP   |   L2PCAP               |
        -----------------------------------
        |           Baseband              |
        -----------------------------------

我开始在一些旧的HTC设备中测试我的应用程序,而没有出现问题。后来,在三星手机上进行测试,一些设备无法打开连接。根据制造商和第三方的规范,这些手机据称不支持SPP配置文件(编辑:第三方规范列出了受支持的SPP,并且制造商的规范不够准确)。引发了IOException(服务发现失败),并且我遵循了此问题中显示的方法:

Service discovery failed exception using Bluetooth on Android

此处提出的解决方案是使用反射黑客,如下所示:
        Method m = device.getClass().getMethod("createRfcommSocket", new Class[] {int.class});
        BluetoothSocket socket = socket = (BluetoothSocket) m.invoke(device, 1);

骇客为我工作。令人惊讶的是,BluetoothDevice类中的此方法是公共(public)的,但是通过@hide批注将其从API中删除。这是JellyBean的源代码:
        /**
         * Create an RFCOMM {@link BluetoothSocket} ready to start a secure
         * outgoing connection to this remote device on given channel.
         * <p>The remote device will be authenticated and communication on this
         * socket will be encrypted.
         * <p> Use this socket only if an authenticated socket link is possible.
         * Authentication refers to the authentication of the link key to
         * prevent man-in-the-middle type of attacks.
         * For example, for Bluetooth 2.1 devices, if any of the devices does not
         * have an input and output capability or just has the ability to
         * display a numeric key, a secure socket connection is not possible.
         * In such a case, use {#link createInsecureRfcommSocket}.
         * For more details, refer to the Security Model section 5.2 (vol 3) of
         * Bluetooth Core Specification version 2.1 + EDR.
         * <p>Use {@link BluetoothSocket#connect} to initiate the outgoing
         * connection.
         * <p>Valid RFCOMM channels are in range 1 to 30.
         * <p>Requires {@link android.Manifest.permission#BLUETOOTH}
         *
         * @param channel RFCOMM channel to connect to
         * @return a RFCOMM BluetoothServerSocket ready for an outgoing connection
         * @throws IOException on error, for example Bluetooth not available, or
         *                     insufficient permissions
         * @hide
         */
        public BluetoothSocket createRfcommSocket(int channel) throws IOException {
            return new BluetoothSocket(BluetoothSocket.TYPE_RFCOMM, -1, true, true, this, channel,
                    null);
        }

我不明白为什么以这种方式从API中删除了一个公共(public)方法。但是让此应用程序,此方法和使用UUID的官方支持方法都是薄信封,它们使用不同的参数调用相同的BluetoothSocket构造函数:
        public BluetoothSocket createRfcommSocketToServiceRecord(UUID uuid) throws IOException {
            return new BluetoothSocket(BluetoothSocket.TYPE_RFCOMM, -1, true, true, this, -1,
                    new ParcelUuid(uuid));
        }

在源代码中多挖一点,我意识到两者都打开了RFCOMM连接,但是UUID方法启动了一个发现,而隐藏的则没有。

总而言之,从我的OS 2.2到4.1,反射hacks在我测试过的每台设备上都可以完美工作。编辑:“有故障的”设备确实支持SPP,只是他们对BT堆栈的自定义实现使发现过程陷入了困惑;还有其他错误,例如ICS中已经配对的设备显示配对对话框的错误。使用反射调用此隐藏的API可以解决所有这些错误或由不同制造商引入的不同行为的变通办法。

我应该在生产代码中保留hack吗?有没有一种方法可以通过公共(public)API达到相同的目的?

提前致谢。

最佳答案

精湛的问题。基本上,您可以使用所有所需的反射。甚至我也做了类似的事情来计算应用程序的启动时间,通过反射获得了一种方法,它的工作方式从FroYo到Jelly Bean都很吸引人。您唯一需要注意的是,

  • 由于它不是公共(public)API,因此Google可以随时更改它而不会发出警告
  • 如果更改,则将相应地修改使用它的系统应用程序或HAL,而不会影响任何应用程序。

  • 您需要在哪里小心?



    因此,您需要在每个新的OS版本中进行检查,以确保您的应用程序不会损坏。否则,您不必担心使用此hack。当API暴露了很多东西时,许多应用程序都会使用这种黑客手段。

    09-07 01:59