透過集合功能整理內容
你可以依據偏好儲存及分類內容。
追溯寫入帳戶金鑰
如果 Seeker 是透過傳統方式 (例如透過藍牙設定) 配對,而不是透過快速配對進入點,系統就不會將帳戶金鑰寫入 Provider。在這種情況下,即使使用者擁有支援快速配對的裝置,也無法查看或使用任何快速配對功能。為讓使用者享有快速配對的優點,供應商應允許搜尋器在配對完成後,立即以無聲模式寫入帳戶金鑰。
- 如果供應商未透過快速配對流程完成繫結,請允許透過以金鑰為準的配對方法寫入新帳戶金鑰,時間最多一分鐘。在這段期間,只接受寫入一個帳戶金鑰。
- 建立 RFCOMM 通道後,供應商應透過訊息串流將模型 ID 和 BLE 位址傳送給搜尋者,搜尋者會建立 GATT 連線並啟動以金鑰為準的配對程序。
- 如果收到 Flags 位元 3 設為 1 的 Raw Request,Provider 應驗證已配對裝置的 BR/EDR 位址是否與要求中包含的位址相同。如果不是,請拒絕要求。
- 由於裝置已完成繫結,因此會略過 BR/EDR 繫結和密碼金鑰驗證 (程序中的步驟 8 至 17),並在建立共用密碼後,由 Seeker 直接將帳戶金鑰寫入 Provider。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-08-13 (世界標準時間)。
[null,null,["上次更新時間: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."]]