Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Écrire la clé de compte de manière rétroactive
Si un demandeur effectue une association de manière traditionnelle (par exemple, via les paramètres Bluetooth) au lieu de passer par le point d'entrée Association express, aucune clé de compte ne sera écrite dans le fournisseur. Dans ce cas, l'utilisateur ne pourra pas voir ni utiliser les fonctionnalités Association express, même s'il possède un appareil compatible. Pour que les utilisateurs puissent bénéficier de Fast Pair, le Fournisseur doit autoriser l'écriture silencieuse de la clé de compte par le demandeur juste après l'association.
- Si le fournisseur est associé sans passer par le flux Fast Pair, autorisez l'écriture d'une nouvelle clé de compte via la méthode d'association basée sur une clé pendant une minute maximum. N'acceptez qu'une seule clé de compte à écrire pendant cette période.
- Une fois le canal RFCOMM établi, le fournisseur doit envoyer l'ID du modèle et l'adresse BLE au demandeur via Message Stream. Le demandeur établira une connexion GATT et lancera la procédure d'association basée sur une clé.
- Si un Raw Request avec le bit 3 des indicateurs défini est reçu, le fournisseur doit vérifier que l'adresse BR/EDR de l'appareil associé est la même que celle incluse dans la requête. Si ce n'est pas le cas, refusez la demande.
- Étant donné que les appareils sont déjà associés, l'association BR/EDR et la validation de la clé d'accès (étapes 8 à 17 de la procédure) seront ignorées. Le demandeur écrira directement une clé de compte au fournisseur après l'établissement d'un secret partagé.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/13 (UTC).
[null,null,["Dernière mise à jour le 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."]]