孩子手里的小米手表怎么和同桌的华为手表加上好友放在三年前答案基本是不能。小天才封闭社交、各家碰一碰只认自家。直到 2025-12-02GB 46859-2025《儿童手表安全技术要求》正式发布2027-01-01 强制实施——跨品牌加好友从一个看厂商心情的功能变成了一条写进国家标准的硬性要求。而且不是说说而已头部几个大厂拿出了一个连通方案。这篇文章不是复述规范条文。我手上有一份真实的 nRF 抓包儿童手表小米华为.pcapng56098 帧27.7 秒里面正好是一台小米 Mi Kids Watch和一台华为 K3I完成一次完整加好友的全过程。我把它逐帧拆开让你看清标准里那一两百字的交换电话号码落到空口上到底是什么字节流。先说结论跨品牌加好友是有强制标准的GB 46859-2025 的第 4.18 条标题就叫交换电话号码原文是要求儿童智能手表允许不同品牌手表之间交换电话号码和昵称。这是这份国标里最拆生态墙的一条——只要双方都是合规儿童手表就必须能换联系方式厂商不能拿我家封闭当理由。几个关键时间点发布 2025-12-02实施 2027-01-01实施之日前已生产/进口的产品自实施起第 13 个月约 2028-01起也必须满足——给存量留了升级窗口小米、华为、小天才、360 全部是起草单位。标准是这几位老对手一起写的这是跨品牌互加能落进强制标准的关键。一句话概括它的技术路线BLE 广播一个服务 UUID → 连接 → GATT 服务发现 → 数字比对配对 → 链路加密 → 在加密的 GATT 读写里换掉电话号码和昵称。下一个问题是不同品牌的表靠什么认出彼此能加好友互操作的两把钥匙一模一样的 UUID跨品牌互通最怕的两个字是私有。A 牌私有格式B 牌根本不认。国标解决这个问题的办法特别嵌入式用两个固定 UUID 一个 20 字节格式把整个行业的数据面拉平。附录 A规定一个 128 位服务标识6d293d29-cee2-4ace-aa7a-1909e34e4298。手表要把它塞进 BLE 广播包让对方扫到就知道这是一块支持国标加好友的儿童手表。附录 B规定这个服务里一个特征的 UUID4a3510a8-b8f5-42b7-9870-8901807b229f以及它的属性值格式——一个 TLV 自描述结构------------------------------------------------------------------- | 号码长度(1B) | 电话号码(E.164) | 昵称长度(1B) | 昵称(UTF-8) | -------------------------------------------------------------------标准示例就一行15 008613912345678 2 张三。意思是号码长 15 字节号码 008613912345678昵称长 2 字节昵称 张三。两个不同品牌的手表不需要任何私有协商central 去读对端这个特征按固定格式一解号码和昵称就到手了。这就是20 字节拉平全行业的工程含义——也是最漂亮的设计点实现成本低到任何有 BLE 栈的团队都接得起。主角登场抓包里那一对陌生表继续往下之前先交代清楚这份抓包到底是什么。设备外设是一台小米 Mi Kids Watch地址7e:a7:0d:3e:f7:d4它一直在广播广播里就带着附录 A 的服务 UUID。发起方是一台华为 K3I它的地址是轮换的RPA是靠 CONNECT_REQ 里留下的地址 它停止广播的时间点交叉推断出来的。数据连接一共三条加好友会话只是其中一条——注意它的 Access Address 和属性Access Address报文数时间窗口性质0x29c2c8c86145全程小米私有55 AA F0定长帧已加密0x71f64469104314.5~20.5s★ 跨品牌加好友会话本文主角0x323c98bb1033全程另一条后台连接那个时间窗口很关键一次完整的加好友只花约 6 秒从 14.5s 建立连接到 20.5s 结束。这一小段就是国标从纸面落到空口的全过程。逐帧拆包6 秒里到底发生了什么照 GB 4.18 的要求顺序一帧一帧看。第 ① 步广播里藏着国标身份pkt185小米手表的广播包ADV_IND信道 39里有一串 EIREIR 0x07 Complete List of 128-bit Service Class UUIDs: 6d293d29-cee2-4ace-aa7a-1909e34e4298华为手表正是扫到这串 UUID才认出这是支持国标加好友的儿童手表于是发起连接。这里有个必踩的坑BLE 在空口传输 128 位 UUID 用的是小端字节序。6d293d29-...在空口原始字节里长这样11 07 98 42 4e e3 09 19 7a aa ce 4a e2 ce 29 3d 29 6d98 42 4e e3 ...——完全反着的顺序。你要是按打印出来的大端去搜结果是零命中然后就开始怀疑是不是厂商没实现。我在分析时就踩过这个坑折腾了一阵写出来给各位避雷分析 BLE 时search 小端字节流别 search 大端 UUID。第 ② ③ 步建连 能力协商CONNECT_REQ 由华为发起连接间隔 30ms。随后是常规的 LL 层握手LL_FEATURE_REQ/RSP、CONNECTION_PARAM协商链路特性。这一段相对朴素真正精彩从 GATT 发现开始。第 ④ 步GATT 服务发现挖出国标那两把钥匙华为作为 central先发Read By Group Type遍历主服务在 pkt27479 里挖到了目标主服务 句柄 0x0028-0xFFFF, UUID 6d293d29-cee2-4ace-aa7a-1909e34e4298紧接着Read By Type在服务内发现特征pkt28529关键字节是这一行09 15 2900 0a 2a 00 9f227b80 0189 7098 b742f5b8 a810354a └op└len└声明句柄└props└值句柄└──── 属性UUID 附录B ────┘这里那个0a是 properties 位0x0A 00001010 → READ(0x02) WRITE(0x08)不含 Notify/Indicate。也就是说小米手表把这个特征暴露成可读可写。再往后华为用Find Information探测特征之后有没有描述符得到一个Attribute Not Found——意思是这个特征没有 CCCD彻底没有 Notify/Indicate 通知这条路。重建出来的小米侧 GATT 表0x0028-0xFFFF 电话号码交互服务 (6d293d29-...) ← 附录A └ 0x0029 特征声明 (properties READWRITE 0x0A) └ 0x002a 特征值: 电话号码昵称 (4a3510a8-...) ← 附录B (无 CCCD → 无 Notify, 双向只能靠 ReadWrite)第 ⑤ 步数字比对配对然后链路加密配对走的是LE Secure Connections。抓包看到 SMP 交换了 P-256 公钥配对方法解析为Numeric Comparison——两张表屏幕上各显示一个 6 位数字由佩戴的孩子/家长确认一致后配对生效。这有两层含义防中间人攻击者没法让两侧数字一致又保留人的确认环节。随后进入链路层加密握手pktLL 控制报文含义36166LL_ENC_REQ(0x03)主机携带 SKD/IV 请求启动加密36185LL_ENC_RSP(0x04)从机回应36187LL_START_ENC_REQ(0x05)从机确认启动之后LL_START_ENC_RSP进入 AES-128-CCM 密文阶段加密之后scapy 等通用解析器只能看到乱码化的 L2CAP伪 CID——那些其实是密文 ATT 帧内容正是按附录 B 格式交换的电话号码和昵称。这一点非常关键也容易误解这乱码不是抓包失败恰恰是 GB 4.18.2电话信息加密传输达标的证据。空口视角下号码和昵称的明文从头到尾没出现过——这正是这份国标想要的效果号码可以当面换但绝不在无线空口裸奔。第 ⑥ 步收尾t≈20.5s 后连接无新报文会话结束。全程约 6 秒发现 3s → 配对加密 2s → 交换 1s。一次跨品牌加好友比想象中快得多也安静得多——不值得在隔壁都能用手机抓到的时间窗里拖泥带水。一个我把结论改了三遍的疑点信息到底怎么双向交换写到这里有个问题一直缠着我听起来是发起方读了被加方的号码小米这边算是把信息给过去了可华为怎么把自己的信息给小米看来方向很明确华为 central 读小米 peripheral。那小米怎么读华为答案有点意外——查遍了这份实际抓包华为根本没法往小米写。这个疑点我最初跑偏过两次。第一次想既然从机特征可能只读那从机是不是回头反向连一次主机把信息送出去也就是角色反转。对照真实时间线后我否定了它这个加好友会话全程只有一次加密握手、没有第二段 CONNECT_REQ、没有反向连接。第二次想会不会是同一条连接里靠其他可写/可通知通道偷偷送也否定了华为在可读阶段对小米的写请求是 0 次Write Request 0x12、Write Command 0x52、Prepare/Execute Write 全都为 0而小米侧除了标准电话号码服务没有第二个两厂商共通的私有可写句柄。写都没地方落。于是我把它拆成三层诚实地看A. 抓包可证的事实- 华为 central 在可读阶段对小米0 次写入只做服务/特征发现 读 - 会话只有一次加密握手没有第二次连接没有角色反转。B. 抓包可证的排除- 排除华为从 BLE 写号码给小米 - 排除反向连接/角色反转。注意排除了 X ≠ 证明了 Y。走到BLE 这条路被堵死就到头了。信息到底走哪条路只能算推测C. 推测标注置信度中高——华为→小米那一向走云端最合理的解释是那块手表把华为的号码经蜂窝网络上报云端云端再异步处理好友关系。间接佐证有几个华为官方明确加好友需网络SIM 卡好友关系在云端落地、家长可云端拒绝、跨品牌需互联互通认证。如果这个转发本就走蓝牙空口为什么强制要求插 SIM 卡——这是必须插卡最强的合理解释。但我必须诚实没有任何公开规范或官方文档直接白纸黑字陈述跨品牌加好友时联系人数据经厂商云在两品牌间转发。这一环节的具体实现我无法从已拿到的证据直接确认所以它只能是推测/最可能不是定论。要把它做实得用带 LTK 的嗅探器解密密文段、或逆向手表固件。在此之前我不给华为→小米走云端这个说法盖上事实的戳。这一段特别想传达给同行的是一个方法论做协议分析最该警惕的是把排除了 A顺嘴讲成那就是 B。分析可以大胆下结论要能分清抓到的事实和推出来的猜想。为什么加好友离不开 SIM 卡顺着上一节的推测实测情况是两台表互加好友必须插 SIM有 4G只连 WiFi 不行。这和走云端的推测高度咬合。华为官方文档给了三处佐证2026-09 查证摇一摇加好友使用前请确保手表蓝牙已开启、网络连接正常、且已安装 SIM 卡——同品牌加好友三件套缺一不可跨品牌添加联系人使用前请确保蓝牙已开启且网络连接正常添加成功后家长在智能关怀的消息通知可看到添加联系人通知失败排查第一步就是确保网络正常后重新摇一摇。蜂窝网络在这套流程里大概要干三件事。我说大概因为每一条都有置信度差别别当铁律看云端好友关系落地置信度高家长能云端拒绝、删除好友说明好友关系记录在云端账号体系手表本地只是缓存家长管控通知通路置信度高这也是标准明文要求——4.18.1a 规定受手表管理端管理家长不在孩子身边管控指令只能云端中转身份合法性校验置信度中附录 B 交换的是 E.164 号码本地 SIM 无号时流程直接失败官方提示号码为空的排查项侧面印证。至于为什么 WiFi 不行的具体机制云端长连接绑定蜂窝身份 / 手表 WiFi 阉割 / 流程硬校验目前都只是推断要抓手表↔云端的蜂窝流量或逆向固件才能实锤。这里我给的都是最可能不给一定。行业坐标国标出台前跨品牌社交怎么活没人喜欢被一个国标从头上套下来但加好友这个需求一直在。国标之前市场上有三种自发方案腾讯系儿童 App360、荣耀、REDMI 的路子手表 QQ 碰一碰互加跨品牌靠腾讯账号体系但依赖网络和腾讯生态电话号码通讯录小天才的路子管理员从 App 把任意品牌号码存进通讯录互通靠电话短信完全封闭部分品牌只能和自家玩。GB 46859 的策略很聪明不是取缔这些而是强制加一条不依赖任何第三方生态的设备直连通道蓝牙 GATT 交换号码。结果就是——任何两块国标合规的表哪怕都没装微信、都没插流量卡也能面对面完成基础互加。现在的生态信号小天才 Z12 从 1.1.0 起支持蓝牙添加联系人机制与国标 4.18 高度同源华为跨品牌文档里的互联互通认证名单小天才 Z12 / 小米 / 360 12X / 荣耀 WhizKid / 小寻 M7 等就是这套服务在产业侧的实际落地。抓包时间在 2026功能上线早于 2027 强制实施说明头部厂商选了提前合规——商战归商战该接的底线谁也没含糊。给嵌入式同行的实现清单如果你现在要在自家手表上把这套国标功能做出来这份从抓包逆向出的清单可以直接抄广播EIR 0x07 携带6d293d29-...记得支持 RPA抓包证实小米在轮换GATT主服务 特征4a3510a8-...properties至少要有 READ想走 Notify 推送当面交换得加 CCCD并处理好华为实测从机特征只读、无 Notify这个兼容边界——别默认对方一定会来读也别默认对方肯让你写属性值严格按附录 B TLV昵称用 UTF-8配对LE Secure Connections Numeric Comparison禁止 Just Works防中间人全靠它时序先完成加密、再交换号码——实测小米/华为就是这个顺序别把号码发在明文段管理端功能开关、加好友通知家长、通讯录删除一个不能少4.18.1a/c 是硬要求。收尾20 字节和一颗敬重事实的心回头想想这件小事其实挺震撼一个影响全行业、牵扯 14 岁以下儿童个人信息安全的标准功能它的递物层就 20 个字节——一个长度字节、一个 E.164 号码、一个长度字节、一个昵称。而它背后是要被强制执行的数字比对、链路加密、家长管控三条安全底线。至于另一向到底怎么走我保留推测也明确告诉读者它哪里没被证实。这趟抓包分析最大的收获不是解出了某个手表的私有实现而是学会了对证据链诚实——抓到什么说什么没抓到的明明白白标成还没抓到。你要是也在做嵌入式或 BLE欢迎聊聊你遇到过哪些因为可以看出细节、实则串了同一套标准的互通坑觉得有用的话点个在看让更多做硬件协议的工程师看到这份实拍。本文基于作者独立采集与分析的 BLE 空口抓包数据写成文中对标准条文的理解参考 GB 46859-2025对无法直接查证方向的部分已如实标注为推测欢迎批评指正。
孩子手里的小米手表怎么和同桌的华为手表加上好友放在三年前答案基本是不能。小天才封闭社交、各家碰一碰只认自家。直到 2025-12-02GB 46859-2025《儿童手表安全技术要求》正式发布2027-01-01 强制实施——跨品牌加好友从一个看厂商心情的功能变成了一条写进国家标准的硬性要求。而且不是说说而已头部几个大厂拿出了一个连通方案。这篇文章不是复述规范条文。我手上有一份真实的 nRF 抓包儿童手表小米华为.pcapng56098 帧27.7 秒里面正好是一台小米 Mi Kids Watch和一台华为 K3I完成一次完整加好友的全过程。我把它逐帧拆开让你看清标准里那一两百字的交换电话号码落到空口上到底是什么字节流。先说结论跨品牌加好友是有强制标准的GB 46859-2025 的第 4.18 条标题就叫交换电话号码原文是要求儿童智能手表允许不同品牌手表之间交换电话号码和昵称。这是这份国标里最拆生态墙的一条——只要双方都是合规儿童手表就必须能换联系方式厂商不能拿我家封闭当理由。几个关键时间点发布 2025-12-02实施 2027-01-01实施之日前已生产/进口的产品自实施起第 13 个月约 2028-01起也必须满足——给存量留了升级窗口小米、华为、小天才、360 全部是起草单位。标准是这几位老对手一起写的这是跨品牌互加能落进强制标准的关键。一句话概括它的技术路线BLE 广播一个服务 UUID → 连接 → GATT 服务发现 → 数字比对配对 → 链路加密 → 在加密的 GATT 读写里换掉电话号码和昵称。下一个问题是不同品牌的表靠什么认出彼此能加好友互操作的两把钥匙一模一样的 UUID跨品牌互通最怕的两个字是私有。A 牌私有格式B 牌根本不认。国标解决这个问题的办法特别嵌入式用两个固定 UUID 一个 20 字节格式把整个行业的数据面拉平。附录 A规定一个 128 位服务标识6d293d29-cee2-4ace-aa7a-1909e34e4298。手表要把它塞进 BLE 广播包让对方扫到就知道这是一块支持国标加好友的儿童手表。附录 B规定这个服务里一个特征的 UUID4a3510a8-b8f5-42b7-9870-8901807b229f以及它的属性值格式——一个 TLV 自描述结构------------------------------------------------------------------- | 号码长度(1B) | 电话号码(E.164) | 昵称长度(1B) | 昵称(UTF-8) | -------------------------------------------------------------------标准示例就一行15 008613912345678 2 张三。意思是号码长 15 字节号码 008613912345678昵称长 2 字节昵称 张三。两个不同品牌的手表不需要任何私有协商central 去读对端这个特征按固定格式一解号码和昵称就到手了。这就是20 字节拉平全行业的工程含义——也是最漂亮的设计点实现成本低到任何有 BLE 栈的团队都接得起。主角登场抓包里那一对陌生表继续往下之前先交代清楚这份抓包到底是什么。设备外设是一台小米 Mi Kids Watch地址7e:a7:0d:3e:f7:d4它一直在广播广播里就带着附录 A 的服务 UUID。发起方是一台华为 K3I它的地址是轮换的RPA是靠 CONNECT_REQ 里留下的地址 它停止广播的时间点交叉推断出来的。数据连接一共三条加好友会话只是其中一条——注意它的 Access Address 和属性Access Address报文数时间窗口性质0x29c2c8c86145全程小米私有55 AA F0定长帧已加密0x71f64469104314.5~20.5s★ 跨品牌加好友会话本文主角0x323c98bb1033全程另一条后台连接那个时间窗口很关键一次完整的加好友只花约 6 秒从 14.5s 建立连接到 20.5s 结束。这一小段就是国标从纸面落到空口的全过程。逐帧拆包6 秒里到底发生了什么照 GB 4.18 的要求顺序一帧一帧看。第 ① 步广播里藏着国标身份pkt185小米手表的广播包ADV_IND信道 39里有一串 EIREIR 0x07 Complete List of 128-bit Service Class UUIDs: 6d293d29-cee2-4ace-aa7a-1909e34e4298华为手表正是扫到这串 UUID才认出这是支持国标加好友的儿童手表于是发起连接。这里有个必踩的坑BLE 在空口传输 128 位 UUID 用的是小端字节序。6d293d29-...在空口原始字节里长这样11 07 98 42 4e e3 09 19 7a aa ce 4a e2 ce 29 3d 29 6d98 42 4e e3 ...——完全反着的顺序。你要是按打印出来的大端去搜结果是零命中然后就开始怀疑是不是厂商没实现。我在分析时就踩过这个坑折腾了一阵写出来给各位避雷分析 BLE 时search 小端字节流别 search 大端 UUID。第 ② ③ 步建连 能力协商CONNECT_REQ 由华为发起连接间隔 30ms。随后是常规的 LL 层握手LL_FEATURE_REQ/RSP、CONNECTION_PARAM协商链路特性。这一段相对朴素真正精彩从 GATT 发现开始。第 ④ 步GATT 服务发现挖出国标那两把钥匙华为作为 central先发Read By Group Type遍历主服务在 pkt27479 里挖到了目标主服务 句柄 0x0028-0xFFFF, UUID 6d293d29-cee2-4ace-aa7a-1909e34e4298紧接着Read By Type在服务内发现特征pkt28529关键字节是这一行09 15 2900 0a 2a 00 9f227b80 0189 7098 b742f5b8 a810354a └op└len└声明句柄└props└值句柄└──── 属性UUID 附录B ────┘这里那个0a是 properties 位0x0A 00001010 → READ(0x02) WRITE(0x08)不含 Notify/Indicate。也就是说小米手表把这个特征暴露成可读可写。再往后华为用Find Information探测特征之后有没有描述符得到一个Attribute Not Found——意思是这个特征没有 CCCD彻底没有 Notify/Indicate 通知这条路。重建出来的小米侧 GATT 表0x0028-0xFFFF 电话号码交互服务 (6d293d29-...) ← 附录A └ 0x0029 特征声明 (properties READWRITE 0x0A) └ 0x002a 特征值: 电话号码昵称 (4a3510a8-...) ← 附录B (无 CCCD → 无 Notify, 双向只能靠 ReadWrite)第 ⑤ 步数字比对配对然后链路加密配对走的是LE Secure Connections。抓包看到 SMP 交换了 P-256 公钥配对方法解析为Numeric Comparison——两张表屏幕上各显示一个 6 位数字由佩戴的孩子/家长确认一致后配对生效。这有两层含义防中间人攻击者没法让两侧数字一致又保留人的确认环节。随后进入链路层加密握手pktLL 控制报文含义36166LL_ENC_REQ(0x03)主机携带 SKD/IV 请求启动加密36185LL_ENC_RSP(0x04)从机回应36187LL_START_ENC_REQ(0x05)从机确认启动之后LL_START_ENC_RSP进入 AES-128-CCM 密文阶段加密之后scapy 等通用解析器只能看到乱码化的 L2CAP伪 CID——那些其实是密文 ATT 帧内容正是按附录 B 格式交换的电话号码和昵称。这一点非常关键也容易误解这乱码不是抓包失败恰恰是 GB 4.18.2电话信息加密传输达标的证据。空口视角下号码和昵称的明文从头到尾没出现过——这正是这份国标想要的效果号码可以当面换但绝不在无线空口裸奔。第 ⑥ 步收尾t≈20.5s 后连接无新报文会话结束。全程约 6 秒发现 3s → 配对加密 2s → 交换 1s。一次跨品牌加好友比想象中快得多也安静得多——不值得在隔壁都能用手机抓到的时间窗里拖泥带水。一个我把结论改了三遍的疑点信息到底怎么双向交换写到这里有个问题一直缠着我听起来是发起方读了被加方的号码小米这边算是把信息给过去了可华为怎么把自己的信息给小米看来方向很明确华为 central 读小米 peripheral。那小米怎么读华为答案有点意外——查遍了这份实际抓包华为根本没法往小米写。这个疑点我最初跑偏过两次。第一次想既然从机特征可能只读那从机是不是回头反向连一次主机把信息送出去也就是角色反转。对照真实时间线后我否定了它这个加好友会话全程只有一次加密握手、没有第二段 CONNECT_REQ、没有反向连接。第二次想会不会是同一条连接里靠其他可写/可通知通道偷偷送也否定了华为在可读阶段对小米的写请求是 0 次Write Request 0x12、Write Command 0x52、Prepare/Execute Write 全都为 0而小米侧除了标准电话号码服务没有第二个两厂商共通的私有可写句柄。写都没地方落。于是我把它拆成三层诚实地看A. 抓包可证的事实- 华为 central 在可读阶段对小米0 次写入只做服务/特征发现 读 - 会话只有一次加密握手没有第二次连接没有角色反转。B. 抓包可证的排除- 排除华为从 BLE 写号码给小米 - 排除反向连接/角色反转。注意排除了 X ≠ 证明了 Y。走到BLE 这条路被堵死就到头了。信息到底走哪条路只能算推测C. 推测标注置信度中高——华为→小米那一向走云端最合理的解释是那块手表把华为的号码经蜂窝网络上报云端云端再异步处理好友关系。间接佐证有几个华为官方明确加好友需网络SIM 卡好友关系在云端落地、家长可云端拒绝、跨品牌需互联互通认证。如果这个转发本就走蓝牙空口为什么强制要求插 SIM 卡——这是必须插卡最强的合理解释。但我必须诚实没有任何公开规范或官方文档直接白纸黑字陈述跨品牌加好友时联系人数据经厂商云在两品牌间转发。这一环节的具体实现我无法从已拿到的证据直接确认所以它只能是推测/最可能不是定论。要把它做实得用带 LTK 的嗅探器解密密文段、或逆向手表固件。在此之前我不给华为→小米走云端这个说法盖上事实的戳。这一段特别想传达给同行的是一个方法论做协议分析最该警惕的是把排除了 A顺嘴讲成那就是 B。分析可以大胆下结论要能分清抓到的事实和推出来的猜想。为什么加好友离不开 SIM 卡顺着上一节的推测实测情况是两台表互加好友必须插 SIM有 4G只连 WiFi 不行。这和走云端的推测高度咬合。华为官方文档给了三处佐证2026-09 查证摇一摇加好友使用前请确保手表蓝牙已开启、网络连接正常、且已安装 SIM 卡——同品牌加好友三件套缺一不可跨品牌添加联系人使用前请确保蓝牙已开启且网络连接正常添加成功后家长在智能关怀的消息通知可看到添加联系人通知失败排查第一步就是确保网络正常后重新摇一摇。蜂窝网络在这套流程里大概要干三件事。我说大概因为每一条都有置信度差别别当铁律看云端好友关系落地置信度高家长能云端拒绝、删除好友说明好友关系记录在云端账号体系手表本地只是缓存家长管控通知通路置信度高这也是标准明文要求——4.18.1a 规定受手表管理端管理家长不在孩子身边管控指令只能云端中转身份合法性校验置信度中附录 B 交换的是 E.164 号码本地 SIM 无号时流程直接失败官方提示号码为空的排查项侧面印证。至于为什么 WiFi 不行的具体机制云端长连接绑定蜂窝身份 / 手表 WiFi 阉割 / 流程硬校验目前都只是推断要抓手表↔云端的蜂窝流量或逆向固件才能实锤。这里我给的都是最可能不给一定。行业坐标国标出台前跨品牌社交怎么活没人喜欢被一个国标从头上套下来但加好友这个需求一直在。国标之前市场上有三种自发方案腾讯系儿童 App360、荣耀、REDMI 的路子手表 QQ 碰一碰互加跨品牌靠腾讯账号体系但依赖网络和腾讯生态电话号码通讯录小天才的路子管理员从 App 把任意品牌号码存进通讯录互通靠电话短信完全封闭部分品牌只能和自家玩。GB 46859 的策略很聪明不是取缔这些而是强制加一条不依赖任何第三方生态的设备直连通道蓝牙 GATT 交换号码。结果就是——任何两块国标合规的表哪怕都没装微信、都没插流量卡也能面对面完成基础互加。现在的生态信号小天才 Z12 从 1.1.0 起支持蓝牙添加联系人机制与国标 4.18 高度同源华为跨品牌文档里的互联互通认证名单小天才 Z12 / 小米 / 360 12X / 荣耀 WhizKid / 小寻 M7 等就是这套服务在产业侧的实际落地。抓包时间在 2026功能上线早于 2027 强制实施说明头部厂商选了提前合规——商战归商战该接的底线谁也没含糊。给嵌入式同行的实现清单如果你现在要在自家手表上把这套国标功能做出来这份从抓包逆向出的清单可以直接抄广播EIR 0x07 携带6d293d29-...记得支持 RPA抓包证实小米在轮换GATT主服务 特征4a3510a8-...properties至少要有 READ想走 Notify 推送当面交换得加 CCCD并处理好华为实测从机特征只读、无 Notify这个兼容边界——别默认对方一定会来读也别默认对方肯让你写属性值严格按附录 B TLV昵称用 UTF-8配对LE Secure Connections Numeric Comparison禁止 Just Works防中间人全靠它时序先完成加密、再交换号码——实测小米/华为就是这个顺序别把号码发在明文段管理端功能开关、加好友通知家长、通讯录删除一个不能少4.18.1a/c 是硬要求。收尾20 字节和一颗敬重事实的心回头想想这件小事其实挺震撼一个影响全行业、牵扯 14 岁以下儿童个人信息安全的标准功能它的递物层就 20 个字节——一个长度字节、一个 E.164 号码、一个长度字节、一个昵称。而它背后是要被强制执行的数字比对、链路加密、家长管控三条安全底线。至于另一向到底怎么走我保留推测也明确告诉读者它哪里没被证实。这趟抓包分析最大的收获不是解出了某个手表的私有实现而是学会了对证据链诚实——抓到什么说什么没抓到的明明白白标成还没抓到。你要是也在做嵌入式或 BLE欢迎聊聊你遇到过哪些因为可以看出细节、实则串了同一套标准的互通坑觉得有用的话点个在看让更多做硬件协议的工程师看到这份实拍。本文基于作者独立采集与分析的 BLE 空口抓包数据写成文中对标准条文的理解参考 GB 46859-2025对无法直接查证方向的部分已如实标注为推测欢迎批评指正。
