如何发现ANCS服务，发现ANCS服务的过程是怎样的？怎么知道成功发现了ANCS服务？
最近，一直在研究ANCS，参考的例程是：http://processors.wiki.ti.com/index.php/Cc2640_ANCS_Sample#Demo_guide
我研究的是：如何在2640实现发现ANCS的服务。
但是对发现ANCS服务的过程，感觉理解的不够透彻。
我的问题是：
如何发现ANCS服务，发现ANCS服务的过程是怎样的？怎么知道成功发现了ANCS服务？
以下是我对发现ANCS服务的一些理解：
外围设备作为GATT client，需要发现ios设备的ANCS服务（service）和特征值（characteristics）,这一步就是由ancs_discovery.c 文件中的Ancs_discover函数实现。Ancs_discover利用特定状态值来发现ANCS服务（特定状态值见附录一），来函数会发现ANCS的服务和3个特征值（三个特征值具体见附录二），并且保存句柄。
Ancs_discover函数的框架如下：
static uint8_t Ancs_discover(uint8_t state, gattMsgEvent_t *pMsg)
{
uint8_t newState = state;
static uint8_t isNotifCCCD = FALSE;
switch (state)
{
case DISC_ANCS_START:
:
case DISC_ANCS_SVC:
:
case DISC_ANCS_CHAR:
:
switch (uuid)
{
case ANCS_NOTIF_SRC_CHAR_UUID:
Ancs_handleCache[HDL_ANCS_NTF_NOTIF_START] = handle;
Ancs_endHdlIdx = HDL_ANCS_NTF_NOTIF_END;
LCD_WRITE_STRING("Found: Ntfi char", LCD_PAGE1);
break;
case ANCS_CTRL_PT_CHAR_UUID:
LCD_WRITE_STRING("Found: Ctrl pt char", LCD_PAGE2);
break;
case ANCS_DATA_SRC_CHAR_UUID:
Ancs_handleCache[HDL_ANCS_DATA_SRC_START] = handle;
Ancs_endHdlIdx = HDL_ANCS_DATA_SRC_END;
LCD_WRITE_STRING("Found: data src char", LCD_PAGE3);
break;
default:
break;
}
:
case DISC_ANCS_CCCD:
:
}
======================================================================
附录一：
// ANCS discovery states
enum
{
DISC_IDLE = 0x00, // Idle state
DISC_ANCS_START = 0x10, // ANCS service
DISC_ANCS_SVC, // Discover service
DISC_ANCS_CHAR, // Discover all characteristics
DISC_ANCS_CCCD, // Discover ANCS CCCD
DISC_FAILED = 0xFF // Discovery failed
};
附录二：
ANCS Service Characteristics:
● Notification Source: UUID: 9FBF120D-6301-42D9-8C58-25E699A21DBD (notifiable) 基本通知源，通知一些计数的信息
● Control Point: UUID: 69D1D8F3-45E1-49A8-9821-9BBDFDAAD9D9 (writeable with response)控制器，用于向ios设备写入控制信息，例如读取详情
● Data Source: UUID: 22EAC6E9-24D6-4BB5-BE44-B36ACE7C7BFB (notifiable) 数据源，用于提供详细数据，在控制信息写入后通过此characteristic返回
你好，
回答你的问题之前，我们先搞清楚ANCS源头，本质上是CC2640作为客户端发现IOS系统上的服务，然后订阅服务，读取参数的过程！
苹果通知中心（Apple Notification Center Service, ANCS）的目的是提供给蓝牙外设一种简单、方便的获取ios设备通知信息的方式。
依赖
ANCS的使用没有依赖，它是GATT的一个子集，任何一个实现了GATT client的设备可以方便的从ios设备获取通知信息。
传输注意事项
如果没有特殊说明，通过ANCS传输的数值均使用小端模式。
如果没有特殊说明，通过ANCS传输的字符串均使用UTF-8编码。
概念定义
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返回的都是啥：
电话：
|
AttrID |
返回值 |
|
0(App ID) |
com.apple.mobilephone |
|
1(Title) |
1 (326) 021-3971（电话号码，不过划分方式好怪。。。） 如果此号码存了名字，则是电话本中的名字 |
|
2(SubTitle) |
空 如果此号码存了名字，则是mobile |
|
3(Message) |
Incoming Call |
短信：
|
AttrID |
返回值 |
|
0(App ID) |
com.apple.MoileSMS |
|
1(Title) |
10698109555991 01051726663 +86 132-6021-3971 如果此号码存了名字，则是电话本中的名字 |
|
2(SubTitle) |
空 |
|
3(Message) |
短信的内容 |
微信：
|
AttrID |
返回值 |
|
0(App ID) |
com.tencent.xin |
|
1(Title) |
微信 |
|
2(SubTitle) |
空 |
|
3(Message) |
发信人:内容 |
其他应用的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