2、蓝牙技术基础：蓝牙协议栈架构、经典蓝牙与BLE的区别、核心术语（GAP、GATT、L2CAP、HCI等）

蓝牙技术自1994年由爱立信提出以来，已经从最初的替代线缆方案演变为覆盖音频传输、数据通信、设备定位、Mesh组网等多种场景的无线通信标准。对于Android蓝牙驱动开发者而言，理解蓝牙协议栈的分层架构、掌握经典蓝牙（BR/EDR）与低功耗蓝牙（BLE）的本质差异，以及熟练运用GAP、GATT、L2CAP、HCI等核心术语，是进行驱动移植、协议调试和性能优化的前提。本章将从协议栈分层模型出发，逐步拆解各层职责，并通过对比表格和实战案例帮助读者建立完整的蓝牙技术认知框架。

上图展示了蓝牙协议栈的整体架构。从驱动开发视角看，HCI层是软件与硬件之间的关键分界点：HCI以上部分（主机协议栈）通常由操作系统内核或用户空间库实现，而HCI以下部分（控制器）则由蓝牙芯片固件完成。Android系统通过BlueDroid（经典蓝牙）和Floss（BLE）等协议栈实现主机侧功能，驱动开发者需要重点关注HCI传输层的适配（如UART、USB、SDIO）以及控制器固件的加载与通信。

2.1 蓝牙协议栈分层架构

核心原理：从物理层到应用层的职责划分

蓝牙协议栈采用分层设计，每一层只处理特定范围的通信任务，层与层之间通过标准接口交互。这种设计使得上层协议可以独立于底层硬件演进，也便于不同厂商的蓝牙芯片通过标准HCI命令接入主机。完整的协议栈可分为三大部分：控制器（Controller）、主机（Host）和应用层（Application）。控制器包含物理层（PHY）和链路层（Link Layer），负责射频信号的调制解调、数据包的发送接收、跳频、重传等底层操作。主机包含L2CAP、SDP、GAP、GATT、ATT等协议，负责逻辑链路的建立与管理、服务发现、数据封装与分发。应用层则通过Profile（如A2DP、HFP、HID）定义具体的应用场景。

在Android系统中，控制器通常由蓝牙芯片厂商提供固件实现，而主机协议栈则由系统组件bluetooth.default.so和libbt-vendor.so等库文件承载。驱动开发者的工作往往集中在HCI传输层（如通过UART或USB与蓝牙芯片通信）以及厂商特定扩展命令的实现上。理解分层架构有助于快速定位问题：例如，若设备无法被发现，问题可能出在GAP层的可发现模式配置，也可能出在链路层的扫描响应设置，甚至可能是射频天线的硬件故障。

判断方法：如何区分主机与控制器职责

在驱动开发中，判断某个功能属于主机还是控制器，可以通过HCI命令集来界定。HCI命令分为控制器命令（如HCI_Reset、HCI_LE_Set_Scan_Parameters）和主机命令（如HCI_Read_Local_Version_Information）。如果某个功能可以通过标准HCI命令实现，则属于控制器职责；如果需要主机协议栈参与逻辑处理（如GATT服务定义），则属于主机职责。例如，BLE广播数据的设置，广播内容由主机通过HCI_LE_Set_Advertising_Data命令下发，但广播的物理发送时序由控制器链路层管理。

案例拆解：UART传输层HCI通信异常排查

某项目使用高通WCN3990蓝牙芯片，通过UART接口与AP连接。设备在开机后蓝牙无法打开，logcat显示BluetoothService: failed to start。初步排查步骤：

1. 检查内核日志：dmesg | grep -i bluetooth，发现hci_uart驱动加载成功，但ttyHS0无数据流。
2. 使用hcitool dev命令查看HCI设备，无输出，说明HCI通道未建立。
3. 测量UART TX/RX引脚波形，发现TX有数据输出，但RX无响应，判断蓝牙芯片未上电或固件未加载。
4. 检查电源管理：发现bt_en GPIO未拉高，导致芯片处于复位状态。

