消息流作用

Google fast pair service要求Provider提供一个额外得通道以便seeker寻求建立连接，连接建立后，Seeker就可以向Provider发送一串数据流，这样做的目的是为了支持GFPS Extension，也就是扩展的GFPS，主要涉及一些比如耳机的电量，状态，音频切换，名字定制化等等。

消息流支持方式

Fast Pair支持两种消息流方式：

1. 基于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连接上发送消息流了。
2. 基于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额外数据	否