我应该在生产代码中留下蓝牙反射黑客吗？

Question

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

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

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

使用UUID是从JellyBean开始使用Android公共API打开RFCOMM连接的唯一方法.之前曾在BlackBerry和JavaME中使用SPP连接,不需要UUID,我发现这有点奇怪.UUID是关于服务发现的,即使用SDP来查询设备中存在的服务.我真的不需要发现一个发现,因为我的打印机已提前配对,我知道它支持SPP.然而,这正是BluetoothDevice.createRfcommSocketToServiceRecord方法和不安全版本所做的.这是SPP堆栈,我们可以在其中看到SDP是如何在同一层的不同协议,因此应该可以在不首先启动发现的情况下使用RFCOMM:

        -----------------------------------
        |        My Application           |
        ----------------------------------- 
        |     Serial Port Emulation       |
        |          or other API           |
        -----------------------------------
        |      RFCOMM          |    SDP   |
        -----------------------------------
        |  LMP   |   L2PCAP               |
        -----------------------------------
        |           Baseband              |
        -----------------------------------

我开始在一些旧的HTC设备上测试我的应用程序没有问题.后来,在三星手机上测试时,有几台设备无法打开连接.根据制造商和第三方规范,这些手机据称不支持SPP配置文件(编辑:第三方规格列表SPP支持,制造商规格不够准确).抛出了IOException(Service Discovery failed),我按照这个问题中显示的方法:

在Android上使用蓝牙的服务发现失败异常

提出的解决方案是使用反射黑客,如下:

        Method m = device.getClass().getMethod("createRfcommSocket", new Class[] {int.class});
        BluetoothSocket socket = socket = (BluetoothSocket) m.invoke(device, 1);

黑客为我工作.令人惊讶的是,这个BluetoothDevice类中的方法是公共的,但它通过@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中删除公共方法.但是让这个appart,这个方法和使用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,反射技术在我测试过的每个设备中都能完美运行.编辑:"有缺陷"的设备确实支持SPP,只是他们的BT堆栈的自定义实现搞乱了发现过程; 还有一些其他错误,例如显示ICS中已配对设备的配对对话框.使用反射调用此隐藏的API可以解决所有这些错误或不同制造商引入的不同行为.

我应该保留生产代码吗？有没有办法用公共API实现相同的目标？

提前致谢.

Answer 1

精湛的问题.基本上你可以使用你想要的反射.即使我做了类似的事情来计算应用程序启动时间,通过反射得到一个方法,它的工作就像从FroYo到Jelly Bean的魅力.你需要运用的唯一警告是,

• 由于它不是公共API,谷歌可以随时更改它而不会发出警告
• 如果更改,系统应用程序或使用它的HAL将相应地进行修改,而不会影响任何应用程序.

你需要小心在哪里？

机会是这种方法的论据可能在将来被修改.

因此,您需要在每个新的操作系统版本中检查这一点,以便您的应用程序不会中断.否则你不必担心使用这个hack.许多应用程序在API未暴露时会使用此类黑客攻击.