最终通过修改设备树（DTS）中的bt_en GPIO配置，并增加固件加载时序延迟，问题解决。此案例说明，HCI传输层驱动不仅涉及数据收发，还包含电源控制、时钟管理和固件加载等配套逻辑。

常见误区与总结

• 误区一：认为HCI只是简单的串口透传。实际上HCI层需要处理数据分包、流控、错误恢复和电源管理。
• 误区二：混淆主机与控制器职责。例如，BLE的加密功能由控制器链路层完成，但密钥生成和配对流程由主机SMP管理。
• 总结：分层架构的核心价值在于解耦。驱动开发者应优先确保HCI通道稳定，再逐层向上调试协议功能。

2.2 经典蓝牙（BR/EDR）与低功耗蓝牙（BLE）的区别

核心原理：两种无线系统的设计哲学

经典蓝牙（Basic Rate/Enhanced Data Rate, BR/EDR）和低功耗蓝牙（Bluetooth Low Energy, BLE）虽然共享2.4GHz ISM频段，但它们是两套独立的无线系统，从物理层到应用层均有显著差异。BR/EDR设计目标是持续稳定的数据流传输，适合音频、文件传输等场景，支持79个信道（带宽1MHz），采用自适应跳频（AFH）和快速连接机制。BLE设计目标是极低功耗和突发短数据包传输，适合传感器、信标等场景，支持40个信道（带宽2MHz），其中3个为广播信道，37个为数据信道，采用跳频扩频（FHSS）和深度睡眠模式。

从协议栈角度看，BR/EDR使用SDP进行服务发现，使用L2CAP承载RFCOMM、AVDTP等协议；BLE则使用GATT（基于ATT）进行服务发现和数据交互，L2CAP仅作为ATT和SMP的传输载体。两者在连接建立、配对方式、数据传输速率和功耗特性上差异巨大。Android系统从4.3版本开始同时支持BR/EDR和BLE，但驱动层需要分别适配两套控制器配置。

判断方法：根据应用场景选择蓝牙类型

在Android驱动开发中，选择BR/EDR还是BLE取决于产品需求。如果应用需要持续传输音频流（如蓝牙音箱），必须使用BR/EDR的A2DP Profile；如果应用是低功耗传感器数据上报（如心率监测），则选择BLE的GATT服务。值得注意的是，双模蓝牙芯片（如CSR8675、QCC5124）可以同时支持两种模式，但驱动配置需要分别初始化两套协议栈参数。在Android的BluetoothAdapter中，可以通过isLeSupported()和isBrEdrSupported()方法检测芯片能力。

案例拆解：BLE连接参数更新导致功耗异常

某智能穿戴设备使用Nordic nRF52832芯片，通过BLE与Android手机通信。设备在连接后功耗异常升高，电池续航从7天降至2天。通过BLE抓包工具（如nRF Connect）分析，发现连接参数为：连接间隔30ms，从设备延迟0，超时时间2s。由于Android系统默认请求较短的连接间隔（如7.5ms），设备频繁唤醒收发数据。

1. 分析连接参数协商过程：Android主机发送Connection Parameter Update Request，请求间隔7.5ms。
2. 设备端固件未正确处理该请求，直接接受，导致功耗飙升。
3. 修改固件，在onConnectionParameterUpdateRequest回调中拒绝过短的间隔，并回复建议参数（如间隔50ms，延迟4）。
4. 重新测试，功耗恢复正常。

此案例说明，BLE驱动开发不仅涉及底层HCI命令，还需要理解连接参数协商机制，并在固件中实现合理的功耗管理策略。

常见误区与总结

• 误区一：认为BLE可以完全替代BR/EDR。实际上BLE不适合传输高质量音频或大数据量文件。
• 误区二：忽略双模芯片的共存问题。BR/EDR和BLE同时工作时，需要协调射频资源，否则可能互相干扰。
• 总结：选择蓝牙类型应基于应用场景的功耗、速率、时延和拓扑需求，驱动层需确保两种模式正确切换和共存。

2.3 核心术语详解：GAP、GATT、L2CAP、HCI

