Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Kontoschlüssel nachträglich schreiben
Wenn ein Seeker die Kopplung auf herkömmliche Weise (z. B. über die Bluetooth-Einstellungen) anstatt über den Fast Pair-Einstiegspunkt durchführt, wird kein Kontoschlüssel in den Provider geschrieben. In diesem Fall kann der Nutzer keine der Funktionen von „Schnelles Pairing“ sehen oder verwenden, obwohl er ein Gerät besitzt, das „Schnelles Pairing“ unterstützt. Damit Nutzer die Vorteile von Fast Pair nutzen können, muss der Anbieter dem Seeker erlauben, den Kontoschlüssel direkt nach dem Pairing im Hintergrund zu schreiben.
- Wenn der Anbieter ohne den Fast Pair-Ablauf gebunden ist, kann bis zu einer Minute lang ein neuer Kontoschlüssel über die schlüsselbasierte Kopplungsmethode geschrieben werden. Akzeptieren Sie während dieser Zeit nur das Schreiben eines Kontoschlüssels.
- Nachdem der RFCOMM-Kanal eingerichtet wurde, sollte der Anbieter die Modell-ID und die BLE-Adresse über Message Stream an den Suchenden senden. Der Suchende stellt dann eine GATT-Verbindung her und startet die schlüsselbasierte Kopplung.
- Wenn eine Raw Request mit dem gesetzten Bit 3 für Flags empfangen wird, sollte der Anbieter prüfen, ob die BR/EDR-Adresse des gekoppelten Geräts mit der in der Anfrage enthaltenen Adresse übereinstimmt. Andernfalls lehnen Sie die Anfrage ab.
- Da die Geräte bereits gekoppelt sind, werden die BR/EDR-Kopplung und die Passkey-Bestätigung (Schritte 8 bis 17 im Ablauf) übersprungen. Der Seeker schreibt direkt einen Kontoschlüssel auf den Provider, nachdem ein gemeinsames Geheimnis eingerichtet wurde.
Sofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers. Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.
Zuletzt aktualisiert: 2025-08-13 (UTC).
[null,null,["Zuletzt aktualisiert: 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."]]
