Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Wsteczne zapisywanie klucza konta
Jeśli użytkownik sparuje urządzenie w tradycyjny sposób (np. w ustawieniach Bluetooth) zamiast przez punkt wejścia Szybkiego parowania, klucz konta nie zostanie zapisany na urządzeniu dostawcy. W takim przypadku użytkownik nie będzie mógł zobaczyć ani używać żadnych funkcji Szybkiego parowania, mimo że ma urządzenie obsługujące tę technologię. Aby użytkownicy mogli korzystać z zalet Szybkiego parowania, dostawca musi zezwolić urządzeniu wyszukującemu na ciche zapisanie klucza konta bezpośrednio po sparowaniu.
- Jeśli dostawca jest powiązany bez przechodzenia przez proces szybkiego parowania, zezwól na zapisanie nowego klucza konta za pomocą metody parowania opartej na kluczu przez maksymalnie minutę. W tym czasie akceptuj tylko jeden klucz konta do zapisu.
- Po utworzeniu kanału RFCOMM dostawca powinien wysłać do wyszukującego identyfikator modelu i adres BLE za pomocą strumienia wiadomości. Wyszukujący utworzy połączenie GATT i rozpocznie procedurę parowania na podstawie klucza.
- Jeśli zostanie odebrane surowe żądanie z ustawionym bitem 3 flagi, dostawca powinien sprawdzić, czy adres BR/EDR sparowanego urządzenia jest taki sam jak adres zawarty w żądaniu. Jeśli nie, odrzuć prośbę.
- Ponieważ urządzenia są już powiązane, pominięte zostaną powiązanie BR/EDR i weryfikacja hasła (kroki 8–17 w procedurze), a wyszukiwarka bezpośrednio zapisze klucz konta na urządzeniu dostawcy po ustaleniu wspólnego klucza tajnego.
O ile nie stwierdzono inaczej, treść tej strony jest objęta licencją Creative Commons – uznanie autorstwa 4.0, a fragmenty kodu są dostępne na licencji Apache 2.0. Szczegółowe informacje na ten temat zawierają zasady dotyczące witryny Google Developers. Java jest zastrzeżonym znakiem towarowym firmy Oracle i jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-08-13 UTC.
[null,null,["Ostatnia aktualizacja: 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."]]
