苹果ANCS协议分析

SYD8801是一款低功耗高性能蓝牙低功耗SOC，集成了高性能2.4GHz射频收发机、32位ARM Cortex-M0处理器、128kB Flash存储器、以及丰富的数字接口。SYD8801片上集成了Balun无需阻抗匹配网络、高效率DCDC降压转换器，适合用于可穿戴、物联网设备等。具体可咨询：http://www.sydtek.com/

下面是对苹果ancs的说明，下文摘录于：http://www.bubuko.com/infodetail-661715.html

苹果官网ancs解析：https://developer.apple.com/library/content/documentation/CoreBluetooth/Reference/AppleNotificationCenterServiceSpecification/Introduction/Introduction.html

苹果ANCS协议学习

综述

苹果通知中心（Apple Notification Center Service, ANCS）的目的是提供给蓝牙外设一种简单、方便的获取ios设备通知信息的方式。

 

依赖

ANCS的使用没有依赖，它是GATT的一个子集，任何一个实现了GATT client的设备可以方便的从ios设备获取通知信息。

 

传输注意事项

如果没有特殊说明，通过ANCS传输的数值均使用小端模式。

如果没有特殊说明，通过ANCS传输的字符串均使用UTF-8编码。

 The maximum length of an attribute value shall be 512 octets.

概念定义

l  ANCS：苹果通知中心服务

l  NP（Notification Provider）：通知的产生者，一般是ios设备

l  NC（Notification Consumer）：通知的消费者，一般是蓝牙设备

l  iOS notification：ios设备里出现的通知

l  GATT notification：GATT characteristic发送的通知

 

Service定义

ANCS使用了一个私有UUID作为其Service的UUID：

7905F431-B5CE-4E99-A40F-4B1E122D00D0

 

NP上只有一个ANCS实例，基于ios的机制，ANCS没有办法保证一直运行。

所以NC需要搜索并且监听（subscribe）Service Changed characteristic，以保证能够坚挺到所有通知。

（怎么做。。。。Service Changed characteristic是啥）

 

Characteristic类型

所涉及的characteristic

 1、Notification Source:

   UUID 9FBF120D-6301-42D9-8C58-25E699A21DBD(notifiable)

   基本通知源，通知一些计数的信息；

  

 2、Control Point:

   UUID 69D1D8F3-45E1-49A8-9821-9BBDFDAAD9D9(writeablewithresponse)

   控制器，用于向ios设备写入控制信息，例如读取详情；

 

 3、Data Source:

   UUID 22EAC6E9-24D6-4BB5-BE44-B36ACE7C7BFB(notifiable)

   数据源，用于提供详细数据，在控制信息写入后通过此characteristic返回；

 

还有许多其他characteristic，不过只有Notification Source是强制的，其他的都是可选的。

 

Notification Source

通知信息更新时，从NP发给NC的消息。

有以下一些情况：

l  新的ios通知到来；

l  ios通知有改动；

l  ios通知移除；

 

l  EventID：消息类型，添加(0)、修改(1)、删除(2)；

l  EventFlags：消息优先级，静默(1)、重要(2)；

l  CategoryID：消息类型；

l  CategoryCount：消息计数；

l  NotificationUID：通知ID，可以通过此ID获取详情；

 

Notification的生命周期如下：

 

Get Notification Attributes

当NC希望从NP读取Notification的详细信息时，它需要向Control Point characteristic发送一些命令，格式如下：

 

l  CommandID：设为0；

l  NotificationUID：对应Notification Source中相同名字的字段；

l  AttributeIDs：NC希望读取的变量ID列表，有些变量可能需要跟一个16bit的数说明想要的最大长度；

 

NP接收到此命令后，会通过Data Source characteristic将结果返回（通过GATT Notification），所以你需要监听这个参数。此命令发出后对应的返回信息如下：

l  CommandID：为0；

l  NotificationUID：对应之前请求的UID；

l  AttributeList：查询结果列表，每一项的格式都是：ID/16bit  Length/Value，每个attribute都是一个字符串，其长度由Length指定，但是此字符串不是以NULL结尾。若找不到对应的Attribute，则Length为0；

 

* 如果返回的消息长度大于GATT最大传输长度（MTU），则其会被分割成多个分段。蓝牙设备必须将这些分段组装起来。当所有请求属性的内容都接收完成后，此过程才算完成；

 

Get App Attributes

此命令允许NC读取NP上安装app的特定属性，它需要向Control Point characteristic发送一些命令，格式如下：

l  CommandID：设成1；

l  AppIdentifier：App ID，这个字符串必须使用NULL结尾（“\0”吧）；

l  AttributeIDs：希望获得属性的列表；

 

此命令的响应消息格式如下：

 

