使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
追溯写入账号密钥
如果 Seeker 通过传统方式(例如,通过蓝牙设置)而非通过快速配对入口点执行配对,则不会将账号密钥写入 Provider。在这种情况下,即使用户拥有支持快速配对的设备,也无法看到或使用任何快速配对功能。为了让用户能够享受快速配对带来的好处,提供方应允许搜寻方在配对完成后立即静默写入账号密钥。
- 如果提供方在未通过快速配对流程的情况下完成绑定,则允许通过基于密钥的配对方法写入新账号密钥,时间最长为一分钟。在此期间,仅接受写入一个账号密钥。
- 建立 RFCOMM 通道后,提供方应通过消息流将型号 ID 和 BLE 地址发送给搜索方,搜索方将建立 GATT 连接并启动基于密钥的配对程序。
- 如果收到设置了标志位 3 的 Raw Request,提供程序应验证已配对设备的 BR/EDR 地址是否与请求中包含的地址相同。否则,拒绝该请求。
- 由于设备已配对,因此将跳过 BR/EDR 配对和通行密钥验证(流程中的步骤 8-17),并且在建立共享密钥后,Seeker 将直接向 Provider 写入账号密钥。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-08-13。
[null,null,["最后更新时间 (UTC):2025-08-13。"],[[["\u003cp\u003eIf a Fast Pair device is paired traditionally (e.g., via Bluetooth settings), it won't have Fast Pair features until an account key is written.\u003c/p\u003e\n"],["\u003cp\u003eProviders should allow Seekers to write an account key for up to a minute after traditional pairing using Key-based Pairing.\u003c/p\u003e\n"],["\u003cp\u003eThis process involves the Provider sending its Model ID and BLE address, the Seeker establishing a GATT connection, and initiating Key-based Pairing.\u003c/p\u003e\n"],["\u003cp\u003eFor security, the Provider verifies the bonded device's address before accepting the account key write request.\u003c/p\u003e\n"],["\u003cp\u003eSince devices are already bonded, the process skips some steps and the Seeker directly writes the account key after a shared secret is established.\u003c/p\u003e\n"]]],[],null,["Retroactively Writing Account Key\n---------------------------------\n\nIf a Seeker performs a pairing through the traditional way (for example, through\nBluetooth settings) instead of through the Fast Pair entrypoint, there will be\nno account key written into the Provider. In this case, the user will not be\nable to see or use any of the Fast Pair features, despite owning a Fast Pair\ndevice. To let users be able to get the benefits of Fast Pair, the Provider\nshall allow the Seeker silently writing account key right after pairing has\noccurred.\n\n1. If the Provider is bonded without going through the Fast Pair flow, allow a new account key to be written through the Key-based Pairing method for up to one minute. Only accept one account key to be written during this time.\n2. After the RFCOMM channel is established, the Provider should send the Model ID and BLE address to the Seeker via [Message Stream](/nearby/fast-pair/specifications/extensions/messagestream#MessageStream \"Message Stream\"), the Seeker will build GATT connection and start [Key-based Pairing procedure](/nearby/fast-pair/specifications/service/gatt#procedure \"GATT Procedure\").\n3. If an [Raw Request](/nearby/fast-pair/specifications/characteristics#table1.2.1 \"Table 1.2.1 Raw Request\") with Flags bit 3 set is received, the Provider should verify the bonded device's BR/EDR address is the same as what is included in the request. If not, reject the request.\n4. Because the devices are already bonded, BR/EDR bonding and Passkey verification (steps 8 - 17 in the [procedure](/nearby/fast-pair/specifications/service/gatt#procedure \"GATT Procedure\")) will be skipped and the Seeker will directly write an [account key](/nearby/fast-pair/specifications/characteristics#AccountKey \"Account Key\") to the Provider after a shared secret is established."]]