BLE-ANCS协议介绍

1 ANCS综述

ANCS即 Apple Notification Center Service。是IOS系统中的一个通知服务。设备连接手机后，设备首先需要先使能IOS系统的通知功能，具体即设备上的GATT 客户端发现IOS上的ANCS，并且使能其 通知源Characteristics 的notify功能。 之后IOS系统就会通过ble 推送消息给设备了。

通常推送的消息仅仅是一个简短通知，比如通知有一个社交消息。如果需要获取详细消息，还需要 设备通过 控制点 Characteristics 主动发送控制指令给 ANCS服务，让其返回详细信息。返回的详细信息通过一个数据源Characteristics来返回。所以连接上服务后除了使能通知源Characteristics的notify功能，还需要使能 数据源Characteristics的notify功能，因为可能需要通过数据源来获取通知的详细信息。

如下图所示：NC（通知消费者）连接NP（通知提供者）上后发现服务，然后 订阅(使能通知功能) 通知源和数据源，之后如果NP有消息就会 通过 通知源 通知NC了。

综上，ANCS是一个服务，

其服务UUID是特定的为7905F431-B5CE-4E99-A40F-4B1E122D00D0

该服务会主动推送一些 通知消息给 设备，所以有一个具有notify功能的Characteristics。

该特性称为Notification Source.

（注意这里 notify指的是Characteristics的发送消息方式， 而notification source仅仅是一个称谓，就是字面意思，表示这个Characteristics的目的是为了推送一些通知，所以称为通知源）

通过notification source发送过来的通知仅仅是简短的消息。如果希望获取更消息的消息则需要 设备主动发送控制指令给手机上的ANCS，所以该服务还有一个具有写功能的Characteristics，这样就可以通过这个Characteristics来发送控制指令给ANCS服务。这个特性称为Control Point

发送控制消息后 ANCS服务会返回更详细的消息。这个消息不会再通过notification source这个Characteristics，而是用过另一个具有 notify功能的Characteristics来返回，该特性称为Data Source。

综上ANCS服务至少有3个特性。其UUID如下：

·        Notification Source: UUID 9FBF120D-6301-42D9-8C58-25E699A21DBD (notifiable)

·        Control Point: UUID 69D1D8F3-45E1-49A8-9821-9BBDFDAAD9D9 (writeable with response)

·        Data Source: UUID 22EAC6E9-24D6-4BB5-BE44-B36ACE7C7BFB (notifiable)

 

 

即 :notify source 这个Characteristics 是NP用来发送通知给NC的，

    Control point这个Characteristics 是NC用来发送控制命令给NP的，如获取通知详细信息。

    Data source这个Characteristics 是NP收到NC获取详细信息命令后返回通知的详细信息

   

下面分别介绍三个Characteristics 中(也可以认为是三个数据通道)传输的数据的 内容和格式

2 notify source ：通知源

NP发送通知给NC的通道。其上发送的数据格式如下：

2.1 EventID: 

表示这个通知是  added, modified， removed 三种中的哪种。

如果手机收到一个qq消息，则手机（NP）发给一个 added的通知给 设备( NC )。

如果用户在手机通知栏上滑动清除了这通知，则手机(NP)就会发送一个removed的通知给设备(NC)

Modified类型的具体还没碰到

 

2.2 EventFlags：

每个位有特殊的意义，用来指示这个通知的一些特性

EventFlagSilent	= (1 << 0),
EventFlagImportant	= (1 << 1),
EventFlagPreExisting	= (1 << 2),
EventFlagPositiveAction	= (1 << 3),
EventFlagNegativeAction	= (1 << 4),
Reserved EventFlags	= (1 << 5)–(1 << 7)

 

2.2.1  Slient标记：

 没搞清干吗用的。

2.2.2  Important标记:

表示通知重要，比如手机有来电时，推送给NC的通知其flag的important就会被置位，表示通知重要。

2.2.3  PreExisting标记:

表示消息是之前就存在，比如手机连接设备后，再断开设备，然后重新连接，则连接上后手机(NP)会发送一些 断开前就有的没处理的手机上的通知，这些通知的preExisting位就会被置位。

2.2.4  PositiveAction，NegativeAction标记:

 称积极动作和消极动作吧，和每个具体通知有关， 比如手机收到 来电，则就会发送 来电通知给 设备，这个通知就通知具有这两个 标记，积极动作表示 接电话，而消极动作表示拒接电话。

