这几年主机厂的主机OS,几乎从原来的嵌入式、Windows、Linux、QNX等全切换到了Android;嵌入式、Windows几乎覆灭,而Linux和QNX等只占少数份额,剩余的不论前装还是后装产品几乎都是Android;
但不论哪种OS产品,音频娱乐、无线连接等都绕不开蓝牙(Bluetooth), 主机的功能基本验证了那句“你可以不用,但你不能没有”。笔者从事蓝牙产品研发十多年,几乎见证了主机蓝牙的整个变迁过程(笔者主业还是车载蓝牙,BC5-MM等SOC蓝牙只是日常玩玩);
本文聊一下Android 主机中蓝牙使用及架构变化;
早期的Android(如Android4) 主机装车时,此时车机蓝牙使用的是Android 自带蓝牙(我们称其为 原生蓝牙)。其蓝牙兼容问题,将由主机厂自行解决或委托第三方蓝牙方案公司进行维护(但这种维护形式的合作,方案商很难赚到钱,且主机厂会要求全代码公开,能接这种项目的几乎都是为了维护客户关系)。 原生蓝牙方案的维护不论是主机厂本身还是第三方蓝牙方案供应商,都受限于原生蓝牙架构,而有能力作为第三方蓝牙方案供应商的公司,基本都有其自家的蓝牙协议栈,所以对原生蓝牙基本持“不肯定也不否定”的态度;
蓝牙最难的就是兼容问题理清,在解决兼容问题时,不能解决一个bug,制造一个bug,这要求蓝牙工程师必须对蓝牙profile及当前产品架构有较深入认识,在前装产品尤其谨慎。
在近4、5年的Android 主机迭代中,在前装主机厂不断提高稳定性及功能要求以及第三方蓝牙供应商的推动下,Android主机中的蓝牙架构也发生了变化,主要体现在以下两点:
1)直接替换Android 中的原生蓝牙,改用第三方蓝牙供应商的自定义蓝牙接口,这种方案几乎只会出现在前装产品,且Android 主机不允许终端客户随意安装第三方APP的case下;
此架构的优势是: 第三方蓝牙供应商提供完整的蓝牙解决方案,同时也负责主机全生命周期下的蓝牙兼容问题处理;基于对自家蓝牙架构的熟悉度,蓝牙供应商可以较快解决兼容问题,并基于客户需求客制化几乎全部的蓝牙功能;
此架构的劣势是:因自定义蓝牙API,Android市场上的蓝牙相关APP将无法正常使用;
2)保留Android原生蓝牙的Framework层对外接口,Framework层以下替换为第三方蓝牙供应商的蓝牙协议栈;这种方案也几乎只会出现在前装产品;后装车机因对价格敏感,这种方案很少使用;
基于原生蓝牙架构(如Android 8为例),替换方案基本有以下4种方式(4种方式笔者都处理过):
方式A,直接在Framework层进行替换,基于原生蓝牙执行flow,只保留Framework层对外接口;
方式B,在AIDL接口不变情况下,编写蓝牙供应商自己的Bluetooth.apk(Bluetooth Server APK);
方式C,在JNI层进行替换,即替换Bluetooth Server APK的底层JNI so部分;
方式D,替换底层的BlueDroid,只保留JNI层与BlueDroid层的接口实现;
以上4种替换方案,都需要对Android原生蓝牙运行flow有深入的认识,不然替换后,原生蓝牙运行异常也很头大;
较目前发展,各家蓝牙供应商基本集中在A、B两种方式,尤其是A,因替换层级越高,在保证原生蓝牙flow不变case下的处理自由度越高,Framework层接口和自家蓝牙协议栈的转换工作量越少;稳定性越高;
此架构的优势是:能更好的解决蓝牙兼容问题;Android市场的蓝牙APP可以正常安装使用;主机厂在客制化新功能时,供应商的自由度更高;
此架构的劣势:对主机厂来说几乎没有劣势;对供应商来说,每一代Android OS 都需要“理清蓝牙运行flow、重新对接”;
随着市场变化,主机厂对蓝牙也在不断提出新要求:如,
A) 主机厂要求Android车机上电后立马重连上蓝牙。之前的蓝牙架构将不再符合连接时长要求,这种case下,需要把蓝牙Server APK一分为二,如部分蓝牙协议栈独立运行在Linux 内核...;
B)智能座舱,目前市场主流是QNX Hypervisor架构(QNX +Android)。此时蓝牙内核可能运行在QNX,但蓝牙相关操作在Android;
以上两种新需求,都基于A层级的对接修改,蓝牙供应商才有机会进行处理;原生蓝牙无法实现以上功能;
最后叨叨一句题外话,
Android 原生蓝牙BlueDroid的实现架构其实挺好的,但就是处理逻辑太绕,也不知道工程师咋想的,搞得如此复杂。
编写一套能商用,尤其符合车规的蓝牙协议栈很耗时间,需要研发工程师对蓝牙协议有很深入的研究;目前笔者已知的就有部分公司拿Android BlueDroid进行二次开发,包装为自家的蓝牙协议栈,这也算跑捷径了;