コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
アカウント キーの事後書き込み
シーカーがファスト ペアリング エントリ ポイントではなく、従来の方法(Bluetooth 設定など)でペア設定を行った場合、プロバイダにアカウント キーは書き込まれません。この場合、ユーザーはファスト ペアリング対応デバイスを所有していても、ファスト ペアリングの機能を利用できません。ユーザーが Fast Pair のメリットを享受できるように、プロバイダはペア設定の直後にシーカーがアカウントキーをサイレントに書き込むことを許可しなければなりません。
- プロバイダがファスト ペアリング フローを経ずにバインドされた場合、キーベースのペア設定メソッドで最大 1 分間、新しいアカウント キーの書き込みを許可します。この期間中に書き込まれるアカウント キーは 1 つのみを受け入れます。
- RFCOMM チャネルが確立された後、プロバイダは メッセージ ストリームを介してモデル ID と BLE アドレスをシーカーに送信し、シーカーは GATT 接続を構築してキーベースのペア設定手順を開始します。
- フラグビット 3 が設定された Raw Request を受信した場合、プロバイダは、ペア設定されたデバイスの BR/EDR アドレスがリクエストに含まれているものと同じであることを確認する必要があります。満たしていない場合は、リクエストを拒否します。
- デバイスはすでにバインドされているため、BR/EDR バインディングとパスキーの確認(手順のステップ 8 ~ 17)はスキップされ、シークは共有シークレットが確立された後、プロバイダに直接アカウント キーを書き込みます。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-08-13 UTC。
[null,null,["最終更新日 2025-08-13 UTC。"],[[["\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."]]