l  CommandID：为1；

l  AppIdentifier：App ID，与之前的请求ID对应；

l  AttributeList：属性值列表，每一个格式都是：ID/16-bit Length/Value，每个attribute都是一个字符串，其长度由Length指定，但是此字符串不是以NULL结尾。若找不到对应的Attribute，则Length为0；

 

* 关于分段以及传输结束的判断标准，与Get Notification Attributes一致；

 

Session（会话）

ANCS session 在NC订阅Notification Source之后开始，在取消订阅或者连接断开之后结束。由于ANCS不是一个完全同步的服务，它不会在会话中记录状态。所以，所有的NotificationUID以及AppIdentifier仅在某个特定的会话周期内有效。（换句话说，那些ID只是在会话后开始的计数，下次再连接重新计数）

当某个会话结束时，NC需要清空所有ID以及数据内容。当新的会话开始时，NP会尽量把现有的通知都发给NC。NC可以使用这些信息知道当前尚未处理的通知有哪些。

 

Attribute Fetching and Caching

我们建议，只在用户做出操作时才获取attribute。例如，一开始只是展示一个通知列表，然后在用户点击某一个后才查询详细的信息。

 

另外，我们建议在一次会话中建立一张App attribute的缓存表，这样可以避免重复获取一些常量attribute。

 

Error Codes

写入Control Point characteristic时，可能会有错误发生，错误码定义如下（在哪里返回错误码。。。同一次请求中么）：

0xA0 ： 未知命令，commandID非法；

0xA1 ： 无效命令，命令的格式错误；

0xA2 ： 无效参数，某一个参数（例如NotificationID无效）

 

如果有错误发生，就不会有Data Source返回。

 

时序图

下面展示了NP与NC之间的常见交互时序：

 

 

下面的图展示了获取详细信息的时序：

 

 

 

CategoryID

 

EventID

 

EventFlags

 

 

CommandID

 

NotificationAttributeID

 

 

 

 

AppAttributeID

 

 

实际实验之DataSource读取

主要是介绍一下读取的各个AttrID返回的都是啥：

电话：

 

短信：

 

微信：

 

其他应用的ID：

QQ：c o m . t e n c e n t . m q q

365：c o m . 3 6 5 r i l i . C o c o

Any.Do：c o m . a n y d o . A n y D O

系统提示：c o m . a p p l e . r e m i n d e r s

 

下面是官网对ancs的解释（原文请看：https://developer.apple.com/library/archive/documentation/CoreBluetooth/Reference/AppleNotificationCenterServiceSpecification/Introduction/Introduction.html#//apple_ref/doc/uid/TP40013460-CH2-SW1）：

 

Apple Notification Center Service (ANCS) Specification

Next

 

Introduction

 

The purpose of the Apple Notification Center Service (ANCS) is to give Bluetooth accessories (that connect to iOS devices through a Bluetooth low-energy link) a simple and convenient way to access many kinds of notifications that are generated on iOS devices.

The ANCS is designed around three principles: simplicity, efficiency and scalability. As a result, accessories ranging from simple LEDs to powerful “companion” devices with large displays can find the service useful.

 

Dependencies

The ANCS has no dependencies, apart from the standard set of Generic Attribute Profile (GATT) sub-procedures. An accessory acting as a GATT client is free to access and use other services provided by the iOS device while using the ANCS.

 

Endianness and String Encoding

Unless specified otherwise, all numerical values transmitted through the ANCS shall be little endian.

Unless specified otherwise, all string values transmitted through the ANCS shall be composed of unicode characters encoded with UTF-8.

 

Terminology

The Apple Notification Center Service shall be referred to as the ANCS.

The publisher of the ANCS service (the iOS device) shall be referred to as theNotification Provider (NP).

Any client of the ANCS service (an accessory) shall be referred to as a Notification Consumer (NC).

A notification displayed on an iOS device in the iOS Notification Center shall be referred to as aniOS notification.

A notification sent by a GATT characteristic as an asynchronous message shall be referred to as a GATT notification.

 

The Apple Notification Center Service

 

The Apple Notification Center Service is a primary service whose service UUID is7905F431-B5CE-4E99-A40F-4B1E122D00D0.

Only one instance of the ANCS may be present on an NP. Due to the nature of iOS, the ANCS is not guaranteed to always be present. As a result, the NC should look for and subscribe to the Service Changed characteristic of the GATT service in order to monitor for the potential publishing and unpublishing of the ANCS at any time.

 

Service Characteristics

In its basic form, the ANCS exposes three characteristics:

• 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)

All these characteristics require authorization for access.

Support for the Notification Source characteristic is mandatory, whereas support for the Control Point characteristic and Data Source characteristic is optional.

