11、车载蓝牙与连接：BluetoothAdapter车载模式、电话与媒体流管理、CarBluetoothService、设备配对流程
车载蓝牙，说实话，是用户每天都会接触的功能。你想想看，一上车，手机自动连上，音乐接着放，电话免提接听——这些看似理所当然的体验，背后其实是一整套蓝牙协议栈和车载服务的协同工作。我在做车载项目时，蓝牙模块的稳定性问题，曾经让我连续加班两周排查。嗯，今天我们就来把这些核心知识点掰开揉碎。
11.1 BluetoothAdapter 的车载模式
Android 原生的 BluetoothAdapter 大家都不陌生。但在车载场景下，它有几个特殊模式需要关注。
首先，车载蓝牙不能像手机那样随意开关。用户开车时，蓝牙必须保持常开状态。我建议在系统启动时，通过 BluetoothAdapter.getDefaultAdapter() 获取实例后，直接调用 enable() 方法。但要注意，不要在主线程里做这件事。
核心区别：车载模式下，蓝牙的扫描间隔、连接策略、电源管理都与手机不同。系统会优先保证电话和媒体流的低延迟。
车载模式还有一个关键点：多设备连接。手机通常只连一个耳机或音箱，但车载系统可能需要同时连接多个手机（比如主驾和副驾各连一部）。这时候，BluetoothAdapter 的 startDiscovery() 方法就要谨慎调用了——扫描过程会占用射频资源，影响已有连接的稳定性。
我的经验：曾经有个项目，每次扫描蓝牙设备时，正在播放的音乐就会卡顿。后来发现是扫描间隔太短，占用了太多带宽。解决方案是：将扫描间隔拉长到 12 秒以上，并且只在用户主动点击“添加设备”时才触发扫描。
11.2 电话与媒体流管理
车载蓝牙的核心场景就两个：打电话和听音乐。这两个场景对应着不同的 Profile：
| Profile | 用途 | 优先级 |
|---|---|---|
| HFP（Hands-Free Profile） | 电话免提、语音通话 | 最高 |
| A2DP（Advanced Audio Distribution Profile） | 高质量音频流（音乐、导航语音） | 高 |
| AVRCP（Audio/Video Remote Control Profile） | 媒体控制（播放/暂停/切歌） | 中 |
| PBAP（Phone Book Access Profile） | 同步联系人、通话记录 | 低 |
为什么电话优先级最高？你想想看，开车时来电话，如果音频卡顿或断连，用户会直接骂娘。而音乐卡顿一下，大部分人还能忍。所以系统设计时，HFP 的音频通道会抢占 A2DP 的资源。
在实际开发中，我们需要监听 BluetoothHeadset 和 BluetoothA2dp 的状态变化。举个例子：
// 监听 HFP 连接状态
BluetoothHeadset headset = ...;
headset.setConnectionStateChangeListener((device, state) -> {
if (state == BluetoothProfile.STATE_CONNECTED) {
// 电话通道已建立，可以开始处理来电
Log.d("CarBT", "HFP connected for " + device.getName());
}
});
// 监听 A2DP 连接状态
BluetoothA2dp a2dp = ...;
a2dp.setConnectionStateChangeListener((device, state) -> {
if (state == BluetoothProfile.STATE_CONNECTED) {
// 媒体通道已建立，可以开始播放音乐
Log.d("CarBT", "A2DP connected for " + device.getName());
}
});注意：不要同时注册多个相同的 Profile 监听器，否则会导致回调混乱。我曾经踩过这个坑，结果一个设备断开时触发了三次回调，排查了半天才发现是重复注册的问题。
11.3 CarBluetoothService 深度解析
CarBluetoothService 是 Android Automotive 中专门管理蓝牙连接的系统服务。它不像普通 Android 那样直接操作 BluetoothAdapter，而是通过 Car API 来间接控制。
为什么要多这一层？说白了，是为了安全。车载系统不能让任意 App 随意开关蓝牙或读取设备列表。CarBluetoothService 会检查调用方的权限，只有系统级应用或经过签名的应用才能操作。
获取 CarBluetoothService 的典型方式：
Car car = Car.createCar(context);
CarBluetoothManager btManager = (CarBluetoothManager) car.getCarManager(Car.BLUETOOTH_SERVICE);
// 获取已配对的设备列表
List<BluetoothDevice> pairedDevices = btManager.getPairedDevices();
// 主动发起连接
btManager.connect(device);这里有个细节：getPairedDevices() 返回的是已经完成配对流程的设备，但不一定处于连接状态。你需要再调用 connect() 来建立实际的音频通道。
核心逻辑：CarBluetoothService 内部维护了一个设备优先级队列。最近连接过的设备会被排在前面，下次上车时会自动尝试连接。这个队列的排序算法，我建议不要自己去改，系统默认的已经很合理了。
11.4 设备配对流程
配对流程，说白了就是让车机和手机互相认识的过程。完整的流程如下：
- 发现阶段：车机发起扫描，手机端需要处于可被发现模式。
- 请求配对：车机向手机发送配对请求，双方协商加密密钥。
- 用户确认：车机屏幕上显示配对码，用户需要在手机端确认。
- 绑定完成：双方交换必要信息（如设备名称、支持的 Profile），配对成功。
- 自动连接：下次上车时，只要蓝牙开启，系统会自动重连。
在代码层面，配对流程主要涉及 BluetoothDevice 的 createBond() 方法：
BluetoothDevice device = ...;
if (device.getBondState() != BluetoothDevice.BOND_BONDED) {
boolean success = device.createBond();
if (success) {
Log.d("CarBT", "Pairing initiated for " + device.getName());
} else {
Log.e("CarBT", "Pairing failed for " + device.getName());
}
}但这里有个坑：createBond() 是异步操作，你不能指望它立即返回成功。真正的配对结果会通过广播 BluetoothDevice.ACTION_BOND_STATE_CHANGED 通知你。
避坑指南：我曾经遇到过一个情况，某些手机在配对时会弹出 PIN 码输入框，但车机没有物理键盘。这时候需要实现 SSP（Secure Simple Pairing）协议，自动处理配对码。解决方案是：在配对请求广播中，读取 BluetoothDevice.EXTRA_PAIRING_VARIANT，如果是 PAIRING_VARIANT_PIN，就自动填入预设的 PIN 码。
下面我用一张流程图来总结整个蓝牙连接的核心逻辑：
嗯，到这里，车载蓝牙的核心内容就差不多了。我个人觉得，蓝牙这块最考验人的不是代码怎么写，而是对各种异常情况的处理——比如手机突然断开、配对超时、Profile 协商失败等等。建议你在开发时，多花点时间在状态机的设计上，把每个状态之间的转换逻辑理清楚。
最后说一句：车载蓝牙的调试，最好用真实的手机和车机硬件来测。模拟器上跑得再顺，到了真车上也可能出幺蛾子。我吃过这个亏，所以现在每次提交代码前，都会拿三台不同品牌的手机做一轮回归测试。