Android之蓝牙驱动开发总结Word文档下载推荐.docx

Android之蓝牙驱动开发总结Word文档下载推荐.docx

《Android之蓝牙驱动开发总结Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《Android之蓝牙驱动开发总结Word文档下载推荐.docx（38页珍藏版）》请在冰豆网上搜索。

7.4RebuildAndroidimageandreboot16

7.5实现BT睡眠唤醒机制16

7.6系统集成17

八Bluetooth之调试与编译17

8.1Bluetooth驱动调试17

8.2Bluetooth调试工具18

九Bluetooth之应用程序开发18

9.1Bluetooth的API开发18

9.2TheBasics开发18

9.3BluetoothPermissions开发19

9.4SettingUpBluetooth服务19

9.5FindingDevices服务20

9.6ConnectingDevices服务22

9.7ManagingaConnection服务26

9.8WorkingwithProfiles服务28

十总结与疑问29

一Bluetooth基本概念

蓝牙是无线数据和语音传输的开放式标准，它将各种通信设备、计算机及其终端设备、各种数字数据系统、甚至家用电器采用无线方式联接起来。

它的传输距离为10cm～10m，如果增加功率或是加上某些外设便可达到100m的传输距离。

它采用2.4GHzISM频段和调频、跳频技术，使用权向纠错编码、ARQ、TDD和基带协议。

TDMA每时隙为0.625μs，基带符合速率为1Mb/s。

蓝牙支持64kb/s实时语音传输和数据传输，语音编码为CVSD，发射功率分别为1mW、2.5mW和100mW，并使用全球统一的48比特的设备识别码。

由于蓝牙采用无线接口来代替有线电缆连接，具有很强的移植性，并且适用于多种场合，加上该技术功耗低、对人体危害小，而且应用简单、容易实现，所以易于推广。

蓝牙技术的系统结构分为三大部分：

底层硬件模块、中间协议层和高层应用。

底层硬件部分包括无线跳频（RF）、基带（BB）和链路管理（LM）。

无线跳频层通过2.4GHz无需授权的ISM频段的微波，实现数据位流的过滤和传输，本层协议主要定义了蓝牙收发器在此频带正常工作所需要满足的条件。

基带负责跳频以及蓝牙数据和信息帧的传输。

链路管理负责连接、建立和拆除链路并进行安全控制。

二AndroidBluetooth架构

2.1Bluetooth架构图

Android蓝牙系统分为四个层次，内核层、BlueZ库、BlueTooth的适配库、BlueTooth的JNI部分、Java框架层、应用层。

下面先来分析Android的蓝牙协议栈。

图1面向库的架构视图

Linuxkernel层：

bluez协议栈、uart驱动,h4协议,hci,l2cap,sco,rfcomm

bluez层：

这是bluez用户空间的库，开源的bluetooth代码，包括很多协议，生成libbluetooth.so。

library层：

libbluedroid.so等

framework层：

实现了Headset/Handsfree和A2DP/AVRCPprofile，但其实现方式不同Handset/Handfree是直接在bluez的RFCOMMSocket上开发的，没有利用bluez的audioplugin，而A2DP/AVRCP是在bluez的audioplugin基础上开发的，大大降低了实现的难度。

Android的蓝牙协议栈采用BlueZ来实现，BlueZ分为两部分：

内核代码和用户态程序及工具集。

图2面向进程的架构视图

2.2Bluetooth代码层次结构

（1）JAVA层

frameworks/base/core/java/android/bluetooth/

包含了bluetooth的JAVA类。

（2）JNI层

frameworks/base/core/jni/android_bluetooth_开头的文件

定义了bluez通过JNI到上层的接口。

frameworks/base/core/jni/android_server_bluetoothservice.cpp

调用硬件适配层的接口system/bluetooth/bluedroid/bluetooth.c

（3）bluez库

external/bluez/

（4）硬件适配层

system/bluetooth/bluedroid/bluetooth.c

包含了对硬件操作的接口