再如，手机收到qq消息，则手机发送 通知给 设备，这个通知就只有 negativeaction标记。

PositiveAction,NegativeAction 这两个标记仅仅表示 这个”通知”具有一些预定义的动作，比如 电话通知的 接听和 拒接。 具体是否执行，则需要 通过控制通道发送 控制指令 执行 积极动作或者消极动作。

也就是 这两个标记仅仅表示 这个通知具有某个预定义的对这个通知的特殊处理，至于执不执行则要看 设备(NC) 是否发送执行PositiveAction 或NegativeAction的命令 后面 对控制通道的描述会有说明。

2.3 CategoryID:   

用来分类通知类型的

 

CategoryIDOther	= 0,
CategoryIDIncomingCall	= 1,
CategoryIDMissedCall	= 2,
CategoryIDVoicemail	= 3,
CategoryIDSocial	= 4,
CategoryIDSchedule	= 5,
CategoryIDEmail	= 6,
CategoryIDNews	= 7,
CategoryIDHealthAndFitness	= 8,
CategoryIDBusinessAndFinance	= 9,
CategoryIDLocation	= 10,
CategoryIDEntertainment	= 11,
Reserved CategoryID values	= 12–255

 

比如 手机来电时，手机(NP)就会推送通知给设备，这个通知类型就是CategoryIDIncomingCall， 如果手机来电时，用户没有接到，即对方主动挂掉电话，那么 手机就会推送一条 MissedCall 类型的通知给设备。

再比如手机收到qq消息时，就会推送一条 Social 类型的通知给设备。

 

2.4 CategoryCount:

统计当前收到的这个类型的通知已经有多少个了。

比如qq消息和 短信 都被分类成Social 类型，手机连接上设备建立ANCS连接后，收到了第一个qq消息时，则手机推送一条Social类型的通知给设备，其Category Count就为1，如果手机不处理这个通知，则当手机再收到qq消息时就会再次推送一条Social通知给设备，其Category count就是2。 同样手机不处理这个2个qq消息时，如果又收到了一条短信，则手机又会推送一条Social类型的通知给设备，其Category count为3.

2.5 NotificationUID: 用来唯一标识一个通知。

ANCS建立连接后收到的每个通知都有一个NotificationUID，通知只是一个简短消息，通常再需要发送指令给 手机(NP)来获取通知的详细信息，这个时候就需要这个NotificationUID 来标识是想获取哪个通知的详细信息。

以上就是 通知源 Characteristics 上推送的通知的格式。

下面介绍 控制Characteristics 和 数据Characteristics 上传输的数据。

3 Control Point and Data Source

控制点可以用来获取通知的详细信息。

前面提到一些通知是有一些预定义操作的，比如来电通知就有 积极动作(接听)和消极动作(拒接)这两个预定义的动作，所以控制点除了用来 发送获取通知详细信息的命令，还可以用来发送执行 预定义的 积极动作或消极动作的指令。

数据源即用来返回数据的，在控制点上发送的获取详细信息的命令后，就会再 数据源通道上返回 通知的详细信息。

通知的详细信息由一系列的Attributes组成，每个Attribute都表示这个通知某方面的详细信息，如下表

NotificationAttributeIDAppIdentifier	= 0,
NotificationAttributeIDTitle	= 1, (Needs to be followed by a 2-bytes max length parameter)
NotificationAttributeIDSubtitle	= 2, (Needs to be followed by a 2-bytes max length parameter)
NotificationAttributeIDMessage	= 3, (Needs to be followed by a 2-bytes max length parameter)
NotificationAttributeIDMessageSize	= 4,
NotificationAttributeIDDate	= 5,
NotificationAttributeIDPositiveActionLabel	= 6,
NotificationAttributeIDNegativeActionLabel	= 7,
Reserved NotificationAttributeID values	= 8–255

AppIdentifier该attribute表示发送这个通知App的标识。比qq消息的app id就是com.tencent.mqq

 

Title 该attribute表示通知的标题，qq消息的标题就是QQ

Subtitle为子标题，通常为空。Message就是信息内容，MessageSize为信息大小，

 

Date为通知发出的时间(不是返回详细信息的时间，是 之前通知的发出时间)，

 

PositiveActionLabel和NegativeActionLabel即描述 积极动作和消极动作具体是什么。 来电通知其积极动作和消极动作通常就是 接听和拒接。

