瑞芯微RK平台AP6275PR3模块蓝牙MAC地址获取实战指南

开发者的核心痛点

在瑞芯微（Rockchip）RK平台开发蓝牙功能时，你是否遇到过这些困扰：

•设备恢复出厂设置后，蓝牙MAC地址随机变化，无法满足设备唯一性标识需求

•想读取WiFi+BT combo模块（如本文案例中的AP6275PR3）自带的硬件MAC地址，却找不到入口

•系统自动生成的临时MAC地址，在量产场景下完全不可靠

别急，我们结合RK平台的技术规范和实际调试经验，一步步拆解解决方案。

RK平台蓝牙MAC地址获取优先级

首先要明确：RK平台对蓝牙MAC地址的获取有严格优先级逻辑，这是我们解决问题的核心依据：

优先级	来源	特点
	模块自带MAC	硬件烧录的唯一BDADDR（需和模块厂商确认），最稳定可靠
	工具写入MAC	通过RKDevInfoWriteTool等工具提前烧录的MAC（通常需购买地址段）
	系统生成MAC	无有效MAC时临时生成，恢复出厂后会变更，禁止用于量产

对于AP6275PR3这类模块，厂商已确认自带蓝牙MAC地址，所以我们的目标是：让系统优先读取模块自带的MAC，并持久化存储。

 核心解决方案：启用模块BDADDR读取

关键原理

通过修改蓝牙库的宏定义，强制启用「读取模块自带BDADDR」逻辑，让系统从硬件层面获取MAC，并写入vendor storage（RK平台安全持久化存储区域），即使恢复出厂设置也不会丢失。

实操步骤

1. 定位代码文件

在RK SDK中找到蓝牙库配置文件（以Android 13为例）：

 

hardware/broadcom/libbt/include/vnd_rksdk.txt

 

2. 修改关键宏定义

将USE_CONTROLLER_BDADDR从FALSE改为TRUE，完整diff如下：

 

diff --git a/include/vnd_rksdk.txt b/include/vnd_rksdk.txtindex 7d3f810..e1953b 100644--- a/include/vnd_rksdk.txt+++ b/include/vnd_rksdk.txt@@ -9,7 +9,7 @@ BTWND_DBG = FALSE BTHW_DBG = TRUE VNDUSERAL_DBG = FALSE UPIO_DBG = FALSE-USE_CONTROLLER_BDADDR = FALSE+USE_CONTROLLER_BDADDR = TRUE

 

可选：保留调试宏（如BTHW_DBG = TRUE），方便排查问题。

3. 编译验证

重新编译蓝牙相关模块（libbt），将新镜像烧录到设备。

4. 效果验证

•启动设备后，查看蓝牙MAC地址：

 

adb shell settings get secure bluetooth_address

 

•执行恢复出厂设置，再次查看MAC地址，验证是否保持不变。

原理解析：为什么这样改能生效？

1.宏定义作用：USE_CONTROLLER_BDADDR = TRUE 会让蓝牙库初始化时，优先通过HCI命令向AP6275PR3模块（博通方案）读取硬件自带的BDADDR。

2.持久化存储：读取到的MAC地址会被写入vendor storage区域——这是RK平台专门用于存储安全、关键数据的区域，即使格式化data分区（恢复出厂），数据也不会丢失。

3.优先级保障：后续启动时，蓝牙服务会直接从vendor storage读取已存储的MAC，避免重复读取硬件或生成临时地址。

 避坑指南

1.模块兼容性：必须先和模块厂商确认，模块是否在出厂时烧录了唯一BDADDR（如AP6275PR3支持，部分低成本模块可能不支持）。

2.SDK版本差异：不同Android版本（如11/12/13）的配置文件路径可能略有不同，可在hardware/broadcom/libbt目录下搜索vnd_rksdk.txt定位。

3.无自带MAC的场景：如果模块没有自带MAC，建议使用RKDevInfoWriteTool工具，提前将购买的MAC地址段烧录到vendor storage区域，实现量产管理。

总结

通过启用USE_CONTROLLER_BDADDR宏，我们可以高效读取AP6275PR3等模块自带的蓝牙MAC地址，并通过vendor storage实现持久化，完美解决量产场景下蓝牙MAC地址不稳定的痛点。

这种方案既利用了模块硬件的唯一性，又符合RK平台的安全存储规范，是量产项目的推荐方案。

审核编辑 黄宇