system/bluetooth/data/*一些配置文件，复制到/etc/bluetooth/。

还有其他一些测试代码和工具。

内核代码主要由BlueZ核心协议和驱动程序组成；

蓝牙协议实现在内核源代码net/bluetooth中，驱动程序位于内核源代码目录driver/bluetooth中。

用户态程序及工具集主要包括应用程序接口和BlueZ工具集，位于Android源代码目录externel/bluetooth（注：

Android版本不一样，有的在externel/bluez目录下）中。

三Bluetooth协议栈分析

3.1蓝牙协议栈

蓝牙协议栈的体系结构由底层硬件模块、中间协议层和高端应用层三部分组成。

（1）底层硬件模块

组成：

链路管理协议（LinkManagerProtocol，LMP）；

基带（BaseBand，BB）；

射频（RadioFrequency，RF）。

功能：

射频（RF）通过2.4GHz的ISM频段实现数据流的过滤和传输。

基带（BB）提供两种不同的物理链路，即同步面向连接链路（SynchronousConnectionOriented，SCO）和异步无连接链路（AsynchronousConnectionLess，ACL），负责跳频和蓝牙数据，及信息帧的传输，且对所有类型的数据包提供不同层次的前向纠错码（FrequencyErrorCorrection，FEC）或循环冗余度差错校验（CyclicRedundancyCheck，CRC）。

链路管理协议（LMP）负责两个或多个设备链路的建立和拆除，及链路的安全和控制，如鉴权和加密、控制和协商基带包的大小等，它为上层软件模块提供了不同的访问入口。

主机控制器接口（HostControllerInterface，HCI）是蓝牙协议中软硬件之间的接口，提供了一个调用下层BB、LMP、状态和控制寄存器等硬件的统一命令，上下两个模块接口之间的消息和数据的传递必须通过HCI的解释才能进行。

（2）中间协议层

逻辑链路控制和适配协议（LogicalLinkControlandAdaptationProtocol，L2CAP）；

服务发现协议（ServiceDiscoveryProtocol，SDP）；

串口仿真协议（或称线缆替换协议RFCOMM）；

二进制电话控制协议（TelephonyControlprotocolSpectocol，TCS）。

L2CAP位于基带（BB）之上，向上层提供面向连接的和无连接的数据服务，它主要完成数据的拆装、服务质量控制、协议的复用、分组的分割和重组，及组提取等功能。

SDP是一个基于客户/服务器结构的协议，它工作在L2CAP层之上，为上层应用程序提供一种机制来发现可用的服务及其属性，服务的属性包括服务的类型及该服务所需的机制或协议信息。

RFCOMM是一个仿真有线链路的无线数据仿真协议，符合ETSI标准的TS07.10串口仿真协议，它在蓝牙基带上仿真RS-232的控制和数据信号，为原先使用串行连接的上层业务提供传送能力。

TCS定义了用于蓝牙设备之间建立语音和数据呼叫的控制信令（CallControlSignalling），并负责处理蓝牙设备组的移动管理过程。

（3）高端应用层

点对点协议（Point-to-PointProtocol，PPP）;

传输控制协议/网络层协议（TCP/IP）;

用户数据包协议（UserDatagramProtocol，UDP）；

对象交换协议（ObjectExchangProtocol，OBEX）；

无线应用协议（WirelessApplicationProtocol，WAP）;

无线应用环境（WirelessApplicationEnvironment，WAE）；

PPP定义了串行点对点链路应当如何传输因特网协议数据，主要用于LAN接入、拨号网络及传真等应用规范。

TCP/IP、UDP定义了因特网与网络相关的通信及其他类型计算机设备和外围设备之间的通信。

OBEX支持设备间的数据交换，采用客户/服务器模式提供与HTTP（超文本传输协议）相同的基本功能。

可用于交换的电子商务卡、个人日程表、消息和便条等格式。

WAP用于在数字蜂窝电话和其他小型无线设备上实现因特网业务，支持移动电话浏览网页、收取电子邮件和其他基于因特网的协议。

WAE提供用于WAP电话和个人数字助理（PersonalDigitalAssistant，PDA）所需的各种应用软件。

3.2Android与蓝牙协议栈的关系

蓝牙系统的核心是BlueZ，因此JNI和上层都围绕跟BlueZ的沟通进行。

JNI和Android应用层，跟BlueZ沟通的主要手段是D-BUS，这是一套被广泛采用的IPC通信机制，跟Android框架使用的Binder类似。

BlueZ以D-BUS为基础，给其他部分提供主要接口。

四Bluetooth之HCI层分析

蓝牙系统的HCI层是位于蓝牙系统的L2CAP（逻辑链路控制与适配协议）层和LMP（链路管理协议）层之间的一层协议。

HCI为上层协议提供了进入LM的统一接口和进入基带的统一方式。

在HCI的主机（Host）和HCI主机控制器（HostController）之间会存在若干传输层，这些传输层是透明的，只需完成传输数据的任务，不必清楚数据的具体格式。

目前，蓝牙的SIG规定了四种与硬件连接的物理总线方式：

USB、RS232、UART和PC卡。

其中通过RS232串口线方式进行连接具有差错校验。

蓝牙系统的协议模型如图3所示。

图3Bluetooth协议模型

4.1HCI层与基带的通信方式

HCI是通过包的方式来传送数据、命令和事件的，所有在主机和主机控制器之间的通信都以包的形式进行。

包括每个命令的返回参数都通过特定的事件包来传输。

HCI有数据、命令和事件三种包，其中数据包是双向的，命令包只能从主机发往主机控制器，而事件包始终是主机控制器发向主机的。

主机发出的大多数命令包都会触发主机控制器产生相应的事件包作为响应。

图4底层协议通信图

命令包分为六种类型：

*链路控制命令；

*链路政策和模式命令；

*主机控制和基带命令；

*信息命令；

*状态命令；

*测试命令。

事件包也可分为三种类型：

*通用事件，包括命令完成包（CommandComplete）和命令状态包（CommandStatus）；

*测试事件；

*出错时发生的事件，如产生丢失（FlushOccured）和数据缓冲区溢出（DataBufferOverflow）。

数据包则可分为ACL和SCO的数据包。

包的格式如图5所示。

图5HCI包格式

4.2包的分析及研究

命令包：

命令包中的OCF（OpcodeCommandField）和OGF（OpcodeGroupField）是用于区分命令种的。

ParameterLength表示所带参数的长度，以字节数为单位，随后就是所带的参数列表。

下面以Inquiry命令为例对HCI的命令包做具体说明。

在Inquiry命令中，OGF=0x01表示此命令属于链路控制命令，同时OCF=0x0001则表示此命令为链路控制命令中的Inquiry命令。

OCF与OGF共占2字节，又由于底位字节在前，则它们在命令包为0x0104。

在Inquiry命令中，参数ParameterLength为5。

Inquiry命令带3个参数，第一个参数为LAP（lowaddresspart），它将用来产生Baseband中查询命令包的包头中的AccessCode。

第二个参数为Inquiry_Length，它时表示在Inquiry命令停止前所定义的最大时间，超过此时间，Inquiry命令将终止。

第三个参数为NUM_Response，它的值为0X00表示设备响应数不受限制，只为0x00-0xff则表示在Inquiry命令终止前最大的设备响应数。

因此，若LAP=0x9e8b00，Inquiry_Length=0x05，NUM_Response=0x05，则协议上层调用Inquiry命令是HCI向基带发的明令包将为：

0x010405008b9e0505。

事件包：

事件包的EventCode用来区分不同的事件包，ParameterLength表示所带参数的长度，以字节数为单位，随后就是所带的参数列表。

以CommandStatusEvent事件包为例对HCI的事件包进行具体说明。

当主机控制器收到主机发来的如上面所提到的Inquiry命令包并开始处理时，它就会向主机发送CommandStatusEvent事件包，此事件包为：

0x0f04000a0104。

0xOf表示此事件包为CommandStatusEvent事件包，0x04表示此事件包带4字节长度的参数，0x00为此事件包的第一个参数即Status，表示命令包正在处理。

0x0a为事件包的第二个参数NUM_HCI_Command_Packets，表示主机最多可在向主机控制器发10个命令包。

0x0104为第三个参数Command_Opcode，表示此事件包是对Inquiry命令包的响应。

数据包：

ACL和SCO数据包中的ConnectionHandle即连接句柄是一个12比特的标志符，用于唯一确认两台蓝牙设备间的数据或语音连接，可以看作是两台蓝牙设备间唯一的数据通道的标识。

两台设备间只能有一条ACL连接，也就是只有一个ACL的连接句柄，相应L2CAP的信道都是建立在这个连接句柄表示的数据通道上；

两台设备间可以有多个SCO的连接，则一对设备间会有多个SCO的连接句柄。

连接句柄在两设备连接期间一直存在，不管设备处于什么状态。

在ACL数据包中，Flags分为PBFlag和BCFlag，PBFlag为包的界限标志，PBFlag=0x00表示此数据包为上层协议包（如L2CAP包）的起始部分；

PBFlag=0x01表示此数据包为上层协议包（如L2CAP包）的后续部分。

BCFlag为广播发送的标志，BCFlag=0x00表示无广播发送，只是点对点的发送；

BCFlag=0x01表示对所有处于激活状态的从设备进行广播发送，BCFlag=0x02表示对所有的从设备包括处于休眠状态的从设备进行广播发送。

ACL和SCO数据包中的DataTotalLength都表示所载荷的数据的长度，以字节位单位。

4.3通信过程的研究与分析

当主机与基带之间用命令的方式进行通信时，主机向主机控制器发送命令包。

主机控制器完成一个命令，大多数情况下，它会向主机发出一个命令完成事件包（CommandCompletePacket），包中携带命令完成的信息。

有些命令不会收到命令完成事件，而会收到命令状态事件包（CommandStatusPacket），当收到该事件则表示主机发出的命令已经被主机控制器接收并开始处理，过一段时间该命令被执行完毕时，主机控制器会向主机发出相应的事件包来通知主机。

如果命令参数有误，则会在命令状态事件中给出相应错误码。

假如错误出现在一个返回CommandComplete事件包的命令中，则此CommandComplete事件包不一定含有此命令所定义的所有参数。

状态参数作为解释错误原因同时也是第一个返回的参数，总是要返回的。

假如紧随状态参数之后是连接句柄或蓝牙的设备地址，则此参数也总是要返回，这样可判别出此CommandComplete事件包属于那个实例的一个命令。

在这种情况下，事件包中连接句柄或蓝牙的设备地址应与命令包种的相应参数一致。

假如错误出现在一个不返回CommandComplete事件包的命令中，则事件包包含的所有参数都不一定是有效的。

主机必须根据于此命令相联系的事件包中的状态参数来决定它们的有效性。

五Bluetooth之编程实现

5.1HCI层编程

HostControllerInterface（HCI）是用来沟通Host和Module。

Host通常就是PC，Module则是以各种物理连接形式（USB,serial,pc-card等）连接到PC上的bluetoothDongle。

在Host这一端：

application,SDP,L2cap等协议都是软件形式提出的（Bluez中是以kernel层程序）。

在Module这一端：

LinkManager,BB,等协议都是硬件中firmware提供的。

而HCI则比较特殊，它一部分在软件中实现，用来给上层协议和程序提供访问接口（Bluez中,hci.chci_usb.c，hci_sock.c等）.另一部分也是在Firmware中实现，用来将软件部分的指令等用底层协议明白的方式传递给底层。

居于PC的上层程序与协议和居于Modules的下层协议之间通过HCI沟通，有4种不同形式的传输：

Commands,Event,ACLData,SCO/eSCOData。

（1）打开一个HCISocket---inthci_open_dev（intdev_id）:

这个function用来打开一个HCISocket。

它首先打开一个HCIprotocol的Socket（房间），并将此Socket与deviceID=参数dev_id的Dongle绑定起来。

只有bind后，它才将Socket句柄与Dongle对应起来。

注意，所有的HCICommand发送之前，都需要使用hci_open_dev打开并绑定。

（2）关闭一个HCISocket---inthci_close_dev（intdd）

简单的关闭使用hci_open_dev打开的Socket。

（3）向HCISocket发送request---inthci_send_req（intdd,structhci_request*r,intto）

BlueZ提供这个function非常有用，它可以实现一切Host向Modules发送Command的功能。

参数1：

HCISocket。

参数2：

Command内容。

参数3：

以milliseconds为单位的timeout.

下面详细解释此function和用法：

当应用程序需要向Dongle（对应为一个bind后的Socket）发送Command时，调用此function.

参数一dd对应一个使用hci_open_dev（）打开的Socket（Dongle）。

参数三to则为等待Dongle执行并回复命令结果的timeout.以毫秒为单位。

参数二hci_request*r最为重要,首先看它的结构：

structhci_request{

uint16_togf;

//OpcodeGroup

uint16_tocf;

//OpcodeCommand

intevent;

//此Command产生的Event类型。

void*cparam;

//Command参数

intclen;

//Command参数长度

void*rparam;

//Response参数

intrlen;

//Response参数长度

};

ogf,ocf不用多说，对应前面的图就明白这是GroupCode和CommandCode。

这两项

先确定下来，然后可以查HCISpec。

察看输入参数（cparam）以及输出参数（rparam）

含义。

至于他们的结构以及参数长度，则在~/include/net/bluetooth/hci.h中有定义。

至于event.如果设置，它会被setsockopt设置于Socket。

（4）得到指定DongleBDAddr---inthci_read_bd_addr（intdd,bdaddr_t*bdaddr,intto）；

HCISocket,使用hci_open_dev（）打开的Socket（Dongle）。

输出参数，其中会放置bdaddr.

（5）读写DongleName：

inthci_read_local_name（intdd,intlen,char*name,intto）

inthci_write_local_name（intdd,constchar*name,intto）

读取或设置Name。

注意：

这里的Name与IOCTLHCIGETDEVINFO得到hci_dev_info中的name不同。

（6）得到HCIVersion:

inthci_read_local_version（intdd,structhci_version*ver,intto）

（7）得到已经UP的DongleBDaddr---inthci_devba（intdev_id,bdaddr_t*bdaddr）；

dev_id:

DongleDeviceID.

bdaddr:

输出参数，指定Dongle如果UP，则放置其BDAddr。

（8）inquiry远程BluetoothDevice：

inthci_inquiry（intdev_id,intlen,intnrsp,constuint8_t*lap,inquiry_info**ii,longflags）

hci_inquiry（）用来命令指定的Dongle去搜索周围所有blueto