Android 蓝牙

一、蓝牙介绍

蓝牙，是一种支持设备短距离通信（一般10m内）的无线电技术，能在包括移动电话、PDA、无线耳机、笔记本电脑、相关外设等众多设备之间进行无线信息交换。利用“蓝牙”技术，能够有效地简化移动通信终端设备之间的通信，也能够成功地简化设备与因特网Internet之间的通信，从而数据传输变得更加迅速高效，为无线通信拓宽道路。

蓝牙作为一种小范围无线连接技术，能在设备间实现方便快捷、灵活安全、低成本、低功耗的数据通信和语音通信，因此它是目前实现无线个域网通信的主流技术之一。与其他网络相连接可以带来更广泛的应用。是一种尖端的开放式无线通信，能够让各种数码设备无线沟通，是无线网络传输技术的一种，原本用来取代红外。

蓝牙技术是一种无线数据与语音通信的开放性全球规范，它以低成本的近距离无线连接为基础，为固定与移动设备通信环境建立一个特别连接。其实质内容是为固定设备或移动设备之间的通信环境建立通用的无线电空中接口（Radio Air Interface），将通信技术与计算机技术进一步结合起来，使各种3C设备在没有电线或电缆相互连接的情况下，能在近距离范围内实现相互通信或操作。简单的说，蓝牙技术是一种利用低功率无线电在各种3C设备间彼此传输数据的技术。蓝牙工作在全球通用的2.4GHz ISM（即工业、科学、医学）频段，使用IEEE802.11协议。作为一种新兴的短距离无线通信技术，正有力地推动着低速率无线个人区域网络的发展。

蓝牙技术的发展历程如下：

• 蓝牙1.0（1998年）：传输速率为723.1Kbps。

• 蓝牙1.1（2002年）：传输速率为810Kbps。

• 蓝牙1.2（2003年）：传输速率为1Mbps。

• 蓝牙2.0+EDR（2004年）：传输速率为2.1Mbps。

• 蓝牙2.1+EDR（2007年）：传输速率为3Mbps。

• 蓝牙3.0+HS（2009年）：传输速率为24Mbps。

• 蓝牙4.0（2010年）：传输速率为24Mbps。

• 蓝牙4.1（2013年）：传输速率为24Mbps。

• 蓝牙4.2（2014年）：传输速率为24Mbps。

• 蓝牙5.0（2016年）：传输速率为48Mbps。

• 蓝牙5.1（2019年）：传输速率为48Mbps。

• 蓝牙5.2（2020年）：传输速率为48Mbps。

蓝牙技术的传输原理是主从关系，一个主设备可以与7个从设备配对。在蓝牙通信中，主设备负责发起连接请求，从设备则负责响应连接请求。一旦连接建立，主设备和从设备之间就可以进行数据传输。

蓝牙技术分类

蓝牙协议包括两种技术：Basic Rate（BR）和Low Energy（LE），经典蓝牙我们一般说的是BT，低功耗蓝牙我们一般说成BLE。当设备支持蓝牙4.0时，还得进一步确认设备是支持BT单模、BLE单模还是BT和BLE都支持的双模。

低功耗蓝牙 (BLE)： 支持蓝牙协议4.0或更高的模块。主打低功耗，多用于物联网类型。

经典蓝牙( BT)： 指支持蓝牙协议在4.0以下的模块。主打短距离数据高速传输，多用于蓝牙耳机等。

经典蓝牙可再细分为：传统蓝牙和高速蓝牙。

传统蓝牙： 2004年推出，蓝牙2.0/2.1协议。

高速蓝牙： 2009年推出，蓝牙3.0协议，速率提高到约24Mbps，是传统蓝牙模块的八倍。

双模蓝牙： 即兼容BLE和BT，如手机，使用分时机制来达到同时与低功耗蓝牙和经典蓝牙设备通信。

从左到右依次为：经典蓝牙（BR/EDR）、双模蓝牙（同时支持BR/EDR/LE）和低功耗蓝牙（BLE）。其中经典蓝牙和低功耗蓝牙互不兼容。

Basic Rate（BR）

Basic Rate是正宗的蓝牙技术，可以包括可选（optional）的EDR（Enhanced Data Rate）技术，以及交替使用的（Alternate）的MAC（Media Access Control）层和PHY层扩展（简称AMP）

BR(Basic Rate): 蓝牙基础速率技术。

EDR(Enhanced Data Rate) : 蓝牙增强速率技术。

AMP (Alternate MAC/PHYs): 蓝牙核心系统的次要控制器,可切换的媒体访问控制器（Media Access Controller）和物理层（Physical Layer）。

Low Energy（LE）

上面所讲的BR技术的进化路线，就是传输速率的加快、加快、再加快。但能量是守恒的，你想传的更快，代价就是消耗更多的能量。而有很多的应用场景，并不关心传输速率，反而非常关心功耗。这就是Bluetooth LE（称作蓝牙低功耗）产生的背景。

LE技术相比BR技术，差异非常大，或者说就是两种不同的技术，凑巧都加一个“蓝牙”的前缀而已。后面我们会详细的解释这种差异，以及LE的行为特征。

LE(Low Energy): 蓝牙低功耗技术。

蓝牙参数

蓝牙协议

蓝牙协议规定了两个层次的协议，分别为蓝牙核心协议（Bluetooth Core） 和 蓝牙应用层协议（Bluetooth Application）。

蓝牙核心协议（Bluetooth Core）： 关注对蓝牙核心技术的描述和规范，它只提供基础的机制，并不关心如何使用这些机制。

蓝牙应用层协议（Bluetooth Application）： 是在蓝牙核心协议的基础上，根据具体的应用需求，定义出各种各样的策略，如FTP、文件传输、局域网等等

