第二章：Android Automotive蓝牙架构：从Application到Bluetooth Stack的层级调用，AIDL接口设计
好，咱们接着聊。上一章我讲了车载蓝牙的整体轮廓，这一章咱们深入进去，看看Android Automotive里蓝牙到底是怎么一层层调用的。
说白了，你按下一个“连接手机”的按钮，背后发生了什么？
嗯，这中间要穿过好几层代码。从你手指触碰屏幕的App层，一路跑到最底层的蓝牙芯片里。每一层都有自己的职责，每一层都通过特定的接口跟邻居打交道。
2.1 四层架构：谁在跟谁说话？
我个人习惯把Android Automotive的蓝牙架构分成四层。你想想看，就像公司里的四个部门：
- Application层：这是用户能看到的。比如设置里的蓝牙开关、电话应用、音乐播放器。它们只关心“我要连手机”、“我要打电话”，不关心蓝牙协议细节。
- Framework层：这是中间管理层。它把App的请求翻译成系统能懂的命令。比如App说“我要扫描设备”，Framework就调用BluetoothAdapter的startDiscovery()。
- Bluetooth Stack层：这是真正的技术核心。它实现了HCI、L2CAP、RFCOMM、AVRCP、HFP这些协议。我在项目中遇到过，很多第三方Stack在这里埋坑，比如HFP的AT指令解析不完整。
- Vendor层：芯片厂商的驱动。比如高通、MTK、瑞昱的蓝牙芯片，它们通过HCI协议跟Stack通信。说白了，这一层是硬件相关的。
这四层之间怎么通信？靠的就是AIDL和HIDL。嗯，这里要注意，Android Automotive里大量使用AIDL来做跨进程通信。
2.2 AIDL接口设计：跨进程的“翻译官”
为什么需要AIDL？因为App跑在应用进程，Framework跑在系统进程，Stack跑在蓝牙进程。它们不在同一个内存空间里，不能直接调用对方的方法。
AIDL就是那个“翻译官”。它定义好接口，让不同进程能像调用本地方法一样调用远程方法。
我记得在Android 12之前，蓝牙的AIDL接口还比较混乱。Google后来做了统一，现在主要用这几个核心接口：
| 接口名称 | 作用 | 调用方向 |
|---|---|---|
| IBluetooth | 蓝牙开关、扫描、配对等基础操作 | Framework → Stack |
| IBluetoothGatt | BLE GATT相关操作 | Framework → Stack |
| IBluetoothHeadset | HFP免提协议操作 | Framework → Stack |
| IBluetoothA2dp | A2DP音频流操作 | Framework → Stack |
| IBluetoothCallback | 状态变化回调给Framework | Stack → Framework |
你看，这些接口都是成对出现的。一个负责下发命令，一个负责上报状态。
核心要点：AIDL接口的设计原则是“单向调用，双向回调”。Framework调用Stack的方法，Stack通过Callback把结果传回来。千万别搞成双向同步调用，否则容易死锁。
2.3 层级调用实战：从App到Stack的完整链路
咱们拿“连接蓝牙电话”这个场景走一遍。你按下App里的“连接”按钮，背后发生了什么？
- App层：调用
BluetoothHeadset.connect(device)。这个方法是Framework层暴露出来的。 - Framework层：BluetoothHeadset.java里，通过AIDL调用
IBluetoothHeadset.connect(device)。这里会跨进程到蓝牙服务进程。 - 蓝牙服务进程：收到AIDL调用后，调用
BluetoothHeadsetService.connect()。这个Service会跟底层的Bluetooth Stack交互。 - Bluetooth Stack层：Stack收到连接请求后，通过HCI命令跟蓝牙芯片通信。芯片再跟手机建立RFCOMM连接。
- 回调回来：连接成功后，Stack通过
IBluetoothHeadsetCallback把状态回调给Framework。Framework再通过广播或回调通知App。
你看，这一圈下来，每一层只跟相邻层打交道。App不知道Stack的存在，Stack也不知道App的存在。这就是分层的好处。
我的经验：调试这种跨进程调用时，最头疼的是找不到问题在哪一层。我建议你在每一层的入口和出口都加日志。比如在AIDL接口的stub端和proxy端都打log，这样一眼就能看出是哪个进程出了问题。
2.4 车载场景下的特殊设计
Android Automotive跟手机不一样。车载蓝牙有几个特殊需求：
- 多设备并发：车机可能同时连接两部手机。一个打电话，一个放音乐。Framework层需要管理多个BluetoothDevice实例。
- 优先级管理：哪部手机优先接电话？哪部手机优先播放媒体？这些逻辑通常在Framework层的
BluetoothDeviceManager里实现。 - Profile管理：车载蓝牙需要同时支持HFP、A2DP、AVRCP、PBAP、MAP等多个Profile。每个Profile都有自己的AIDL接口。
我曾经在一个项目里遇到过，两部手机同时连接时，A2DP音频流会卡顿。查了半天，发现是Framework层的AIDL回调处理不及时，导致音频缓冲区溢出。后来加了个优先级队列，问题就解决了。
避坑指南：车载蓝牙的AIDL接口设计时，一定要考虑多设备场景。比如IBluetoothHeadset的connect()方法，参数里必须带上设备地址。别写成无参的，否则你没法区分连的是哪部手机。
2.5 代码示例：一个简单的AIDL接口定义
咱们看个实际的例子。这是车载蓝牙里常用的一个AIDL接口，用于控制HFP的音频通道：
// IBluetoothHeadsetAudio.aidl
package android.bluetooth;
interface IBluetoothHeadsetAudio {
// 设置音频通道：0=手机，1=车机，2=自动
int setAudioChannel(int channel);
// 获取当前音频通道
int getAudioChannel();
// 注册回调，监听音频通道变化
void registerCallback(IBluetoothHeadsetAudioCallback cb);
void unregisterCallback(IBluetoothHeadsetAudioCallback cb);
}
// IBluetoothHeadsetAudioCallback.aidl
package android.bluetooth;
interface IBluetoothHeadsetAudioCallback {
void onAudioChannelChanged(int channel);
void onAudioError(int errorCode, String message);
}
你看，这个设计很清晰。一个接口负责下发命令，一个回调接口负责上报状态。而且参数都是基本类型，跨进程传输效率高。
嗯，这里要注意，AIDL接口里不要传大对象。比如不要传Bitmap或者很大的List。跨进程传输是有大小限制的，超过1MB就会抛异常。我见过有人把整个联系人列表通过AIDL传过去，结果直接崩溃。
2.6 总结一下
Android Automotive的蓝牙架构，说白了就是四层结构加AIDL通信。每一层各司其职，通过定义好的接口互相调用。
我个人觉得，理解这个架构的关键在于两点：
- 搞清楚每一层的职责边界。App只管UI，Framework管策略，Stack管协议，Vendor管硬件。
- 理解AIDL的设计哲学。单向调用、双向回调、轻量传输。
下一章咱们聊聊蓝牙配对流程。嗯，那个环节坑更多，尤其是车载场景下的自动配对和PIN码输入。到时候我把我踩过的坑都抖出来。