Introduction
Google Fast Pair Service (GFPS) 利用BLE来发现附近的设备，从而不需要大量消耗手机电量，开启基于设备距离的“魔幻”场景。GFPS一开始是用来辅助audio sink设备的首次配对，比如扬声器，耳机和车载，尽可能的减少用户的交互操作。随后的配对和重连就会容易很多。
Profile dependencies
GFPS需要至少有A2DP或者HFP服务，能兼容蓝牙4.2及以后。
Octet order
当出现多字节字段时，遵从大端序，即网络字节序。
需要注意的是这个是网络传输的标准，与蓝牙协议规定的字节序不一致（比如，广播的服务UUID就是小端序的）。
Configuration
Roles
GFPS定义了两种角色：Fast Pair Seeker和Fast Pair Provider。seeker通常是手机，寻找需要配对的音频设备。provider通常是音频设备，广播它的存在并准备配对（比如处于可被发现可配对状态的耳机）。
Fast Pair Seeker通常做GAP Central role，Fast Pair Provider通常做GAP Peripheral role。除此之外，provider还需有一个相关的蓝牙服务比如A2DP或者HFP。
Seeker和Provider都必须支持经典蓝牙的绑定过程。
Device discovery
为了促进设备的发现，provider需要广播一个显示它支持GFPS的数据包（具体格式下面会说）。seeker需要周期性扫描和观察是否有支持GFPS的广播包，然后采取行动。
Fast Pair Provider
Model Registration
所有的provider型号在提供GFPS服务前都需要在google注册。注册后，google会分配一个Model ID和反欺骗的Public/Private Key Pair。注册中提供的这些信息在pair过程中会提供给用户用以别的体验。
对于注册的信息，获取
Model ID和密钥，可以参考文档Nearby Devices。
Transmit power
provider应该以低功率广播来限制设备的曝光范围，但是，功率至少要保证1米内的手机能收到广播包。
seeker需要知道provider的发送功率来判断距离。因此，TxPower以零米接收到的信号强度来定义，单位是dBm。
Note: 最好的方法是测量一米外的安卓手机的实际输出，再加41dBm.41dBm是1米内信号衰减的平均值。
测量的功率值需要通过下面两种方法之一传输：
- 包含在广播包中
- 注册的时候提供 --- 这要求设备在实际运行中的传输功率维持不变且与注册时的相同，才能保证距离测量的准确性。
Keys
Anti-Spoofing Public/Private Key Pair
在设备注册的时候，google除了提供Model ID，还会分配一个256-bit的私钥。这个私钥会一直存储在provider设备的安全模块内。这个安全模块非常重要，没有它，就不能保证provider不被欺骗，因为私钥有可能会被泄露。私钥的泄露会带来中间人攻击的可能。因此，一旦检测到伪装或滥用，使用这个私钥的Fast Pair功能会被禁用。（比如处于配对模式的provider的“Tap to Pair"提醒）。
相关的公钥暂时不被provider使用。是seeker用的，用来加密发送给provider的消息。
Account Key List
provider需要分配空间来存储一个128-bit的账户密钥表，每个账户密钥让provider能够被一个用户账户识别。
这个表需要至少存储5个密钥（也就是说至少要80-bytes），provider可以选择性的是否存储更多的密钥，只是需要保证密钥与广播包匹配。具体的存储数字是根据广播包还有多少剩余字节来决定的。可以看Account Key Filter部分来确定每个密钥需要多少字节。比如广播10个账户密钥，需要有15个字节的富余。
Advertising: When discoverable
当provider是BR/EDR可发现时（即处于可配对模式），它会通过BLE广播Fast Pair Model ID数据。
Advertising interval
两次广播之间的间隔不能大于100ms(10Hz)，来让seeker即使处于低功率扫描时仍然能够快速的找到provider。
BLE address
为了防止被追踪，BLE广播需要使用随机的resolvable private address(RPA)。当设备一直在广播时，这个地址需要至少15分钟循环一次，或者在广播态与非广播态之间切换时也需要更换地址。地址的随机间隔需要加一个随机的offset。
Advertising payload: Fast Pair Model ID Data
广播包必须包含服务数据类型，Fast Pair Serivce的UUID是0xFE2C，服务数据格式如下：
Model ID
每个provider model都有一个24-bit的model ID，由google在注册的时候提供。
Advertising: When not discoverable
当provider处于不可发现的模式时，即不在pairing mode，那么它会广播Fast Pair Account Data:
广播Account Data可以让附件的seekers识别出一个属于他们account的provider 可以开始配对，而不需要强制provider退回到pairing mode，通常退回到pairing mode是需要用户操作的，也是用户抱怨最多的地方。当seekers不在等待配对的时候，或者这个广播包与他们不相关时（如已经配对过了），他们通常让用户可以选择无视这个广播。seeker也会过滤掉明显不对的广播，如account data是没有配置过的。
Advertising interval
广播间隔最多250ms (4Hz)
BLE address
为了防止被追踪，BLE广播需要使用随机的resolvable private address(RPA)。当设备一直在广播时，这个地址需要至少15分钟循环一次，或者在广播态与非广播态之间切换时也需要更换地址。地址的随机间隔需要加一个随机的offset。
Advertising payload: Fast Pair Account Data
广播包必须包含服务数据类型，Fast Pair Serivce的UUID是0xFE2C，服务数据格式如下：
Account Key Data 包括：
Account Key Filter
广播的Account Key Filter让seeker在准备连接之前可以快速的检查provider是否拥有确定的account key（假阳性低，少于0.5%）。seeker也可以先自动连接上，然后在收到可能包含它的account keys的filter以后开始检查，来降低未来的假阳性。
Rotation
为了减少通过监控Account Key Filter来追踪设备的情况，Account Key Filter需要在设备广播态的时候每15分钟利用新的salt重新生成一个。但是需要注意的是，当这个设备已经建立连接了，那么连接的一端的公共地址就会在channel access code里广播，所以隐私保护也有限。