ANCS推送简介

总体原理
ANCS通过蓝牙BLE 4.0实现,仅支持iPhone 4S及以上且系统版本在IOS 7以上的手机,同时在外设端需要支持蓝牙4.0协议。

1、外设端进行广播,手机打开蓝牙,搜索外设,连接外设,之后进行绑定(这很重要,否则无法接收通知)

2、外设在连接建立后需要监听手机上的ANCS Service中的Notification Source

3、当有通知时,手机会给外设发消息,说明是哪个应用的通知

4、如果外设想进一步获取通知的详情,就往Control Point写控制信息,获取详情

5、详情会通过Data Source发过来


ANCS 服务

服务名: AppleNotification Center Service
UUID:7905F431-B5CE-4E99-A40F-4B1E122D00D0

角色:

NC:Notification Consumer  (i410e)
NP:Notification Provider  ([iOS](http://lib.csdn.net/base/1)设备)

服务特征值:

Notification Source:
UUID9FBF120D-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)

Note:访问该服务需要进行配对。
ANCS服务寻找完毕后,就可以打开监听通知功能了,这里需要注意的是,不能同一时间打开通知源特征Notification Source的通知和数据源特征Data Source的通知功能,所以这里可以开启了一个定时任务,让数据源特征在1s后再打来通知功能。

Notification Source

iOS设备(NP)用来通知i410e(NC)相应的通知;当i410e订阅(set Notify)该特征值后就可以接收通知消息(i410e已自动执行);
格式:


Category count: iOS通知中当前category的数量;(例如当有两个未读邮件的时候,又收到一个邮件通知,categoryCount就为3);
NotificationUID: 一个32位的唯一的数字ID,通过这个ID可以用来发送命令操作iOS通知。


Control Point 和 Data Source

NC可以通过Control Point 对iOS通知执行操作;(获取通知内容或者删除通知等)
NC通过对Control Point特征值写特殊的命令来实现获取通知内容等操作,如果执行成功,NP就会迅速的通过Data Source 特征值的发送通知内容到NC来响应该操作。
共三种:

  • 1.获取通知属性


该命令通过Control Point发出

CommandID :固定为0;
NotificationUID: 特定通知的ID,通过NS 的通知获取。
AttributeIDs:NC希望读取的变量ID列表,有些变量可能需要跟一个16bit的数说明想要的最大长度;
NP端响应格式:
该响应通过DS通知给到NC
CommandID :固定为0;
NotificationID: 特定通知的ID,通过NS 的通知获取。
Attribute List:查询结果列表,每一项的格式都是:ID/16bit  Length/Value,每个attribute都是一个字符串,其长度由Length指定,但是此字符串不是以NULL结尾。若找不到对应的Attribute,则Length为0

* 如果返回的消息长度大于GATT最大传输长度(MTU),则其会被分割成多个分段。蓝牙设备必须将这些分段组装起来。当所有请求属性的内容都接收完成后,此过程才算完成;
  • 2.获取App属性
通过Control Point发出
CommandID :固定为1;
AppIdentifier:app的字符串标识符,以Null结束。
AttributeIDs:希望获得属性的列表;
响应:
通过DS通知给到NC
CommandID :固定为1;
AppIdentifier:app的字符串标识符,以Null结束。
Attribute List:属性值列表,每一个格式都是:ID/16-bit Length/Value,每个attribute都是一个字符串,其长度由Length指定,但是此字符串不是以NULL结尾。若找不到对应的Attribute,则Length为0;

* 关于分段以及传输结束的判断标准,与Get Notification Attributes一致;
  • 3.对通知执行操作


CommandID :固定为2;
NotificationUID: 特定通知的ID,通过NS 的通知获取。
ActionID:从通知源中拿到的可以操作的类型,“积极”操作或“消极”操作.
从iOS8之后,NP可以通知NC一些相关的动作(接通、挂断电话;删除通知等),NC可以根据NP的通知执行对应的操作。
 
从NS的通知event flag中 EventFlagPositiveAction和EventFlagNegativeAction位可以判断是否能够执行对应的操作。
通过获取通知属性对应的属性IDNotificationAttributeIDPositiveActionLabel和NotificationAttributeIDNegativeActionLabel可以获取到对应的操作描述(接听/挂断、清楚)。

错误码:
对Control Point执行操作的时候,收到的NP端未识别的操作的响应


I410e 返回有区别,以规范为准。
0xAA0,
0xAA1,
0xAA2,
0xAA3,

实际实验之DataSource读取
主要是介绍一下读取的各个AttrID返回的都是啥:

0(App ID) ->com.apple.mobilephone

1(Title) ->1 (326) 021-3971(电话号码,不过划分方式好怪。。。)如果此号码存了名字,则是电话本中的名字

2(SubTitle) ->空 如果此号码存了名字,则是mobile

3(Message) ->Incoming Call

 
其他应用的ID:
短信: com.apple.MoileSMS
微信: com.tencent.xin
QQ: com.tencent.mqq
365: com.365rili.Coco
Any.Do:com.anydo.AnyDO
系统提示:com.apple.reminders
下面以来电为例,解析期间收到的通知。来电时存在两种操作,不同的操作会收到不同的通知。
1、接听了电话

(1)来了一同电话

BLE设备将会收到一则通知,如下:

0 1A 1 1 0 0 0 0

EventID——0:表示为增加一条通知。

EventFlags——1A:即0x1A,具有重要、具有“积极”操作、具有“消极”操作等特性。

CategoryID——1:通知的分类为来电。

CategoryCount——1:通知的个数为1
NotificationUID——0 0 0 0:即该通知的UID为0。

(2)接听了来电

接听来电后,会收到一条通知,如下:

2 1A 1 0 0 0 0 0

EventID——2:表示为删除一条通知。

EventFlags——1A:即0x1A,具有重要、具有“积极”操作、具有“消极”操作等特性。

CategoryID——1:通知的分类为来电。

CategoryCount——0:通知的个数为0。
NotificationUID——0 0 0 0:即该通知的UID为0。

解析出的意思是:删除来电通知。

2、拒接了电话

(1)来了一同电话

BLE设备将会收到一则通知,如下:

0 1A 1 1 0 0 0 0

EventID——0:表示为增加一条通知。

EventFlags——1A:即0x1A,具有重要、具有“积极”操作、具有“消极”操作等特性。

CategoryID——1:通知的分类为来电。

CategoryCount——1:通知的个数为1。
NotificationUID——0 0 0 0:即该通知的UID为0。

解析出来的意思就是说:来了一通电话。

(2)拒接了来电

如拒接了来电,BLE设备将收到两则通知,如下:

2 1A 1 0 0 0 0 0

0 18 2 1 1 0 0 0

对第一条通知进行解析如下:

EventID——2:表示为删除一条通知。

EventFlags——1A:即0x1A,具有重要、具有“积极”操作、具有“消极”操作等特性。

CategoryID——1:通知的分类为来电。

CategoryCount——0:通知的个数为0。
NotificationUID——0 0 0 0:即该通知的UID为0。

解析出的意思是:删除来电通知。

对第二条通知进行解析如下:

EventID——0:表示为新增一条通知。

EventFlags——18:即0x1A,具有重要、具有“消极”操作等特性。

CategoryID——2:通知的分类为未接来电。

CategoryCount——1:通知的个数为1。
NotificationUID——1 0 0 0:即该通知的UID为1。

翻译的意思是:一通未接来电。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,265评论 6 490
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,078评论 2 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 156,852评论 0 347
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,408评论 1 283
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,445评论 5 384
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,772评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,921评论 3 406
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,688评论 0 266
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,130评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,467评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,617评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,276评论 4 329
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,882评论 3 312
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,740评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,967评论 1 265
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,315评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,486评论 2 348

推荐阅读更多精彩内容