【IoT】Android/TI 蓝牙 profile 详解

1、TI BLE profile详解

BLE 协议栈的 GATT 层是设计用于应用程序在两个连接设备之间的数据通信。 

从 GATT 层的角度看，当设备连接后，将充当一下两种角色中的一个：

GATT Client —— 从 GATT 服务器读/写数据的设备
GATT Server —— 包含客户端需要读/写的数据的设备

GATT Client 和 Server 的角色完全独立于 BLE 的链路层的 slave 和 master 的角色，或 GAP 层 peripheral 和 central 的角色。

一个 slave 可以是 GATT Client 或 GATT Server，一个 master 同样可以是 GATT Client 或 GATT Server。
一个 GATT Server 可以有多个完成一个特定的功能或特性 GATT Server 组成。

在 SimpleBLEPeripheral（从机） 应用程序中有三个 GATT 服务:

Mandatory GAP Service —— 这个服务包含设备和访问信息，比如设备名称和供应商和产品标识，是一个部分的 BLE 协议栈，需要每个设备按照 BLE 协议栈规范。

Mandatory GATT Service ——这个服务包含有关服务器，是 BLE 的一部分协议栈，它要求每个 BLE 服务器设备按照 BLE 规范。

SimpleGATTProfile Service ——这个服务是一个示例配置文件，供测试和演示。

什么是 Profile？

为了更容易的保持 Bluetooth 设备之间的兼容， Bluetooth 规范中定义了Profile。 

Profile 定义了设备如何实现一种连接或者应用，你可以把 Profile 理解为连接层或者应用层协议。 
Bluetooth 的一个很重要特性，就是所有的 Bluetooth 产品都无须实现全部 的 Bluetooth 规范，你可根据所需要的产品实现需要的 Profile，不必给开发带来更大的开销。

这就是说当需要利用蓝牙提供数据传输功能时就必须建立对应的 Profile， TI 的 BLE 协议栈为我们提供了部分 Profile，其中一部分是非标准的 Profile。
其中非标准的有 SimpleGATTProfile 和 SimpleKeysProfile，我们将通过对这两个 Profile 的介绍及实验来了解 Profile 的特性和使用。
每个 Profile 初始化其响应的服务和内部寄存器。GATT 服务器将整个服务加到属性表中，并为每个属性分配唯一的句柄，GATT Profile 用于存储和处理 GATT 服务器中的数据。

一个GATT服务器通过一个称为属性表的表格组织数据，这些数据就是真正用于发送的数据。

属性包括：UUID、handle、Characteristic Values

handle：属性在GATT表中的索引，一个设备中每一个属性的句柄都是唯一的；
UUID：包含属性表中数据类型的信息，是理解属性表中的值得每一个字节的意义的关键信息；

在一个GATT表中可能有许多属性，但这些属性可能有相同的UUID。

2、Android Bluetooth Profile详解

SPP Serial Port Profile
A2DP Advanced Audio Distribution Profile
AVRCP Audio/Video Remote Control Profile
HID Human Interface Device Profile
HFP Hands-Free Profile

其中Media相关度比较大的是A2DP和AVRCP，做数据通信经常用到SPP

Bluetooth Profile的概念

Profile定义了一种基于蓝牙的应用，每个Profile规范主要包括针对开发者的接口，消息的格式和标准（例如音频压缩），使用蓝牙协议栈的组件等。
每一种Profile对应于一个UUID，Bluetooth种UUID的概念类似于TCP/IP中端口的概念，每一个UUID运行一种服务。

Bluetooth通过SDP(Service Discovery Protocol)来发现配对设备的所支持的Profile。
在Bluetooth Device的SDP Servie Daemon中，保存有支持的Service List和连接的Session等信息，SDP Client利用这些信息来完成Profile的发现和鉴别。
特殊说明的是，Bluetooth中比较基础的Profile有Generic Access Profile (GAP)和上述的SDP，此外，SPP通常作为其他Profile的实现基础。

Bluetooth UUID的概念

UUID的概念应用很普遍，是一种分布式（更确切说是局部式？）的ID生成方式。上述每种Profile均对应一个或多个UUID（同一Profile内不同UUID也对应不同的service）。

在Bluetooth SIG中已定义的Profile的UUID均采用如下方式生成：

BASE_UUID + uuid16 << 96 或 BASE_UUID + uuid32 << 96

其中，BASE_UUID为：

BASE_UUID 00000000-0000-1000-8000-00805F9B34FB

因此，Bluetooth SIG预定义的UUID仅在后32位（实际为96~112位）发生变化

例如，

A2DP_UUID 0000110B-0000-1000-8000-00805F9B34FB
在android的logcat种经常看到00805F9B34FB的字串

SPP

SPP是Android唯一完全开放的Bluetooth Profile，在Offical Tutorial中也采用00000000-0000-1000-8000-00805F9B34FB作为SPP的UUID。
事实上，SPP通信是一个很基本的方式，UUID完全可以自定义，但Device双方必须事先共享UUID。
具体实现上，SPP的编程方式非常接近于linux的Tcp socket. 一些共同的问题如client接入之后处理，另开线程等等都非常类似。

A2DP

A2DP是做音频和多媒体方面遇到比较多的一个Profile，在Android中已经包含了A2DP对应的API（大部为@hide）。需要自己用reflection的方式来获得对应的API。
相关的API与Android API Level的对应关系随后总结。

HID

HID是标准的键盘、鼠标等的输入输出，例如可以用这个Profile来实现一些简单的远程按键控制。
Android种HID的事件捕获与backKey等等方式相同，可以在使用View.OnKeyListener的onKey来捕获对应的keyCode。

AVRCP

AVRCP主要是对应一些媒体播放控制，基本可以等价于HID，例如PC的“多媒体键盘”上的音量键、播放暂停键等。
AVRCP事件可以看成HID的特殊情况，具体在Android的keybord layout中定义按键的具体含义。

HFP

在车载种经常用到的Profile，音频部分类似于A2DP，支持HFP和A2DP的设备，Bluetooth在蓝牙打开的情况下会自动连接。