蓝牙核心协议（Bluetooth Core） 由 主机（Host）、控制器（Controller） 和 零个或多个 辅助控制器 组成。控制器又可分为主控制器 和 辅助控制器。两者在不同的蓝牙技术中（BR/EDR、AMP、LE），承担角色略有不同，但大致的功能是相同的，如下图。

控制器（Controller）： 负责定义RF、Baseband等偏硬件的规范，并在这之上抽象出用于通信的逻辑链路（Logical Link）。- 下图中整个蓝牙框架中有三种控制器，分别是BR/EDR Controller、LE Controller和AMP Controller。

主机（Host）： 负责在逻辑链路的基础上，进行更为友好的封装，这样就可以屏蔽掉蓝牙技术的细节，让 蓝牙应用层协议（Bluetooth Application） 更为方便的使用。

蓝牙核心协议	名称	含义	功能
控制器 （Controller）	PHY（Physical Layer）	物理层	1. 定义物理通道(Physical Channel)，带宽为2MHz的40个RF Channel。 2. 定义RF收发双方的特征（发射功率、调制方式等）。 3. 负责物理信道上数据的发送和接收。
		LL(Link Controller)	链路控制器	1. 编解码蓝牙数据包。蓝牙数据包为物理信道、逻辑传输和逻辑链路的相关数据负载和参数。 2. 携带链路控制协议信令（ BR/EDR）或链路层协议（LE），包括流控、确认、重传请求信令。
		Baseband Resource Manager	基带资源管理器	负责所有无线媒介的访问。 1. 时间调度器，负责给已协商约定的所有访问实体分配物理信道时间。 2. 协商约定，与访问实体协商访问参数，以便于给用户程序提供一个确定的QoS质量。 3. 时间调度和协商约定必须考虑到需要主控制器的所用行为，包括已连接设备在逻辑链路和逻辑通道上的所有数据交互，执行查询、连接、可被发现、可连接、可读等的无线媒介使用情况。
		LM(Link Manager)	链路管理器	负责创建、修改或释放逻辑链路，以及更新设备之间的相关物理链路参数。 1. 链路管理器利用链路管理协议（LMP, ER/EDR）或链路层协议（LL，LE）与远程蓝牙设备的链路管理器通信。 2. LM、LL协议允许在设备之间创建新的逻辑链路和逻辑通道，控制逻辑链路和通道的属性，如使能链路安全、调整BR/EDR物理链路的发送功率、逻辑链路的QoS设置。
		Device Manager	设备管理器	用于控制蓝牙设备的行为，负责除数据传输外的所有蓝牙系统的操作。 1. 搜索附近的蓝牙设备、连接蓝牙设备、标记本地蓝牙设备为可发现的、可连接的等。 2. 为了执行相应的功能，设备管理器需要访问基带资源管理器的传输媒介。 3. 设备资源管理器通过一系列HCI命令控制本地设备的行为，如管理设备名字，存储链路秘钥等。
主机(Host)	Channel Manager	信道管理器	主要负责创建、管理和关闭用于传输服务协议和应用层数据流的L2CAP信道。 1. 信道管理器利用L2CAP协议与远程（对端）终端上的信道管理器进行交互，以创建L2CAP信道。 2. 信道管理器与本地链路管理器或AMP PAL进行交互，以创建新的逻辑链路和配置这些链路，从而为传输数据提供所需的服务质量。
		L2CAP Resource Manager	L2CAP资源管理器	1. 主要负责管理传递给基带PDU片段的有序性和信道之间的调度， 以确保具有QoS承诺的L2CAP通道不会因为控制器资源耗尽而被拒绝访问物理通道。 2. 还可能执行流量一致性政策，以保证提交的L2CAP SDU在协商的QoS范围内。
		SMP（Security Manager Protocol)	安全管理协议	端对端协议。 1. 生成加密秘钥和身份标识秘钥，并存储。 2. 使用专有的固有的L2CAP信道。 3. 生成随机地址，并将随机地址解析为已知设备标识。 4. 直接与控制器交互，在加密和配对过程中提供加密和鉴权的秘钥。
		ATT(Attribute Protocol)	属性协议	端对端协议，服务器和客户端之间的协议。 1. ATT客户端通过专用的固定L2CAP通道与远程设备上的ATT服务端通信。 2. ATT客户端向ATT服务端发送命令、请求和确认。 3. ATT服务端向客户端发送响应、通知和指示。 4. ATT客户端的命令和请求提供了在ATT服务端的对等设备上读、写属性值的方法。
		GATT(Generic Attribute Profile)	通用属性规范	描述属性服务器的功能，选择性地描述属性客户端的功能。 1. 描述了服务层次、特点，以及属性服务器的属性。 2. 提供发现、读、写以及服务特点和属性的接口。
		SDP	服务发现协议	提供了应用发现可用服务以及确定可用服务特点的方法。 1. 为客户提供搜索所需要服务的能力. 2. 允许基于服务类型搜索服务 3. 可抑执行服务浏览，而不需预先知道服务特征. 4. 提供一种新的方法来搜索新的服务. 5. 提供一种机制来确定在设备离开客户设备邻频时，设备在何时变为不可用. 6. 提供对服务、服务类型和属性的唯一标识 7. 允许在一方设备上的客户在另一方设备上搜索服务，而无需查询第三方设备 8. 在复杂性不高的设备上使用. 9. 提供一种可发现更多服务信息的机制 10. 可通过中介代理支持服务搜索信息缓存 11. 可独立传输.
		AMP Manager Protocol	AMP管理协议	1. 使用专有的L2CAP信号信道与远程设备的AMP管理器进行通信。 2. 直接与AMP PAL交互，以便于AMP控制。 3. 发现远程AMP，并确定其有效性。 4. 收集远程AMP信息，以便于建立和管理AMP物理链路。
		GAP(Generic Access Profile)	通用访问协议	描述所有蓝牙设备的通用基本功能。 1. GAP服务包括：设备发现、连接模式、安全、鉴权、服务发现、关联模型。
