GFPS扩展技术原理（一）消息流
消息流作用
Google fast pair service要求Provider提供一个额外得通道以便seeker寻求建立连接，连接建立后，Seeker就可以向Provider发送一串数据流，这样做的目的是为了支持GFPS Extension，也就是扩展的GFPS，主要涉及一些比如耳机的电量，状态，音频切换，名字定制化等等。
消息流支持方式
Fast Pair支持两种消息流方式：
- 基于RFCOMM连接方式：
RFCOMM Server（一般是部署在Provider上）需要提供UUID为df21fe2c-2515-4fdb-8886-f12c4d67927c 也就是UUID 0xFE2C的Channel,以便Seeker在做SDP查询时，能够找到。可以看下图所示的实例：
从上面的HCI LOG可以看到，Seeker会去做SDP查询，寻找基于UUID为0xFE2C的SDP服务， Provider会返回RFCOMM Server Channel 28,接下来Seeker就会在Channel 28上建立RFCOMM连接，后面就可以在此RFCOMM连接上发送消息流了。 - 基于BLE CoC方式：
Connection-oriented channel (CoC)也就是L2CAP面向连接通道，会有三种模式，基本L2CAP模式，重传模式以及基于流控模式。然而BLE CoC只支持QOS流控模式，比如基于Credit-based flow control。消息流基于BLE CoC方式，采用的是GATT PSM也就是动态PSM值（0x80-0xFF），参考如下实例：
如上图所示，我们会基于PSM:0x00A1建立一个LE L2CAP Connection，后面的消息流就可以通过这个LE L2CAP连接传送。
消息流数据格式
消息流采用如下数据格式：
| 字节序列 | 类型 | 详解 | 必须支持与否 |
|---|---|---|---|
| 0 | uint8 | Message group,消息组 | 是 |
| 1 | uint8 | Message code,消息代码 | 是 |
| 2-3 | uint16 | Additional data length,额外数据长度 | 是 |
| 4-n | n uint8 | Additional data额外数据 | 否 |
原文地址：https://blog.csdn.net/Jzj1234555/article/details/144394435
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！