在上一篇的内容里【LE Audio】PACS精讲[1]: 吃透基础规则，解锁音频能力发布核心逻辑，我们吃透了PACS的基础规则，从一致性要求、协议兼容、GATT交互约定到术语体系，搭建起了PACS的知识地基。而PACS的服务层，正是这些基础规则落地的核心载体，是蓝牙音频设备作为服务器对外发布自身音频能力的核心操作框架。如果说基础规则是PACS的“语法规范”，那服务层就是基于语法写出的核心篇章，定义了PACS服务该如何声明、哪些设备能部署、音频能力该如何发布与交互，甚至明确了多参数组合的硬性规则——这些内容也是实际开发中设备兼容、能力解析的核心考点，很多开发中的问题都源于对服务层规则的理解偏差。目录一、服务声明：PACS服务器的唯一身份准则1.1 实例唯一性：一个服务器只能有一个PACS服务1.2 UUID固定+推荐主服务：让客户端一眼找到PACS服务二、部署范围：哪些设备能搭载PACS服务？三、服务核心行为：三大能力发布逻辑，区分固有能力与实时状态3.1 音频能力：通过PAC记录发布，设备的固有硬件配置表3.2 音频可用性：通过Available Audio Contexts发布，设备的实时营业状态3.3 音频能力与可用性的核心区分：一个不变，一个实时变四、PAC记录核心规则：多参数组合的全兼容硬性要求4.1 多参数的两种表示形式：位域与范围4.2 全组合规则：不允许选择性支持4.3 离散值需求：拆分PAC记录，而非在一个记录中留空4.4 全组合规则的设计初衷：杜绝声明与实际不符五、通用约定：数组参数的标准排列规则六、服务行为的补充：通知机制的触发与执行七、测试本文聚焦PACS服务层的核心，从服务声明的唯一性准则，到设备的部署范围，再到PAC记录的多参数组合规则、音频能力与可用性的核心区分，把服务层的规则讲透，真正理解蓝牙音频设备是如何对外公示自己的音频能力的。一、服务声明：PACS服务器的唯一身份准则任何一个蓝牙GATT服务的实现，第一步都是明确服务声明规则，PACS也不例外。服务声明为PACS服务器定下了两个核心硬性规则，一个是实例唯一性，一个是UUID与服务类型规范，这两个规则是客户端能正常发现、识别PACS服务的前提，相当于给PACS这个音频能力公示牌定下了摆放规则。