AMP控制器 （辅控制器）	AMP PHY	AMP物理层
		AMP MAC	AMP MAC层
		AMP PAL	AMP协议适应层	AMP MAC与Host之间的接口。 1. 将Host命令或事件转化成MAC服务命令或事件，将MAC服务命令或事件转化为host能明白的命令和事件。 2. 支持AMP信道管理、基于特定流控模板的数据流量管理、电源效率管理等。
		AMP HCI	AMP主机控制器接口	AMP控制器与主机之间的逻辑接口。 1. 支持AMPs需要额外的与AMP物理信号和逻辑信道管理、QoS、流控相关的HCI命令和事件。 2. 一个AMP控制器对应一个HCI逻辑实体，一个BR/EDR控制器对应一个HCI逻辑实体。当多个控制器在同一个物理单元时，一个物理HCI传输层管理多个复用在同一物理传输线上的控制器。



蓝牙架构

如下为蓝牙的架构图：

HW层

这里就是蓝牙芯片层，包含以下几个部分

1）RF（RADIO）：射频层，本地蓝牙数据通过射频发送给远端设备，并且通过射频接收来自远端蓝牙设备的数据

2）BB（BASEBAND）：基带层，进行射频信号与数字或语音信号的相互转化，实现基带协议和其它的底层连接规程。

3）LMP（LINK MANAGER PROTOCOL）：链路管理层，负责管理蓝牙设备之间的通信，实现链路的建立、验证、链路配置等操作

4）HCI（HOST CONTROLLER INTERFACE）：主机控制器接口层，HCI层在芯片以及协议栈都有，芯片层面的HCI负责把协议栈的数据做处理，转换为芯片内部动作，并且接收到远端的数据，通过HCI上报给协议栈。

5）BLE PHY：BLE的物理层

6）BLE LL：BLE的链路层

TRANSPORT层

此部分在硬件接口（UART/USB/SDIO）实现HOST跟CONTROLLER的交互，此部分会分为以下几个协议，在后续章节会对transport协议做详细的说明

1）H2：USB的transport

2）H4: UART的transport

H4是UART传输种最简的一个Transport，只是在HCI raw data的前面加一个type就行，如下HCI一共有五种HCI data:

* HCI COMMAND:由蓝牙协议栈发送给芯片的命令

* HCI EVENT:由蓝牙芯片上报给蓝牙协议栈的事件

* HCI ACL:蓝牙协议栈跟蓝牙芯片双向交互的普通数据

* HCI SCO:蓝牙芯片跟蓝牙协议栈双向交互的通话/语音识别等音频数据

* HCI ISO（这部分是在core5.2才添加）:LE audio用的数据包格式

3）H5: UART的transport

4）BCSP: UART的transport

5）SDIO Transport,我不知道叫什么transport,但是有走SDIO的蓝牙芯片，比如Marvell8887，可以选择走SDIO或者UART

其中2,3,4的主要差别在于H4需要BT CHIP UART_TX/UART_RX/UART_CTS/UART_RTS/VCC/GND接到MCU，而H5,BCSP只需要BT CHIP的UART_TX/UART_RX/VCC/GND接到MCU就可以通信。

HOST层

此部分就是蓝牙协议栈

HCI（HOST CONTROLLER INTERFACE）

主机控制层接口，主要负责透过transport把协议栈的数据发送给蓝牙芯片，并且接受来自蓝牙芯片的数据，数据主要分为HCI COMMAND(HOST->CONTROLLER),HCI EVENT(HOST<-CONTROLLER),HCI ACL(HOST<->CONTROLLER),HCI SCO(这个有点些微差异，因为部分芯片的SCO数据不是透过TRANSPORT直接跟HOST沟通，而是通过特殊的引脚，PCM IN/OUT/SYNC/CLK脚来传输数据),core文档HCI的架构如下：

L2CAP（Logical Link Control and Adaptation Protocol）

逻辑链路控制与适配协议，将ACL数据分组交换为便于高层应用的数据分组格式，并提供协议复用和服务质量交换等功能。

通过协议多路复用、分段重组操作和组概念,向高层提供面向连接的和无连接的数据服务,L2CAP还屏蔽了低层传输协议中的很多特性，使得高层协议应用开发人员可以不必了解基层协议而进行开发。L2CAP 还支持可变长度的 L2CAP PDU（协议数据单元），以适应不同的应用需求。架构如下:

SDP（SERVICE DISCOVERY PROTOCOL）

服务发现(搜索)协议，服务发现协议(SDP)为应用程序提供了一种方法来发现哪些服务可用，并确定这些可用服务的特征。

由于蓝牙服务在不断增加，一个设备不可能也没有必要支持所有服务，所以需要在建立链接时获知哪些services可以提供，无法提供或未知服务如何处理，这就需要SDP来实现；SDP是一个user-initiated application，应用层通过SDP获知是否有必要打开通信服务，如RFCOMM，是否有特殊使用场景，如传输文件；SDP用于定位哪些服务可用，但是选择、接入、使用服务并不是SDP的范畴，需要参照具体的服务协议；

SDP的主要作用就是search：

a、搜索服务类；

b、搜索服务属性；

c、服务浏览；

如下图所示，SDP中分为client和server；server保存服务列表，client通过request向server获取；

SDP提供查询服务和属性的机制，但并不提供使用这些服务的机制；

如果多个应用在一个设备上提供服务，那么需要多个client使用SDP来查询servers，SDP client会根据servers距离client的RF proximity动态改变访问的server；

RFCOMM（Serial Port Emulation）

串口仿真协议，上层协议蓝牙电话，蓝牙透传SPP等协议都是直接走的RFCOMM。

