Android Bluetooth HID Host的理解及Report Data如何写入Android 节点之三

问题点8：为何原生BT 中的HID Host在收到中断Report Data时不需解析；

从以上flow我们看到，从中断通道(Interrupt Channel)的report data其实并没有解析，而是通过API bta_hh_co_write最后写入到节点"/dev/uhid"中，此过程并没有去解析report内容；

(详看后续分析：不是不需解析，而是真正的解析是在Android 系统内部, 好处是：蓝牙和USB HID 共用同一套report descriptor parser)

Attention：在实测前，我们推测其是通过设置为Boot Protocol Mode来解析固定格式report data来避开需要Parser的问题,但实测后发现和我们想象的完全不一样

/******************************************************************/

以下是Boot Protocol Mode的HID Spec 描述

其中当HID Host和HID Device 处于Report Protocol mode时，HID Host必须解析HID Device SDP中的report descriptor来了解HID Device的具体发送格式以及发送内容；

其中当HID Host和HID Device 处于Boot Protocol mode时，HID Host并不需要报告描述符解析器(HID report descriptor parser)：

 

 /******************************************************************/

我们使用市场上主流的传统蓝牙游戏手柄(非BLE)和Android手机进行实测，此游戏手柄在SDP中表明其不支持Boot Protocol Mode，但此时Android手机还是可以正常响应手柄的按键操作；

 原因分析：既然没有Report Protocol Mode Parser，那为何把Report Data 通过API bta_hh_co_write直接丢给Android 系统，其就能识别？

从目前实际看到的是，在SDP问询后有信息被写入到Android 系统中，通过API

bta_hh_co_send_hid_info；

 

所以从SDP接收到的report descriptor , 其实直接传送给Android 系统进行解析；

/*******************************************************************/

延伸问题点：SDP中收到的报告描述符(report descriptor)是如何传送到Android系统的；

从之前tracing了解到，SDP 问询的Callback API 是hidh_search_callback

-->可以看到进行SDP 问询时，调用的API 是SDP_ServiceSearchRequest，留意其第二个参数；此函数把问询到的数据填充到第二个参数中，问询完成时通过第三个函数callback返回；

-->当SDP问询完成时，函数hidh_search_callback被执行，在此函数内部，可以看到其对获取的数据，针对UUID是0x1124的进行部分解析 (但不解析报告描述符部分)；

 

 

 /*******************************************************************/