蓝牙电话之PBAP同步电话薄协议分析
蓝牙电话之PBAP-同步协议分析
在前一篇文章《蓝牙电话之PBAP协议分析》中从整体上分析了PBAP协议的内容，本章我们着重分析协议中的精髓——同步电话薄。PBAP协议存在的目的就是将PSE端的源数据同步到PCE，那么就让我们开启这段旅程吧。
每一种协议都会定义相关的功能features，PBAP同步也不另外，协议中主要定义了以下两种功能。
-
Download：此功能用于下载电话簿对象的全部内容
-
Browsing：此功能特别适用于需要滚动浏览电话簿的应用程序
PSE和PCE两端对这两种功能的支持见下图：
由于Download功能可以将电话簿对象的全部内容同步到PCE，从而PCE端获取到数据后完全可以通过蓝牙电话等应用程序将数据显示到界面，一样可以达到滚动浏览电话簿信息的目的，所以后面主要以Download为分析点，对Browsing感兴趣的同学，欢迎给我私信一起探讨该功能点如何使用。
Download这个功能特别适用于PSE端存储的电话簿容量相对较大，PCE设备通常从PSE端下载这些大容量数据并在其本地存储整个电话簿的场景下。PullPhonebook函数就是用来下载自己感兴趣的电话簿对象。
由于PBAP协议是基于OBEX的，所以PullPhonebook函数顾名思义也是采用request-response这种一问一答的形式传输数据。
请求格式：
同步的电话簿对象名字Name值有如下几种选项：
回复格式：
回复数据中的vCard对象只应包含使用属性选择器Attribute Selector参数指示的属性，并且应使用格式Format参数指示的格式组装数据。当前蓝牙PBAP协议中的vCard版本只有vCard 2.1和vCard 3.0这两种版本，所以我们在构造数据时选择其中一种vCard版本即可。
请求回复格式中需要重点讲解的只有一个参数：Application Parameters Header，其数据是由一组不同的tag组成整体的Application Parameters，可选的Tag如下图，比较常用的为红色框图标注出来的这六个tag：
这些tag中PropertySelector用于指示请求的vCard对象中应该包含的属性，PSE根据这些属性来组织回复的Body/End of Body Header中包含的数据，PCE只能使用此头接收所请求的vCard所需内容，PSE不得回复任何其他性能数据，除非PCE有其他要求。
因为PropertySelector的值是由一个64位的数据组成，所以每一位都代表了一种属性，如果PCE请求的电话簿需要包含对应的数据，就将该数据对应在PropertySelector的二进制位设置为true（1）。具体每一位的含义见下图：
同步电话簿中的信息时，最主要的关注还是联系人名字、联系人号码、联系人头像这三部分数据。所以要根据自己业务的真实需求来构造PropertySelector值，同步到PCE端相关应用需要的数据。
由于当前安卓源码还没实现PCE端的相关接口，需要适配自我实现。我这里采用的这套安卓代码是以高通源码为基础，加上功能适配后实现的一套PBAP同步代码，PCE端同步电话簿的流程大概为：获取同步对象的数量 –> 同步该对象。
接下来以HCI视角简单分析下同步流程：
1、 同步联系人
同步联系人整体上分为两步骤，先获取两种Name下的联系人数量，再根据数量分别同步对应Name下的联系人数据，以下两幅截图选取Name=telecom/pb.vcf为例进行说明，SIM卡的流程类似。
-
获取联系人数量：
-
同步联系人数据：
2、 同步通话记录
通话记录有三种类型及对应的vcf文件
-
MISSED：未接来电通话记录——mch.vcf
-
RECEIVED：已接来电通话记录——ich.vcf
-
DIALED：去电通话记录——och.vcf
但是还有一种类型的vcf文件包含以上三种类型，即cch.vcf，所以可以根据自己的需求选择同步哪种通话记录，我这边实现的是同步全部类型的通话记录（主要是分类型依次去同步通话记录，太麻烦了）
PCE端同步获取到电话簿数据后基本上有两种方式来处理数据：
- 通过回调方式上报给应用（需要添加相关回调打通APK-API-蓝牙服务这三层的关系）
- 存储在安卓系统提供的数据库中，上报应用相关状态，应用再从数据库中取出对应的数据
实际使用以上两种方式后，自我感觉通过回调方式上报数据速度很快，但数据库的优势是可以将数据已数据库的形式存储，不担心应用或安卓系统crash后导致的数据丢失问题。所以建议大家可以两种方式结合起来共同使用。
好了，蓝牙电话中关于PBAP协议同步数据的分析就总结到这，感兴趣的小伙伴欢迎私信留言一起讨论
更多互联互通技术，欢迎关注微信公众号：Connectivity