RFCOMM是一种蓝牙协议，提供串行端口仿真，可用于连接到传统应用程序，也可用于蓝牙配置中的一些数据传输。RFCOMM支持两种类型的设备：类型1设备是通信路径的末端，支持RFCOMM之上的应用程序；类型2设备是中间设备，具有RFCOMM之上的物理RS-232串行端口。要建立RFCOMM连接，必须首先建立L2CAP连接。RFCOMM帧在L2CAP包的有效载荷字段中发送。一旦建立了L2CAP连接，就会回送RFCOMM控制帧，以建立数据链路连接标识符（DLCI）设置为0的信令信道。在此基础上，建立后续传输数据的通道。最多可以设置30个数据通道，因此RFCOMM理论上可以同时支持30种不同的服务。(实际上，大多数蓝牙设备都没有足够的资源来支持30种不同的服务。）RFCOMM基于GSM07.10标准，在蓝牙连接和GSM移动电话连接之间有一些细微的差别。RFCOMM不需要开始和结束标志，因为每个RFCOMM帧都是在一个L2CAP包中。且无需从网络中选取RFCOMM帧数据流，因此不需要标志位来标记帧的开始和结束位置。

OBEX

对象交换协议，蓝牙电话本，蓝牙短信，文件传输等协议都是走的OBEX。

HFP（Hands-Free）

蓝牙免提协议。一共分为两个角色：AG跟HF，举一个例子你一下就会懂，蓝牙耳机跟手机连接，那么手机的角色就是AG，蓝牙耳机的角色是HF。

HSP

蓝牙耳机协议，最开始的蓝牙耳机协议，目前已经没有产品在用这个了吧，至少我没有看到了。算是一个简化版的HFP。

SPP（SERIAL PORT PROFILE）

蓝牙串口协议。

IAP

苹果的特有协议，分为IAP1/IAP2，一般做Carplay或者iPod功能的人肯定接触过这块。

PBAP（Phone Book Access）

蓝牙电话本访问协议。此部分尤其注意，PBAP在V1.2跟V1.1架构变化很大，V1.1 PBAP直接走的RFCOMM，在V1.2的时候如果GOEP是V2.0版本，那么PBAP是直接走的L2CAP，并且是L2CAP ERTM mode，不是basic mode。

角色如下：同样举例说明，我们车载蓝牙跟手机连接，车载蓝牙下载手机的电话本，那么手机的角色就是PSE，车载蓝牙就是PCE。

MAP（MESSAGE ACCESS PROFILE）

蓝牙短信访问协议。MAP跟PBAP很像，都是在V1.2的时候架构有变化，V1.1 MAP直接走的RFCOMM，在V1.2的时候如果GOEP是V2.0版本，那么MAP是直接走的L2CAP，并且是L2CAP ERTM mode，不是basic mode。

OPP（OBJECT PUSH PROFILE）

对象推送协议。

AVCTP（AUDIO/VIDEO CONTROL TRANSPORT PROTOCOL）

音视频控制传输协议，是AVRCP的底层

AVDTP（AUDIO/VIDEO DISTRIBUTION TRANSPORT PROTOCOL）

音视频分布传输协议，是A2DP的底层

HID（HUMAN INTERFACE DEVICE）

人机接口协议，HID还是有很多广泛的用途的，比如蓝牙鼠标，蓝牙键盘，蓝牙自拍杆，蓝牙手柄等

A2DP（Advanced Audio Distribution）

蓝牙音乐协议，角色如下：举一个例子说明，还是拿蓝牙耳机跟手机连接，手机传输音乐给蓝牙耳机，那么手机就是A2DP source端，蓝牙耳机是A2DP sink端。

A2DP协议使用了Advanced Audio Coding（AAC）或者SBC（Subband Coding）等音频编码格式来压缩和解压缩音频数据。它还支持立体声音频传输，可以提供高保真的音质。

AVRCP（AUDIO/VIDEO REMOTE CONTROL PROFILE）

蓝牙音乐控制协议，角色如下:举例说明，哈哈，继续拿手机跟蓝牙耳机举例（前提是蓝牙耳机有上一首下一首的功能），那么蓝牙耳机就是controller(CT),手机就是target(TG)

ATT（Attribute Protocol）

蓝牙属性协议ATT，用于发现、读、写对端设备的协议(针对BLE设备)，ATT允许设备作为服务端提供拥有关联值的属性集 ，让作为客户端的设备来发现、读、写这些属性；同时服务端能主动通知客户端。

说到属性协议，我们就不得不提属性是什么，在ATT中属性分为3个内容：

属性类型(attribute type)，用UUID的形式来表现

属性句柄(attribute handle)，用于标识一个属性

属性权限(permissions), 控制是否该Attribute可读、可写、属性值是否通过加密链路发送！

ATT分为两个角色：Server/Client

GATT（Generic Attribute Profile）

GATT (Generic Attribute Profile) 是蓝牙低功耗 (Bluetooth Low Energy, BLE) 协议栈中的一部分，它定义了 BLE 设备之间交换数据的格式和规范。

GATT 是基于属性 (attribute) 和服务 (service) 的概念，通过将数据封装在属性中，从而实现设备之间的通信。

在 GATT 中，一个服务表示一个特定的功能，一个服务可以包含多个属性。

每个属性都有一个唯一的标识符 (UUID)，可以用来识别它们。属性可以是只读的 (Read)，也可以是可写的 (Write)。

属性还可以包含一个描述符 (Descriptor)，用于描述属性的特性和值。描述符是可选的，但是它们可以提供关于属性的额外信息，例如范围、单位或名称。

GATT 使用基于请求-响应模型的通信方式。当一个设备想要读取或写入属性时，它会发送一个请求给另一个设备，请求的格式包含要访问的属性的 UUID 和操作类型 (读或写)。接收方设备会根据请求返回响应消息，其中包含请求的数据，或者在写入操作时返回确认消息。

GATT 还定义了一些通用的属性和服务，例如设备信息服务 (Device Information Service)、电池服务 (Battery Service) 等，这些服务可以让开发人员更容易地实现常见的功能。

下图展示了GATT各层概念之间的包含关系：

2. 角色

在 GATT 中，存在两种角色：GATT Server 和 GATT Client。

（1）GATT Server

是指具有 GATT 数据的设备，它可以被 GATT Client 连接并提供服务。

GATT Server 存储着一个或多个服务，每个服务都包含一个或多个属性。当 GATT Client 连接到 GATT Server 时，它可以通过 GATT 协议来访问服务和属性。GATT Server 需要响应 GATT Client 的请求，例如读取和写入属性值。

（2）GATT Client

是指需要访问 GATT Server 的设备。GATT Client 可以扫描周围的 BLE 设备，找到包含 GATT 数据的设备，并连接到它们。一旦连接建立，GATT Client 可以通过 GATT 协议来读取和写入 GATT Server 上的服务和属性。例如，GATT Client 可以读取一个温度传感器的属性值，或者写入一个 LED 灯的属性值。

一个设备既可以作为 GATT Server，也可以作为 GATT Client。例如，一个智能手表可以作为 GATT Server，提供心率监测服务；同时，它也可以作为 GATT Client 连接到另一个设备，例如智能手机，以获取其他服务的数据，如来自手机的通知。

SM

蓝牙BLE安全管理协议

APP层

蓝牙应用层，比如要做耳机，做蓝牙HID设备，做车载，做蓝牙防丢器，做蓝牙穿戴设备等等

蓝牙服务

使用蓝牙对外提供服务的设备，需要有对应的服务功能，如蓝牙耳机，他需要提供音频播放的功能，这种具体的功能，就是蓝牙服务。这个服务分为服务、特性、属性三个部分：

服务（Service）

服务（Service） 可以理解一个房间，当这个房间为空的时候他什么也不是，不能提供任何的服务功能，所以，房间里面至少需要有一个或多个家俱，不同的家俱有不同的功能，这就是特性（Characteristic）。不同的服务（Service）应该有不同的编号(UUID)，用以区分不同的服务(Service)。就像我们有卧室、厨房、书房等不同的房间，为了统一，我们给这些不同功能的房间定义了各自的编号，我们假定卧室编号为0001，不管是哪家公司修建的卧室，都必须使用0001来表示这是卧室，当客人需要休息时，他只需要找到编号为0001的房间就行了。这样，不管是用英文、法文还是德语来给房间命名，我们都知道他是卧室。

特性（Characteristic）

特性（Characteristic） 是依附于某个服务（Service）的，就像前面说到卧室里的床，卧室并不能让我们睡觉休息，真正让我们睡觉休息的是床。在卧室里，我们除了放床，通常还可以放梳妆台、衣柜等相关的家俱，每样家俱可以提供与之相关的不同功能。同样，我们需要给每样家俱分配一个编号，这就是特性（Characteristic）的UUID。我们知道，每种家俱会有一个或多个不同的子功能，这个子功能就是特性（Characteristic）所包含的属性（Property） 。例如床单可以更换、床的高低可以调整。

属性（Property）

属性的概念就更好理解，这里就不再比喻。

通常的属性有如下几个：

Read： 读属性，具有这个属性的特性是可读的，也就是说这个属性允许手机来读取一些信息。手机可以发送指令来读取某个具有读属性UUID的信息。

Notify： 通知属性， 具有这个属性的特性是可以发送通知的，也就是说具有这个属性的特性（Characteristic）可以主动发送信息给手机。

Write： 写属性， 具有这个属性的特性是可以接收写入数据的。通常手机发送数据给蓝模块就是通过这个属性完成的。这个属性在Write 完成后，会发送写入完成结果的反馈给手机，然后手机再可以写入下一包或处理后续业务，这个属性在写入一包数据后，需要等待应用层返回写入结果，速度比较慢。

WriteWithout Response：写属性，从字面意思上看，只是写，不需要返回写的结果，这个属性的特点是不需要应用层返回，完全依靠协议层完成，速度快，但是写入速度超过协议处理速度的时候，会丢包。

什么是 UUID

前面说蓝牙服务的时候，我们多次提到了UUID，这UUID （Universally Unique Identifier）用于标识蓝牙服务以及通讯特征访问属性，不同的蓝牙服务和属性使用不同的访问方法，就像人们语言交流一样，语言相同才能正常交流（找到正确的UUID，才能使用正确的功能）。

简单理解UUID就是编号，对应不同服务的一个唯一的编号，用于区分不同的服务及服务特性的个体。服务和特性都有各自的UUID。为了明确标准的蓝牙服务，蓝牙技术联盟SIG定义UUID共用了一个基本的UUID：0x0000xxxx-0000-1000-8000-00805F9B34FB。总共128位，为了进一步简化基本UUID，每一个蓝牙技术联盟定义的属性有一个唯一的16位UUID，以代替上面的基本UUID的‘x’部分。使用16位的UUID便于记忆和操作，如SIG定义了“Device Information”的16位UUID为0x180A。也就是说，不管是什么样的蓝牙设备，只要你提供设备信息（Device Information） 的服务功能，就必须使用”0x180A“的UUID号。这样，当应用程序需要读取这蓝牙设备的设备信息时，只需要找到对应UUID号为0x180A的服务，就可以获取到。

蓝牙不同服务各自定义了“特征字段”用于实现数据访问，允许定义read、write、notification不同的特征属性，实现对应通道的读写操作，而“特征字段”也采用了UUID来唯一标识，如SIG在“DeviceInformation”服务下定义了“Manufacture Name String”实现“Read”属性，其16位UUID为0x2A29。

可见，蓝牙服务UUID以及服务特征字段，在蓝牙服务交互过程中起着非常重要的作用，而SIG标准中允许用户自定义服务，采用128位完成蓝牙服务，以及128位特征字段定义。

16位UUID的定义：



服务类名称	UUID	规格	许可用法
ServiceDiscoveryServerServiceClassID	0x1000	蓝牙核心规格	服务类
BrowseGroupDescriptorServiceClassID	0x1001	蓝牙核心规格	服务类
SerialPort	0x1101	串口配置文件 (SPP) 备注：SPP v1.0 中的 SDP 记录范例并不包含 BluetoothProfileDescriptorList 属性，但部分实 施中也可将此 UUID 用于配置文件标识符。	服务类/配置文件
LANAccessUsingPPP	0x1102	局域网访问配置文件 [已作废] 备注：可用作服务类标识符及配置文件标识符。	服务类/配置文件
DialupNetworking	0x1103	拨号网络配置文件 (DUN) 备注：可用作服务类标识符及配置文件标识符。	服务类/配置文件
IrMCSync	0x1104	同步配置文件 (SYNC) 备注：可用作服务类标识符及配置文件标识符。	服务类/配置文件
OBEXObjectPush	0x1105	物件推拉配置文件 (OPP) 备注：可用作服务类标识符及配置文件。	服务类/配置文件
OBEXFileTransfer	0x1106	文件传输配置文件 (FTP) 备注：可用作服务类标识符及配置文件标识符。	服务类/配置文件
IrMCSyncCommand	0x1107	同步配置文件 (SYNC)
Headset	0x1108	耳机配置文件 (HSP) 备注：可用作服务类标识符及配置文件标识符。	服务类/配置文件
CordlessTelephony	0x1109	无绳电话配置文件 (CTP) 备注：可用作服务类标识符及配置文件标识符。 [已作废]	服务类/配置文件
AudioSource	0x110A	高级音频分发配置文件 (A2DP)	服务类
AudioSink	0x110B	高级音频分发配置文件 (A2DP)	服务类
A/V_RemoteControlTarget	0x110C	音频/视频远程控制配置文件 (AVRCP)	服务类
AdvancedAudioDistribution	0x110D	高级音频分发配置文件 (A2DP)	配置文件
A/V_RemoteControl	0x110E	音频/视频远程控制配置文件 (AVRCP) 备注：可用作服务类标识符及配置文件标识符。	服务类/配置文件
A/V_RemoteControlController	0x110F	音频/视频远程控制配置文件 (AVRCP) 备注：AVRCP 规格 v1.3 及更新版本要求将 0x110E 纳入 ServiceClassIDList 的 0x110F 之前，以实现向后兼容。	服务类
Intercom	0x1110	内部通信系统配置文件 (ICP) 备注：可用作服务类标识符及配置文件标识符。 [已作废]	服务类
Fax	0x1111	传真配置文件 (FAX) 备注：可用作服务类标识符及配置文件标识符。 [已作废]	服务类
Headset – Audio Gateway (AG)	0x1112	耳机配置文件 (HSP)	服务类
WAP	0x1113	蓝牙技术作为 WAP 的互操作性要求，Bluetooth SIG [已作废]	服务类
WAP_CLIENT	0x1114	蓝牙技术作为 WAP 的互操作性要求，Bluetooth SIG [已作废]	服务类
PANU	0x1115	个人局域网配置文件 (PAN) 备注：可用作针对 PANU 角色的服务类标识符及配置文件标识符。	服务类/配置文件
NAP	0x1116	个人局域网配置文件 (PAN) 备注：可用作针对 NAP 角色的服务类标识符及配置文件标识符。	服务类/配置文件
GN	0x1117	个人局域网配置文件 (PAN) 备注：可用作针对 GN 角色的服务类标识符及配置文件标识符。	服务类/配置文件
DirectPrinting	0x1118	基本打印配置文件 (BPP)	服务类
ReferencePrinting	0x1119	参见基本打印配置文件 (BPP)	服务类
基本成像配置文件	0x111A	基本成像配置文件 (BIP)	配置文件
ImagingResponder	0x111B	基本成像配置文件 (BIP)	服务类
ImagingAutomaticArchive	0x111C	基本成像配置文件 (BIP)	服务类
ImagingReferencedObjects	0x111D	基本成像配置文件 (BIP)	服务类
免提	0x111E	免提配置文件 (HFP) 备注：可用作服务类标识符及配置文件标识符。	服务类/配置文件
HandsfreeAudioGateway	0x111F	免提配置文件 (HFP)	服务类
DirectPrintingReferenceObjectsService	0x1120	基本打印配置文件 (BPP)	服务类
ReflectedUI	0x1121	基本打印配置文件 (BPP)	服务类
BasicPrinting	0x1122	基本打印配置文件 (BPP)	配置文件
PrintingStatus	0x1123	基本打印配置文件 (BPP)	服务类
HumanInterfaceDeviceService	0x1124	人机接口设备 (HID) 备注：可用作服务类标识符及配置文件标识符。	服务类/配置文件
HardcopyCableReplacement	0x1125	硬拷贝电缆替代配置文件 (HCRP)	配置文件
HCR_Print	0x1126	硬拷贝电缆替代配置文件 (HCRP)	服务类
HCR_Scan	0x1127	硬拷贝电缆替代配置文件 (HCRP)	服务类
Common_ISDN_Access	0x1128	通用 ISDN 接入配置文件 (CIP) 备注：可用作服务类标识符及配置文件标识符。 [已作废]	服务类/配置文件
SIM_Access	0x112D	SIM 卡接入配置文件 (SAP) 备注：可用作服务类标识符及配置文件标识符。	服务类/配置文件
Phonebook Access – PCE	0x112E	电话簿访问配置文件 (PBAP)	服务类
Phonebook Access – PSE	0x112F	电话簿访问配置文件 (PBAP)	服务类
Phonebook Access	0x1130	电话簿访问配置文件 (PBAP)	配置文件
Headset – HS	0x1131	耳机配置文件 (HSP) 备注：参见勘误 #3507。 0x1108 及 0x1203 须纳入 ServiceClassIDList 的 0x1131 之前， 以实现向后兼容。	服务类
Message Access Server	0x1132	信息访问配置文件 (MAP)	服务类
Message Notification Server	0x1133	信息访问配置文件 (MAP)	服务类
信息访问配置文件	0x1134	信息访问配置文件 (MAP)	配置文件
GNSS	0x1135	全球导航卫星系统配置文件 (GNSS)	配置文件
GNSS_Server	0x1136	全球导航卫星系统配置文件 (GNSS)	服务类
​3D 显示	0x1137​	​3D 同步配置文件 (3DSP)	服务类
​3D 眼镜	​0x1138	​3D 同步配置文件 (3DSP)	服务类
​3D 同步	0x1139​	​3D 同步配置文件 (3DSP)	配置文件
​MPS 配置文件 UUID	​0x113A	​多配置文件规格 (MPS)	配置文件
​MPS SC UUID	​0x113B	多配置文件规格 (MPS)​	服务类
​CTN 访问服务​	​0x113C​	日历、任务和提醒 (CTN) 配置文件	服务类
​CTN 通知服务​	​0x113D	​​日历、任务和提醒 (CTN)配置文件	服务类
​CTN 配置文件	​0x113E	​​日历、任务和提醒 (CTN)配置文件	配置文件
PnPInformation	0x1200	设备识别 (DID) 备注：可用作服务类标识符及配置文件标识符。	服务类/配置文件
GenericNetworking	0x1201	不适用	服务类
GenericFileTransfer	0x1202	不适用	服务类
GenericAudio	0x1203	不适用	服务类
GenericTelephony	0x1204	不适用	服务类
UPNP_Service	0x1205	增强服务发现配置文件 (ESDP) [已作废]	服务类
UPNP_IP_Service	0x1206	增强服务发现配置文件 (ESDP) [已作废]	服务类
ESDP_UPNP_IP_PAN	0x1300	增强服务发现配置文件 (ESDP) [已作废]	服务类
ESDP_UPNP_IP_LAP	0x1301	增强服务发现配置文件 (ESDP) [已作废]	服务类
ESDP_UPNP_L2CAP	0x1302	增强服务发现配置文件 (ESDP) [已作废]	服务类
VideoSource	0x1303	视频分发配置文件 (VDP)	服务类
VideoSink	0x1304	视频分发配置文件 (VDP)	服务类
VideoDistribution	0x1305	视频分发配置文件 (VDP)	配置文件
HDP	0x1400	保健设备配置文件	配置文件
HDP Source	0x1401	保健设备配置文件 (HDP)	服务类
HDP Sink	0x1402	保健设备配置文件 (HDP)	服务类

蓝牙音频编码

蓝牙音乐采用一定的编码格式，如下是当前较为常用的几种音频传输格式和支持厂商。下面按照编码的码率由低到高列举。

SBC （Sub-band coding，子带编码）

最早的格式应该是SBC，SBC是A2DP（Advanced Audio Distribution Profile，蓝牙音频传输协议）协议强制规定的编码格式。所有的蓝牙都会支持这个协议，所以所有的蓝牙音频芯片也会支持这个协议。SBC编码在传输时的码率具体参数未找到，根据sony官网宣传给出的资料，是：328Kbps，44.1KHZ。这个码率其实和高品质的MP3差不多。但因为蓝牙传输中间设备是需要转码，以MP3文件为例，转码过程为 MP3->PCM->SBC->PCM, 每次转码都会损失细节，导致SBC的听感会比原始的MP3要差。

ACC（Advanced Audio Coding，高级音频编码）

ACC是杜比实验室为音乐社区提供的技术，是一种高压缩比的编码算法。实际体验上都认为同样的码率下面，ACC的听感比MP3好，apple上面ACC的音频很多。所以现在的iphone的音频传输格式也都是acc格式，码率与SBC相当，但听感据说好于SBC。因为没有做过严肃对比，暂且认为稍微好于SBC。

APTX

APTX是CSR公司的专利编码算法，在被高通收购后，APTX在安卓手机里面推广力度很大。

根据官网介绍，aptX分为三种：aptX，aptX HD和aptX Low Latency，根据名字可以认为，分别是传统aptX，高品质aptX（估计是提高码率）和低时间延迟aptX（在看视频和打CS的时候时间延迟就很重要了）。所以aptX其实传输码率估计也不高，可能和前面两者差不多，但是得益于高效的编码，使得声音保留的细节更多，实际听感好于前面两者，aptX的宣传也是称其可以达到CD级别的听感。

LDAC

现在轮到大法出场了，大法很简单粗暴的提高了信道，在支持LDAC的设备上面，蓝牙的通信码率接近1M。

LDAC可传输约3倍于普通Bluetooth*1的数据(在最高990kbps的传输速度下*2)，让你在无线情况下欣赏Hi-Res Audio*3音乐时，可以聆听到接近Hi-Res Audio的音质。

在这么高的传输速度下面，传输无损音乐成为了可能。当然，这种近乎私有协议的传输格式，也导致现在只有少量设备兼容。 但毫无疑问，LDAC在传输速率上获得了很大的提升，使得传输的音频品质更高，听感自然是最好的。

二、Android蓝牙子系统介绍

Android 提供了一个默认蓝牙堆栈，该堆栈具有以下两个层级：实现核心蓝牙功能的蓝牙嵌入式系统 (BTE) 以及与 Android 框架应用通信的蓝牙应用层 (BTA)。

架构

蓝牙系统服务通过 JNI 与蓝牙堆栈进行通信，并通过 Binder IPC 与应用通信。系统服务向开发者提供了对各种蓝牙配置文件的访问权限。下图显示了蓝牙堆栈的常规结构：

应用框架

处于应用框架级别的是应用代码，它利用 android.bluetooth API 与蓝牙硬件进行交互。此代码在内部通过 Binder IPC 机制调用蓝牙进程。蓝牙系统服务

蓝牙系统服务（位于 packages/apps/Bluetooth 中）被打包为 Android 应用，并在 Android 框架层实现蓝牙服务和配置文件。该应用通过 JNI 调用 HAL 层。

JNI

与 android.bluetooth 相关联的 JNI 代码位于 packages/apps/Bluetooth/jni 中。当发生特定蓝牙操作时（例如发现设备时），JNI 代码会调用 HAL 层并从 HAL 接收回调。

HAL

硬件抽象层定义了 android.bluetooth API 和蓝牙进程会调用的标准接口，并且您必须实现该接口才能使蓝牙硬件正常工作。蓝牙 HAL 的头文件是 hardware/libhardware/include/hardware/bluetooth.h。

蓝牙堆栈

系统为您提供了默认蓝牙堆栈。该堆栈会实现常规蓝牙 HAL，并通过扩展程序和更改配置对其进行自定义。

供应商扩展程序

要添加自定义扩展程序和用于跟踪的 HCI 层，您可以创建一个 libbt-vendor 模块并指定这些组件。

实现 HAL

蓝牙 HAL 位于 /hardware/libhardware/include/hardware/bluetooth.h 中。因此，bluetooth.h 文件包含蓝牙堆栈的基本接口，并且您必须实现其功能。

特定于配置文件的文件位于同一目录中。有关详情，请参阅  HAL 文件参考 。

以下是与配置文件相关的文件的部分列表。有关完整列表，请参阅/packages/modules/Bluetooth/system/include/hardware目录：

• bt_av.h：包含 A2DP 配置文件的接口定义。

• bt_gatt.h、bt_gatt_client.h 和 bt_gatt_server.h：包含 GATT 配置文件的接口定义。

• bt_hf.h：包含 HFP 配置文件的接口定义。

• bt_hh.h：包含 HID 主机配置文件的接口定义。

• bt_hl.h：包含 HDP 配置文件的接口定义。

• bt_mce.h：包含 MAP 配置文件的接口定义。

• bt_pan.h：包含 PAN 配置文件的接口定义。

• bt_rc.h：包含 AVRCP 配置文件的接口定义。

• bt_sock.h：包含 RFCOMM 套接字的接口定义。

自定义原生蓝牙堆栈

如果您使用的是默认蓝牙堆栈，但想要进行一些自定义设置，则可以执行以下操作：

• 自定义蓝牙配置文件 - 如果要添加没有由 Android 提供的 HAL 接口的蓝牙配置文件，则必须提供 SDK 插件下载方式，以使配置文件可供应用开发者使用，使这些 API 在蓝牙系统->进程应用 间可用，并将它们添加到默认堆栈。

• 自定义供应商扩展程序和配置更改 - 您可以通过创建 libbt-vendor 模块来添加内容，例如额外的 AT 命令或特定于设备的配置更改。

• 主机控制器接口 (HCI) - 您可以通过创建一个主要用于调试跟踪的 libbt-hci 模块来提供自己的 HCI。

• 蓝牙协议栈由BTIF、BTIF AV、BTU、BTA、BTE、BTM、HCI组成，他们的关系如下：

BTIF：提供bluedroid对外的接口

BTE：bluedroid的内部处理，又细分为BTA，BTU，BTM和HCI

BTA：bluedroid中各profile的逻辑实现和处理

BTU：承接BTA与HCI

BTM：蓝牙配对与链路管理

HCI：读取或写入数据到蓝牙hw

三、高通蓝牙子系统介绍

BT Audio

上行(手机声音数据通过BT Chip到SoC)：BT Driver通过UART读取BT Chip的数据，然后通过BT Stack进行数据解析，之后调用AudioTrack。

下行(BT Audio音频数据从SoC到外置AMP再通过Speaker出声音)：AudioTrack在收到BT Stack发来的数据后经过AudioFlinger和AudioHAL后到达TinyALSA，再经过高通AudioReach从Android侧的GSL FE到达QNX侧的GSL BE，然后经过GPR到达ADSP，再由ADSP通过TDM给到A2B芯片，再有A2B芯片通过A2B给到外置功放。

BT RingTone(本地铃声)

下行(BT RingTone 音频数据从Soc到外置AMP再通过Speaker出声音)：BT App调用AudioTrack播放本地铃声音频数据，AudioTrack在收到BT App发来铃声音频数据后后经过AudioFlinger和AudioHAL后到达TinyALSA，再经过高通AudioReach从Android侧的GSL FE到达QNX侧的GSL BE，然后经过GPR到达ADSP，再由ADSP通过TDM给到A2B芯片，再有A2B芯片通过A2B给到外置功放。

BT HFT

上行(HU侧通话声音通过Mic到SoC)：MIC数据通过ADC到达SoC的ADSP，在ADSP中经过ECNR处理后通过IIS发送给BT Chip，再由BT Chip发给近端手机，通过移动基站到达远端手机。

上行(手机侧通话声音通过BT Chip到Soc)：远端手机的通话声音通过移动基站达到近端手机后，再通过近端手机的BT Chip片到达车机的BT Chip，在Soc的BT Driver中读取通过IIS从BT Chip读取通话声音，然后给到BT Stack，之后BT Stack调用AudioTrack。

下行(BT HFT音频数据从Soc到外置AMP再通过Speaker出声音)：AudioTrack在收到BT Stack发来的数据后经过AudioFlinger和AudioHAL后到达TinyALSA，再经过高通AudioReach从Android侧的GSL FE到达QNX侧的GSL BE，然后经过GPR到达ADSP，再由ADSP通过TDM给到A2B芯片，再有A2B芯片通过A2B给到外置功放，另外给到ADSP的通话声音也要经过ECNR，作为ECNR的参考声音。

四、Android蓝牙子系统分类介绍

Android蓝牙子系统相关类如下：