【HOGP】规范精讲[3]: HOGP设备开发避坑指南——HID Device端强制要求与实现细节全解析

做蓝牙键盘、鼠标、游戏手柄、遥控器这类BLE人机交互设备的开发者，大概率都有过这样的经历：硬件和固件都调通了，广播正常发送，串口看数据也正常上报，可Windows、macOS主机就是搜不到、连不上，要么连上了没反应，要么BQB认证的时候一堆合规性报错。

[一、先搞懂HID Device的服务基线，必选、可选、条件必选分清楚](#一、先搞懂HID Device的服务基线，必选、可选、条件必选分清楚)

二、核心服务的强制实现细节，每一条都是合规底线

[2.1 HID Service：整个设备的核心心脏，没有任何妥协空间](#2.1 HID Service：整个设备的核心心脏，没有任何妥协空间)

[三、Battery Service：必选的基础服务，别再只做报告里的电量了](#三、Battery Service：必选的基础服务，别再只做报告里的电量了)

[四、Device Information Service：必选的身份标识，PnP ID是重中之重](#四、Device Information Service：必选的身份标识，PnP ID是重中之重)

[五、Scan Parameters Service与HID ISO Service](#五、Scan Parameters Service与HID ISO Service)

六、安全要求，合规认证的核心红线

七、开发实战高频踩坑点避坑总结

八、检验

很多人第一反应是去改上报逻辑、调连接参数，甚至换芯片，可折腾了半天，问题依旧。其实这类问题90%都不是代码逻辑的问题，而是没吃透HOGP规范里对HID Device端的强制要求。HID Device作为整个HOGP体系的服务提供方，它的每一个服务、每一个特征值、每一条广播参数，甚至安全级别，都有严格的规范约束，差一点都不行。

这篇文章就把HID Device端的所有强制要求、边界规则、隐藏坑点全部拆解清楚，从必选服务基线、核心服务实现细节，到安全合规要求、重连行为配置，再到高频踩坑点的避坑方案，全部讲透，看完就能直接落地到开发和调试中，少走半年弯路。

一、先搞懂HID Device的服务基线，必选、可选、条件必选分清楚

就像开一家合规的餐厅，必须有营业执照、固定经营场所、后厨、前台这些基础配置，少一样都没法开门营业。HID Device要想被主机正常识别、稳定工作，首先要搭好合规的服务框架，规范对服务的必选性做了铁一般的定义，没有任何妥协空间。

HID Device的服务分为三类：强制必选、可选支持、条件必选，核心架构如下：

这里的每一项要求，都没有模糊空间。强制必选的三项服务，不管你做的是最简单的单按键遥控器，还是复杂的带触摸板、手写笔的复合键盘，都必须完整实现，少一个都不符合规范，主机有权直接拒绝识别你的设备。

可选的扫描参数服务，你可以根据设备的使用场景按需实现，它的核心作用是配合Report Host优化扫描和重连逻辑，降低设备功耗，提升重连速度。如果你的设备只需要支持BIOS下的Boot模式，完全可以不用实现这个服务，因为规范明确要求Boot Host不能支持对应的Scan Client角色，加了反而没用。

条件必选的HID ISO服务，是v1.1版本新增的低延迟能力的核心，如果你要做1ms高刷的游戏手柄、低延迟手写笔，需要用到LE等时通道传输HID报告，那这个服务就变成强制必选，必须完整实现；如果你的设备只是普通的办公键盘、遥控器，不需要高刷低延迟，那这个服务就可以直接排除，不用实现。

二、核心服务的强制实现细节，每一条都是合规底线

2.1 HID Service：整个设备的核心心脏，没有任何妥协空间

HID Service是整个HOGP体系的核心，所有的HID报告交互、模式控制、状态同步，都要通过这个服务完成，它的实现规则，直接决定了设备能不能被主机正常驱动。

首先是最基础的服务类型要求，规范明确要求：

All services with the <<HID Service>> UUID shall be instantiated as a <<Primary Service>>。

这句话看起来简单，却是新手开发者最高频的踩坑点。很多人刚接触BLE开发，分不清Primary Service和Secondary Service的区别，随手把HID Service做成了Secondary Service次服务，结果就是主机在做服务发现的时候，根本找不到你的HID Service，自然也就无法识别设备。记住，所有HID Service实例，必须是Primary Service主服务，没有任何例外。

然后是最容易出错的外部服务依赖规则，这是复合设备开发的重灾区。规范明确要求：

Any non-HID Service that has a characteristic whose value is described within the Report Map characteristic value shall be referenced as an <<Include>> within the HID Service definition containing that Report Map characteristic.

这句话怎么理解？举个例子，你做了一个带电量显示的蓝牙键盘，想把电池电量的状态做到HID报告里，在Report Map描述符里定义了电池电量对应的Usage Page和Usage。这时候，你存放电池电量的Battery Service，就必须用Include声明，包含到对应的HID Service定义里，同时，Battery Level特征值必须添加Report Reference特征描述符，告诉主机这个特征值对应的Report ID和Report Type。

很多人这里只改了Report Map，没加Include声明，也没加Report Reference描述符，结果就是主机解析Report Map的时候，找不到对应的特征值，直接解析失败，设备就算连上了，也完全没有反应。更严重的是，如果你有多个HID Service实例，绝对不能让两个HID Service同时Include同一个外部服务，否则会出现特征值引用冲突，主机直接拒绝通信。

接下来是广播数据的优化要求，虽然这部分是推荐实现，但直接决定了用户的第一体验。规范建议，设备在可发现模式下，广播数据里应该包含三个关键内容：HID Service的UUID、设备的Local Name本地名称、Appearance外观值。

HID Service UUID放在广播里，主机可以在扫描阶段就直接识别出这是一个HID设备，不用等连接后做服务发现，大大加快连接速度；Local Name能让用户在蓝牙列表里一眼认出自己的设备；Appearance值更是关键，它能告诉主机这个设备是键盘、鼠标、游戏手柄还是遥控器，主机会根据这个值显示对应的图标，而不是千篇一律的未知蓝牙设备。很多人做的设备，蓝牙列表里只显示一串MAC地址，就是没加Local Name；主机显示未知设备图标，就是没加Appearance值。

然后是HID Information特征值的行为要求，这里面有两个关键标志位，直接决定了设备的重连和唤醒体验，规范还专门用了独立附录详细定义了对应的行为，我们必须重点拆解。

第一个是NormallyConnectable标志位，这个标志位的配置，直接决定了设备在空闲状态下的广播行为，是影响重连体验的核心。规范专门在附录A里，详细定义了这个标志位两种配置对应的设备和主机行为，我们直接拆解成实战场景：

当NormallyConnectable设置为FALSE时，设备的行为是：只有当有按键按下、有数据需要上报的时候，才会开启高占空比广播，持续5秒；如果设备处于空闲状态，没有任何操作，会直接关闭射频，停止广播。对应的主机行为是，一直保持低占空比扫描，尽可能降低自身功耗。这种配置，最适合台式机配套的固定使用的键鼠，几乎不会和主机断开连接，空闲时关闭射频能最大化设备的续航，是最常用的省电配置。

当NormallyConnectable设置为TRUE时，设备的行为是：有数据需要上报时，开启高占空比广播5秒；就算设备处于完全空闲的状态，也会一直保持低占空比广播，随时等待主机的连接请求。对应的主机行为是，当主机从睡眠中唤醒、有数据需要发送时，会立刻开启高占空比扫描5秒，快速找到设备完成重连。这种配置，最适合笔记本、平板配套的移动使用的键鼠，笔记本睡眠时会断开蓝牙连接，唤醒后需要快速重连，这个配置能让设备在几百毫秒内完成重连，用户完全感知不到延迟，体验拉满。

很多人做的笔记本配套蓝牙键盘，唤醒后要等好几秒才能连上，甚至连不上，就是因为把NormallyConnectable设成了FALSE，设备空闲时直接关了射频，主机唤醒后扫描不到，自然没法重连。

第二个是RemoteWake标志位，这个标志位决定了设备能不能唤醒处于睡眠状态的主机。如果这个标志位设为FALSE，说明设备不支持远程唤醒，主机睡眠时会直接把这个设备排除在唤醒源之外；如果设为TRUE，说明设备支持远程唤醒，主机睡眠时会允许这个设备通过按键操作唤醒自己。做办公键鼠的开发者，一定要注意这个标志位的配置，很多用户反馈键盘没法唤醒电脑，就是这个标志位没设对。

最后是HID ISO功能对应的额外要求，如果你做的是高刷游戏手柄，支持HID ISO功能，并且用了多个HID Service实例，那必须保证：同一个设备里，所有相同Report Type的报告，Report ID必须全局唯一。比如，你有两个HID Service实例，第一个里面有Report ID 1的Input Report，第二个里面绝对不能再出现Report ID 1的Input Report，否则会出现报告冲突，ISO通道无法正常建立，主机直接拒绝进入混合模式。

三、Battery Service：必选的基础服务，别再只做报告里的电量了

很多开发者有一个误区：我已经在HID Report Map里加了电量报告，能上报电量了，就不用再加独立的Battery Service了。这是完全错误的，规范明确要求，HID Device必须有至少一个Battery Service实例，并且必须实例化为Primary Service，这是强制必选项，没有任何例外。

就算你已经在HID报告里实现了电量上报，也必须加一个独立的Battery Service，这是规范的底线，也是BQB认证的必查项。很多人的设备过不了认证，就是因为缺了这个必选服务。

同时，如果你在HID Report Map里描述了Battery Level特征值，那对应的Battery Service必须用Include声明，包含到HID Service里，和我们前面讲的外部服务依赖规则完全一致，不能有任何遗漏。

四、Device Information Service：必选的身份标识，PnP ID是重中之重

Device Information Service简称DIS，也是强制必选的服务，必须实例化为Primary Service。很多人觉得这个服务就是放个厂商名、产品名，可有可无，随便加几个特征值就行，结果踩了大坑。

规范明确要求：

The Device Information Service shall include the PnP ID characteristic for reading the PnP ID fields for the HID Device。

这句话是铁律，DIS里可以不加厂商名、产品名、固件版本号这些可选特征值，但PnP ID特征值是必须加的，没有任何商量的余地。

PnP ID里包含了厂商ID、产品ID、产品版本号，主机系统会用这个ID来加载对应的驱动程序，显示设备的专属图标，做设备的兼容性匹配。很多人做的设备，连上主机后显示未知HID设备，就是因为没加PnP ID，或者PnP ID里的厂商ID是随便填的。更严重的是，没有PnP ID，你的设备连BQB认证的入门门槛都达不到，直接会被驳回。

五、Scan Parameters Service与HID ISO Service

Scan Parameters Service是可选服务，只有当你的设备需要配合Report Host优化扫描和重连逻辑的时候才需要实现，Boot Host完全不支持这个服务，所以只做Boot模式的设备不用考虑。

HID ISO Service是条件必选服务，只要你的设备支持HID ISO低延迟功能，就必须完整实现这个服务，并且只能有一个实例，不能开多个。这个服务是控制混合模式切换、ISO通道配置的核心，里面的HID ISO Properties和LE HID Operation Mode两个特征值都是强制必选的，少一个都不行。

六、安全要求，合规认证的核心红线

很多开发者的设备，能连上主机，但是无法开启HID报告的通知，主机发了写CCCD的指令，设备也回复成功了，可就是没有数据上报，Windows系统甚至会直接断开连接。这种问题，90%都是因为安全要求没达标。

规范对HID Device的安全要求，做了非常明确的强制规定，没有任何妥协空间：

第一，HID Device必须处于GAP定义的可绑定模式，必须支持和主机完成绑定流程，不支持绑定的设备，直接不符合规范。

第二，HID Service的所有特征值，不管是读、写，还是通知、指示，都必须在加密的链路上才能执行。规范原文明确要求：HID Service characteristics shall require an encrypted link for reading, writing, and notification。这是强制要求，很多人把HID特征值的权限设成了无加密可读可写，结果就是主机系统出于安全考虑，直接拒绝开启通知，甚至拒绝和设备通信。Windows、macOS、iOS、Android这些主流系统，对HID设备的安全要求都和规范完全一致，没有加密的链路，根本不会处理HID报告数据。

第三，设备应该使用Peripheral Security Request流程，在连接建立后，主动向主机发送安全请求，告诉主机自己的安全要求，主机会根据这个请求，发起加密和绑定流程，保证链路的安全性。

第四，Battery Service、Device Information Service、Scan Parameters Service这些配套服务的安全级别，应该和HID Service保持完全一致，不能出现HID Service需要加密，而DIS服务不需要加密的情况，否则会导致主机的安全行为异常，出现连接不稳定、频繁断连的问题。

七、开发实战高频踩坑点避坑总结

讲完了所有的强制要求，我们再总结一下开发中最常见的踩坑点，帮大家直接避开：

必选服务缺失：没加Battery Service或者DIS服务，主机不识别，认证失败。
HID Service类型错误：做成了Secondary Service，主机服务发现找不到。
DIS服务缺少PnP ID特征值：认证失败，主机显示未知设备。
外部服务引用错误：Report Map里引用了外部服务，没加Include声明和Report Reference描述符，主机解析Report Map失败。
多HID Service实例Report ID重复：尤其是开ISO功能的时候，直接导致混合模式无法启用。
安全要求不达标：没开链路加密，主机无法开启通知，甚至拒绝连接。
**NormallyConnectable标志位配置错误：**设备休眠唤醒后重连慢，甚至连不上。

HOGP规范对HID Device端的所有要求，看似繁琐，实则核心逻辑非常清晰：必选项不能缺，规则项不能破，安全项不能松。所有的规则，最终都是为了两个核心目标：一是保证全球所有厂商的HID设备，都能和不同系统的主机无缝兼容、即插即用；二是在保证兼容性的前提下，最大化设备的稳定性，降低功耗，提升用户体验。

对于开发者来说，吃透这些强制要求，就相当于拿到了BLE HID设备开发的合规通行证，不仅能让你的设备在所有主流系统上稳定运行，还能轻松通过BQB认证，少走无数弯路。

八、检验

**题目：**HOGP规范中，HID Device端的强制必选服务有哪些？每个服务的核心强制要求是什么？

答案：

HOGP规范中，HID Device端的强制必选服务有三个，分别是HID Service、Battery Service、Device Information Service（DIS），核心强制要求如下：

HID Service：必须实例化为Primary Service主服务，不可为次服务；若Report Map中引用了外部服务的特征值，必须通过Include声明引用该外部服务，且对应特征值必须添加Report Reference描述符；所有特征值的读、写、通知操作必须在加密链路上执行；多实例场景下，禁止重复引用同一个外部服务。
Battery Service：必须至少有1个实例，且必须实例化为Primary Service；若Battery Level特征值被写入Report Map中，对应的Battery Service必须通过Include声明包含到HID Service中；安全级别需与HID Service保持一致。
Device Information Service：必须实例化为Primary Service；必须包含PnP ID特征值，不可缺失；安全级别需与HID Service保持一致。

**题目：**HOGP规范中，HID Service对外部服务的引用有哪些强制规则？违反规则会导致什么问题？

答案：

强制规则如下：

若非HID Service的某个特征值，其数值被定义在HID Service的Report Map描述符中，该外部服务必须通过Include声明，被包含到对应的HID Service定义中。
被引用的外部服务特征值，必须添加Report Reference特征描述符，明确其对应的Report ID与Report Type。
同一个外部服务，禁止被多个HID Service实例同时Include引用，避免特征值引用冲突。
仅支持在Report Map中描述，具备对应Report类型强制属性的特征值。

违反规则会导致的问题：

主机解析Report Map描述符失败，设备连接后无任何响应，无法正常上报HID数据。
多HID Service实例场景下出现报告ID冲突，主机无法区分不同的HID报告，导致功能异常。
设备不符合规范要求，BQB认证直接驳回，无法通过合规认证。
部分主机系统会直接拒绝识别设备，或出现频繁断连的问题。

**题目：**HOGP规范中，HID Device端的安全强制要求有哪些？为什么Windows主机经常无法开启HID设备的通知？

答案：

HID Device端的安全强制要求如下：

设备必须处于GAP定义的可绑定模式，必须支持与主机完成完整的绑定流程。
HID Service的所有特征值，其读、写、通知、指示操作，必须在加密的BLE链路上执行，无加密链路禁止执行相关操作。
设备应通过Peripheral Security Request流程，主动向主机告知自身的安全要求，触发主机发起加密与绑定流程。
配套的Battery Service、Device Information Service、Scan Parameters Service的安全模式与安全级别，应与HID Service保持一致。

Windows主机无法开启HID设备通知的核心原因，绝大多数是安全要求不达标：

Windows系统严格遵循HOGP规范的安全要求，对于HID Service的特征值，仅允许在加密绑定的链路上开启CCCD通知。如果设备未开启链路加密要求，或HID特征值的权限配置为无加密可访问，Windows会出于安全策略，拒绝执行CCCD写操作，或写操作成功后也不处理上报的通知数据，最终表现为无法开启通知、无数据上报。此外，设备未处于可绑定模式，无法与Windows完成绑定流程，也会导致同样的问题。