Note: There may be more characteristics present in the ANCS than the three listed above. That said, an NC may ignore any characteristic it does not recognize.

 

Notification Source

The Notification Source characteristic is the characteristic upon which an NC is informed of:

• The arrival of a new iOS notification on the NP

• The modification of an iOS notification on the NP

• The removal of an iOS notification on the NP

GATT notifications may be delivered as soon as the NC subscribes to the Notification Source characteristic. As a result, the NC should be in a state where it can properly accept and process these messages before subscribing to this characteristic.

The format of GATT notifications delivered through the Notification Source characteristic is shown inFigure 2-1.

Figure 2-1  The format of a GATT notification delivered through a Notification Source characteristic

A GATT notification delivered through the Notification Source characteristic contains the following information:

• EventID: This field informs the accessory whether the given iOS notification was added, modified, or removed. The enumerated values for this field are defined inEventID Values.

• EventFlags: A bitmask whose set bits inform an NC of specificities with the iOS notification. For example, if an iOS notification is considered “important”, the NC may want to display a more aggressive user interface (UI) to make sure the user is properly alerted. The enumerated bits for this field are defined in EventFlags.

• CategoryID: A numerical value providing a category in which the iOS notification can be classified. The NP will make a best effort to provide an accurate category for each iOS notification. The enumerated values for this field are defined in CategoryID Values.

• CategoryCount: The current number of active iOS notifications in the given category. For example, if two unread emails are sitting in a user’s email inbox, and a new email is pushed to the user’s iOS device, the value of CategoryCount is 3.

• NotificationUID: A 32-bit numerical value that is the unique identifier (UID) for the iOS notification. This value can be used as a handle in commands sent to the Control Point characteristic to interact with the iOS notification.

The lifetime of an iOS notification can be implicitly deduced through the sequence of Notification Source GATT notifications generated by the NP, as shown inFigure 2-2.

Figure 2-2  The lifetime of an iOS notification

Control Point and Data Source

An NC may want to interact with an iOS notification. It may want to retrieve more information about it, including its contents, or it may want to perform actions on it. The retrieval of these attributes is performed through the Control Point and Data Source characteristics.

An NC can issue a request to retrieve more information about an iOS notification by writing specific commands to the Control Point characteristic. If the write to the Control Point characteristic is successful, the NP will promptly respond to the request through a stream of GATT notifications on the Data Source characteristic.

An NC can perform pre-determined actions on an iOS notification by writing specific commands to the Control Point characteristic. More information about actions and iOS notifications are inPerform Notification Action.

 

Get Notification Attributes

The Get Notification Attributes command allows an NC to retrieve the attributes of a specific iOS notification. The format of a Get Notification Attribute command is shown inFigure 2-3.

Figure 2-3  The format of a Get Notification Attribute command

A Get Notification Attributes command contains the following information:

• CommandID: Should be set to 0 (CommandIDGetNotificationAttributes).

• NotificationUID: The 32-bit numerical value representing the UID of the iOS notification for which the client wants information.

• AttributeIDs: A list of attributes that the NC wants to retrieve. Some attributes may need to be followed by a 16-bit length parameter that specifies the maximum number of bytes of the attribute the NC wants to retrieve.

The format of a response to a Get Notification Attributes command is shown in Figure 2-4.

Figure 2-4  The format of a response to a Get Notification Attributes command

A response to a Get Notification Attributes command contains the following information:

• CommandID: Set to 0 (CommandIDGetNotificationAttributes).

• NotificationUID: The 32-bit numerical value that is the UID of the iOS notification the following attributes correspond to.

• AttributeList: A list of AttributeIDs/16-bit Length/Attribute tuples. An attribute is always a string whose length in bytes is provided in the tuple but that is not NULL-terminated. If a requested attribute is empty or missing for the iOS notification, its length is set to 0. The tuples are always in the same order as the AttributeIDs of the Get Notification Attributes command.

If the response is larger than the negotiated GATT Maximum Transmission Unit (MTU), it is split into multiple fragments by the NP. The NC must recompose the response by splicing each fragment. The response is complete when the complete tuples for each requested attribute has been received.

 

Get App Attributes

The Get App Attributes command allows an NC to retrieve attributes of a specific app installed on the NP. The format of the Get App Attributes command is shown inFigure 2-5.

Figure 2-5  The format of a Get App Attributes command

A Get App Attributes command contains the following information:

• CommandID: Should be set to 1 (CommandIDGetAppAttributes).

• AppIdentifier: The string identifier of the app the client wants information about. This string must be NULL-terminated.

• AttributeIDs: A list of attributes the NC wants to retrieve.

The format of a response to a Get App Attributes command is shown in Figure 2-6.