核心原理：四大协议的角色定位

GAP（Generic Access Profile）是蓝牙协议栈的顶层管理协议，定义了设备如何被发现、如何建立连接、如何进行安全配对。GAP规定了设备的角色（Broadcaster、Observer、Peripheral、Central），以及广播数据、扫描响应、连接参数等核心参数。在Android中，BluetoothAdapter的startDiscovery()和startLeScan()方法底层即调用GAP层的扫描和广播功能。

GATT（Generic Attribute Profile）基于ATT（Attribute Protocol）构建，定义了BLE设备之间数据交互的标准方式。GATT将数据组织为服务（Service）、特征（Characteristic）和描述符（Descriptor）的层级结构。每个特征包含属性值（Value）和属性权限（读、写、通知、指示）。Android的BluetoothGatt类封装了GATT客户端操作，而BluetoothGattServer用于实现GATT服务端。

L2CAP（Logical Link Control and Adaptation Protocol）位于HCI之上，负责将上层协议的数据封装为L2CAP数据包，并映射到HCI的ACL（Asynchronous Connection-Oriented）链路。L2CAP提供协议复用、分段重组、流量控制和错误重传功能。在BR/EDR中，L2CAP支持面向连接的通道（如RFCOMM）和无连接通道（如SDP）；在BLE中，L2CAP仅支持面向连接的通道，用于承载ATT和SMP。

HCI（Host Controller Interface）是主机与控制器之间的标准通信接口，定义了命令（Command）、事件（Event）和数据（Data）三种包格式。HCI传输层可以是UART、USB、SDIO或三线UART。Android驱动开发中，hci_uart驱动负责处理HCI数据包在UART上的收发，而bluetooth内核模块则负责HCI命令的解析和分发。

判断方法：如何选择正确的协议进行调试

当蓝牙设备出现连接失败、数据不完整或功耗异常时，需要根据现象判断问题所在的协议层。例如：

• 设备无法被发现 → 检查GAP层的广播参数（广播间隔、广播数据内容）和扫描响应设置。
• 连接建立后无法读写数据 → 检查GATT层的服务发现是否完成，特征属性是否正确配置。
• 数据包丢失或乱序 → 检查L2CAP层的流量控制参数（如MTU大小、窗口大小）。
• 蓝牙无法开启或频繁断开 → 检查HCI层的命令响应是否正常，传输层是否有数据错误。

案例拆解：GATT服务发现失败导致BLE连接异常

某医疗设备使用BLE传输血糖数据，Android App在连接后调用discoverServices()，但回调返回GATT_ERROR（133）。通过btmon抓取HCI日志，发现以下过程：

1. 连接建立成功，发送Exchange MTU Request（MTU=247）。
2. 设备回复Exchange MTU Response（MTU=247）。
3. 发送Discover All Primary Services请求。
4. 设备无响应，超时后返回错误。

分析发现，设备固件在收到MTU交换后，未正确处理后续的GATT请求。进一步检查设备端代码，发现ATT层处理函数在MTU更新后未重新初始化接收缓冲区，导致后续数据包解析失败。修复固件后，服务发现正常。此案例说明，GATT层问题往往源于ATT层的数据包处理逻辑，驱动开发者需要具备跨层调试能力。

常见误区与总结

• 误区一：将GAP和GATT混为一谈。GAP负责连接管理，GATT负责数据交互，两者在BLE协议栈中处于不同层次。
• 误区二：忽略L2CAP的MTU协商。BLE默认MTU为23字节，如果应用需要传输大数据，必须通过Exchange MTU协商更大的值，否则数据会被截断。
• 误区三：认为HCI命令是标准化的，无需关注厂商扩展。实际上，许多蓝牙芯片（如高通、博通）都有私有HCI命令用于射频校准、固件升级等，驱动开发需要查阅芯片手册。
• 总结：掌握GAP、GATT、L2CAP、HCI四大协议是蓝牙驱动开发的基础。建议开发者通过btmon和Wireshark等工具，建立从HCI事件到应用层回调的完整映射关系，从而快速定位问题。