[Android源码解析]蓝牙扫描结果反馈的分析

       在前面两篇文章中，晓东和大家一起分析了android是如何向蓝牙发送扫描命令的，这篇文章我们将继续来看，蓝牙在收到扫描命令之后是如何向android上层反馈搜索到的设备以及上层对这些搜索到的设备是如何进行进一步处理的。

7、inquiry result event的分析

         Inquiry result的意思大概就是在收到inquiryresponse的时候会从controller回应这个event上来，需要注意的是一个event可能会有多个response，并不是一个response对应一个event。

         7.1 inquiry resultevent在spec中的定义

    它在spec中的格式如下所示：

其中各个参数的意思如下：

Num_Responses：表示response的设备数目。上文我们有提到一个event是可以包含多个response的，这里就是表明究竟有多少个response的。

BD_ADDR：这个很好理解，就是每个response的bd addr。是按照顺序存储的，每个占6byte。

Page scan repetition mode:这个其实大家也不要太关心,大概的意思就是page的时候采取的策略.他们具体的差别在于:

         R0对连接的时间要求很严格,并且pagingdevice需要有很好的clock,在这种模式下，别的连接是完全没有机会进来的。当然总的来说,他的功耗也是最大的.

         R1可以理解为连接时间要求还是很严格（和R0接近），但是设备没有足够好的蓝牙clock，就会建议使用这个模式，在这种模式下，别的设备时有机会连接上来的，当然功耗就没有R0大了，可以说他是R0和R1之间的一个模式。

         R2 就是连时间要求都不是那么的严格了。其他就更不谈了，功耗当然也不是很大的。

         Reserved1和2这两个都是在早起的spec中才看到，v1.1之前。现在4.1都要出来了，所以我们就不用管了。

         Class of device：这个表示设备的类型。他分为主要设备类和次要设备类。其中主要设备类是其中的[12:8]位来表示，次要设备类是其中的[7:2]位来表示。

              主要设备类表

12	11	10	9	8	主要设备类
0	0	0	0	0	其他 [Ref #2]
0	0	0	0	1	计算机（台式机、笔记本、PDA、organizer ....）