Retroactively Writing Account Key
If a Seeker performs a pairing through the traditional way (for example, through Bluetooth settings) instead of through the Fast Pair entrypoint, there will be no account key written into the Provider. In this case, the user will not be able to see or use any of the Fast Pair features, despite owning a Fast Pair device. To let users be able to get the benefits of Fast Pair, the Provider shall allow the Seeker silently writing account key right after pairing has occurred.
- 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.
- After the RFCOMM channel is established, the Provider should send the Model ID and BLE address to the Seeker via Message Stream, the Seeker will build GATT connection and start Key-based Pairing procedure.
- If an 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.
- Because the devices are already bonded, BR/EDR bonding and Passkey verification (steps 8 - 17 in the procedure) will be skipped and the Seeker will directly write an account key to the Provider after a shared secret is established.