Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Scrittura retroattiva della chiave dell'account
Se un utente esegue l'accoppiamento in modo tradizionale (ad esempio tramite le impostazioni Bluetooth) anziché tramite il punto di accesso all'accoppiamento rapido, non verrà scritta alcuna chiave dell'account nel fornitore. In questo caso, l'utente non potrà
vedere o utilizzare nessuna delle funzionalità di Accoppiamento rapido, nonostante possieda un dispositivo
con questa funzionalità. Per consentire agli utenti di usufruire dei vantaggi di Fast Pair, il fornitore
deve consentire al richiedente di scrivere silenziosamente la chiave dell'account subito dopo l'accoppiamento.
- Se il fornitore è associato senza passare attraverso il flusso Fast Pair, consenti la scrittura di una
nuova chiave dell'account tramite il metodo di accoppiamento basato su chiave per un massimo di
un minuto. Accetta una sola chiave dell'account da scrivere durante questo periodo.
- Una volta stabilito il canale RFCOMM, il fornitore deve inviare l'ID modello e l'indirizzo BLE al richiedente tramite Message Stream. Il richiedente creerà la connessione GATT e avvierà la procedura di accoppiamento basata su chiave.
- Se viene ricevuta una Raw Request con il bit 3 dei flag impostato, il fornitore
deve verificare che l'indirizzo BR/EDR del dispositivo accoppiato sia lo stesso
incluso nella richiesta. In caso contrario, rifiuta la richiesta.
- Poiché i dispositivi sono già accoppiati, l'accoppiamento BR/EDR e la verifica della passkey (passaggi 8-17 della procedura) verranno ignorati
e il richiedente scriverà direttamente una chiave dell'account al
fornitore dopo aver stabilito un segreto condiviso.
Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.
Ultimo aggiornamento 2025-08-13 UTC.
[null,null,["Ultimo aggiornamento 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."]]
