问题点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的进行部分解析(但不解析报告描述符部分)；
/*******************************************************************/