Figure 2-6  The format of a response to a Get App Attributes command

A response to a Get App Attributes command contains the following information:

• CommandID: Set to 1 (CommandIDGetAppAttributes).

• AppIdentifier: The string identifier of the app the following attributes correspond to. This string is NULL-terminated.

• AttributeList: A list of AttributeIDs/16-bit Length/Attribute tuples. An attribute is always a string whose length in bytes is provided in the tuple but that is not NULL-terminated. If a requested attribute is empty or missing for the app, its length is set to 0. The tuples are always in the same order as the AttributeIDs of the Get App Attributes command.

As with a response to a Get Notification Attributes command, if the response to a Get App Attributes command is larger than the negotiated GATT Maximum Transmission Unit (MTU), it is split into multiple fragments by the NP. The NC must recompose the response by splicing each fragment. The response is complete when the complete tuples for each requested attribute has been received.

 

Perform Notification Action

The Perform Notification Action command allows an NC to perform a predetermined action on a specific iOS notification. A Perform Notification Action command contains the following fields:

No data is generated on the Data Source characteristic when this command is issued, whether it is successful or not.

 

Notification Actions

Starting with iOS 8.0, the NP can inform the NC of potential actions that are associated with iOS notifications. On the user’s behalf, the NC can then request the NP to perform an action associated with a specific iOS notification.

The NC is informed of the existence of performable actions on an iOS notification by detecting the presence of set flags in theEventFlags field of the GATT notifications generated by the Notification Source characteristic:

• EventFlagPositiveAction: A positive action exists and is associated with this iOS notification.

• EventFlagNegativeAction: A negative action exists and is associated with this iOS notification.

The actual actions performed by the NP on behalf of the NC are determined by the NP and vary depending on the iOS notification they are performed on. For example, performing a positive action on an Incoming Call notification may answer it, while performing a negative action may decline it.

The NC must neither assume nor try to guess in advance the exact action performed on an iOS Notification, because these actions are based upon information unavailable to it, as well as other factors such as the ANCS version implemented by the NP. The NP guarantees that positive and negative actions are associated with results that do not surprise the user.

If present for an iOS notification, positive and negative actions may be represented to the user as check marks, X marks, or colors commonly associated with acknowledgment and dismissal (such as green and red).

The NC can retrieve labels that succinctly describe the actual actions associated with an iOS notification by retrieving new notification attributes introduced in iOS 8.0:

• NotificationAttributeIDPositiveActionLabel: The label used to describe the positive action that can be performed on the iOS notification.

• NotificationAttributeIDNegativeActionLabel: The label used to describe the negative action that can be performed on the iOS notification.

 

Sessions

An ANCS session begins when an NC subscribes to the Notification Source characteristic on an NP and ends when the NC either unsubscribes from the same characteristic or disconnects from the NP. Because the ANCS is not designed to be a complete synchronization service, it does not keep track of state across sessions. As a result, all identifiers (such as NotificationUID and AppIdentifier) and all data exchanged between an NC and an NP are valid only within a particular session.

When a particular session ends, the NC should remove any identifiers and data it gathered and stored during the session. When a new session begins, the NP does its best to inform the NC of any existing iOS notifications on the system. The NC can use this information to build a model to use for the remainder of the session.

 

Attribute Fetching and Caching

It is strongly recommended for an NC to fetch attributes only as needed and possibly in response to user actions. For example, if an NC chooses to display active iOS notifications in a simple list, and to show only details about a specific iOS notification when selected by the user, then the retrieval of this iOS notification’s attributes can be triggered lazily.

During a session, it is strongly recommended that an NC build a cache of App Attributes for each app identifier it encounters. Building this cache allows the NC to avoid retrieving the same immutable App Attributes multiple times—saving time and preserving battery.

 

Error Codes

When writing to the Control Point characteristic, an NC may receive the following ANCS-specific error codes:

• Unknown command (0xA0): The commandID was not recognized by the NP.

• Invalid command (0xA1): The command was improperly formatted.

• Invalid parameter (0xA2): One of the parameters (for example, the NotificationUID) does not refer to an existing object on the NP.

• Action failed (0xA3): The action was not performed.

If the NP replies with an error, it will not generate any GATT notification on the Data Source characteristic for the corresponding command.

 

Example Diagrams

The following two figures show examples of two common interactions between an NP and an NC.Figure 2-7 shows the typical sequence of commands and responses needed to set up the ANCS on an NC.Figure 2-8 shows the typical sequence of commands and responses needed to get more information about an iOS notification in order to display it on an NC.

Figure 2-7  Service setup exampleFigure 2-8  Notification attribute retrieval example

 

Appendix

 

The following tables list important values used in the ANCS.

 

CategoryID Values