具体过程如， 当手机qq收到一条qq消息时， 手机就会在 通知源通道上 推送一条 Social类型的通知给 设备，设备收到后 可以在 控制点通道上发送一条获取该通知详细命令，之后手机再通过 数据源通道返回其详细信息。

3.1 获取通知的详细信息的命令格式和 响应数据格式

既然通知的详细信息是由一个个 attribute组成，那么我们获取详细信息的时候就可以自己指定 获取 这个 通知的 哪些attribute。所以获取通知详细命令的格式如下：

3.1.1 CommandID：

获取通知详细信息的 命令ID为0

3.1.2 NotificationUID：

用来具体标识要获取哪个通知的详细消息，这个值就是用 通知源通道中收到的通知的NotificationUID字段。

3.1.3 AttributeID n：

这些字段即指定想获取这个通知的哪些详细信息，一些attributeID之后需要跟2字节的max length表示 设备(NC)期望获取这个通知该特性信息的最大长度。具体哪些attribute需要跟2字节max length在前面的attributes表中有说明。

 

获取通知attributes（即获取通知详细信息）在 控制点通道上发出以后，NP(手机)就会在 数据源通道返回这些 attributes的值。即通知的一些具体信息。返回的响应数据格式如下：

CommandID同样还是0，表示该响应是获取通知attributes的响应，

NotificationUID 与 命令中的NotificationUID对应，用来表示返回的这些attributes的值是 对应哪个 通知的。

随后就是 具体的attributes的值了， 均由3字段组成，分别表示attribute,其值长度，具体值。

 

3 . 2 获取手机上产生本条通知的APP的信息

如何获取 产生这个通知的app的消息？ 设备收到的通知实际是 手机发送过来的，而手机之所以发送这个通知给设备时因为 手机中的一些应用产生了一些消息。

比如，手机上的qq产生了一条消息，则手机通知栏上就会产生这个通知，同时也会推送一条 Social类型的通知给 连接的设备。

所以 设备端 想获取 产生这个通知的APP的一些信息，首先应该 获取 该通知由哪个app产生的，然后才能查询该app的消息。

 

前面提到，收到通知后，一般需要再 在控制通道上发送获取通信详细信息的命令来获取到 该通知相关的一些更具体的信息， 而获取详细信息实际就是获取这个通知的 一些 attributes 的具体的值。

其中就有一个 attribute用来标识 是由哪个 app 产生的这个通知，即NotificationAttributeIDAppIdentifier。

所以受到通知后首先 需要使用 获取通知attributes的命令来获取其NotificationAttributeIDAppIdentifier的具体值，这个就知道了产生这个 通知的app的标识。

之后再通过 获取 app信息命令来获取 产生这个通知的app的信息，命令格式如下

CommandID：为1，标识获取 app的相关信息命令。

App Identifier: 用来指示获取哪个app信息。就是获取通知详细信息中返回的NotificationAttributeIDAppIdentifier的值。

Attributes:  获取通知的详细信息 就是获取通知一些attributes的值，同样获取APP详细信息 也就是 获取 APP的一些attributes。

目前：app相关的 attributes只有一个，即其名字。

AppAttributeIDDisplayName	= 0,
Reserved AppAttributeID values	= 1–255

 

同样 获取 app详细信息的返回也是通过 数据源通道返回。

CommandID：为1，标识获取 app的相关信息命令的响应。

App Identifier: 与命令中的app id对应，用来指示获取哪个app信息。

随后就是具体的各个 attributes的值。

 

如下图是 收到qq消息的通知后，获取其详细信息，并通过 app id这个attribute来获取 app的消息

3.3 执行通知预定义动作

通知源部分有 提到一些通知具有一些预定义的执行动作，通过 通知的EventFlags 字段来指示这个通知是否 有预定义的 积极动作或消极动作。来电通知就有 接听/拒听的 积极动作/消极动作。

所以如果收到 来电通知时， 即 通知CategoryID字段为CategoryIDIncomingCall 时，如果接听，就可以让设备 在控制点 通道上发送 执行积极动作的命令， 同理如果拒接，就在 控制点通道 上发送执行消极动作的命令。

 

执行预定义命令格式如下

Bytes	Name	Description
1	CommandID	为2表示执行预定义动作
2-5	NotificationUID	用来标识 执行哪个 通知的预定义动作
6	ActionID	0表示执行 积极预定义动作，1表示执行消极预定义动作