gfps/GFPS+FAQ.md

GFPS FAQ

(The following questions and answers are extracted from the discussion with Google team)

**1.      ** How do I register the mode id and get the Anti-Spoofing Public/Private Key Pair? Is it necessary to register once for each headset registration (exclusive mode id) or a batch of product registration (shared mode id)?

A batch of products registered once.

**2.      ** If our headphones use this feature, do we need google authentication?

Need to give Google a headset for testing.

**3.      ** In pairing mode provider using discoverable advertising, and not in pairing mode provider using not discoverable advertising. But how the fast pair provider decide which mode it is?

Fast pair provider is in headset side. So it should be able to know headset status to see if headset is in pairing mode or not. For example, the user can force headset in pairing mode like long press some button. After headset is connected, then it is not in pairing mode.

In short, in pair mode, we advertise BLE with model ID. When headset is not discoverable, we advertise BLE with account key list.

**4.      ** What’s the difference between these two modes in fast pair procedure?

One key feature of Fast Pair 2.0 is when you have paired the headset to a phone, other phones or devices with the same account will know and are able to pair the headset via fast pair notification directly.

So in pairing mode, if a phone pairs with the headset via fast pair notification, the account info will bring back to headset in account key list. So when headset not in pairing mode, the headset will broadcast BLE advertisement with account key list and nearby devices will be aware of.

**5.      ** One scenario, if headset want to pair with android device, it should enter the pairing mode, advertise mode ID (trigger by user, such as press some button of headset). Android device show a high priority notification, user should click this notification to complete the fast pair procedure. Also another scenario, once provider broadcast BLE advertisement with account key filter, android device with the same account aware that there is a previously paired headset nearby, so android device with pair the headset directly, user need to do nothing, is that right?

For second scenario, a fast pair notification will appear with wordings like "Your paired device is available..." in description. And the user still has to tap the fast pair notification to complete pairing.

**6.      ** In both pairing modes user should tap fast pair notification to complete pairing. Spec D11 provides that both discoverable advertising and not discoverable advertising are using random resolvable private address (RPA). It seems that pairing mode and not in pairing mode have no difference? Both modes using RPA to prevent tracking, in both modes user need to tap notification to complete pairing.

To sum up, it is necessary to send the discoverable advertising to start pair procedure with android device unpaired before. If android device has paired before, to start pair procedure, provider can send either discoverable advertising or not discoverable advertising.

There is a situation where not discoverable advertising is used. The headset is paired with a device and remains connected. At this time, provider send not discoverable advertising, if the device login the same google account close, the device will receive the pairing prompt. That is, one headset can be paired with multiple devices at the same time.

**7.      ** Android device must be logged in to google account to use this fast pair feature?

Currently the answer is yes since you need to be whitelisted to get to see the notifications. After Fast Pair goes public in about a month, the requirement is that the user gets the relevant Play Services update, which should happen for pretty much all Android 6.0+ users across the world (with the exception of Chinese devices that don't have Play).

**8.      ** Is the provider must support the Numeric Comparison pairing method of LE? BR/EDR also support method of Numeric Comparison?

The provider should support numeric comparison through either method, although our code should be sending the request over BR/EDR.

**9.      ** Does it means if LE Secure connection is mandatory for provider if it need to support Google fast pairing?

Correct, in the future it is possible that we could attempt an LE connection first instead of BR/EDR so support for that should be included if at all possible. 

**10.  ** Make sure that in pairing mode use resolvable private address.

We want to use a rotating private address for privacy reasons, this helps to prevent headphones from being tracked throughout the day.

**11.  ** Is it mandatory or just strongly recommend provider to follow it. Because customers may use other BLE random address type (such as static random address) to implement some other features.

It is not a hard requirement, we only really care that the address returned as part of step 5 in the spec (although some partners were running into issues if they advertise with the same address as their public address, so I would still recommend using a different address, even if it is static, if you run into problems there).

**12.  ** In step 5, what does it mean become discoverable for 10 seconds but shall not advertise Fast Pair Model ID, and what’s the reaction on seeker’s side.

Here we want the headphones to become discoverable (IE, what would normally happen if the user holds the pairing button or something like that, depending on the headset), but not advertise the model ID so that we don't show a notification for it on other phones in the area. From the seekers side, we have to scan for it to work around a bug on older Android versions where we're not able to pair until we've actually discovered the device first. This flag will only be set for Android devices on 7.0 or lower where the bug exists.

**13.  ** “headphones to become discoverable” means headphone advertise like the pairing mode advertising, the same Advertising interval and BLE address, but the payload only include service UUID, no model ID. And we can test this scenario in Android devices on 7.0 or lower, correct?

Correct, everything should stay the same as pairing mode except the model ID shouldn't be advertised so that other devices in the area won't display a notification and try and steal the connection. You can test with any device that is Android 7.0 or lower, that's right. We're actually experimenting with removing this step to see if the connection can still succeed (there was an old bug on Android devices that this originally worked around), however it is in place right now so if you're testing with a 7.0 or below device then it won't work unless this is in place.

**14.  ** In step 8/9/10, request’s flags byte has bit 1 set to 1 means provider shall send pairing request to seeker on BR/EDR, right?  I have never encountered this situation. Request’s flags byte has bit 1 set to 0 means seeker will send pairing request to provider via BR/EDR or BLE, and in which situation via BR/EDR, which situation via BLE? Rules of step 10 shall be follow on Pairing via BR/EDR and BLE, right?

The provider bonding with the seeker is a bit of a different situation that isn't very common, but helps to work around a security issue that was brought up by some of our reviewers. It isn't a likely case though and this flag is off right now, so you won't see it happen in testing and I'm not sure that we'll ever turn it on.

**15.  ** If some days later you turn it on, please let us know, we want to verify it to make sure the code flow is correct.

Yes we'll absolutely let you know if this change is made, but like I said I don't think it will be so not too much to worry about for now.

**16.  ** Passkey Block salt means the last 12 bytes of Raw Passkey Block, right?

Yes, the salt is whatever is needed to fill up the packet to 16 bytes.

**17.  ** It is Raw Passkey Block, not Raw Response. From table 2.2 Octet 4-15 is reserved, it is not the salt. Would you please check it again?

This is a bit unclear in the spec, I'll update it to include more details. Step 15 discusses filling this packet and mentions a salt, but the table itself does not mention a salt. The salt should be bytes 4-15, you can generate any random value and put it there to complete the packet.

**18.  ** If the optional Public Key field is present: if the device is not in pairing mode, ignore the write and exit. The “exit” means provider to disconnect the BLE link, or keep BLE connecting and don’t perform the pairing process?

Provider can disconnect the link at this point if an invalid request comes in, this will stop the seeker from continuing.

**19.  ** In table 1.2, Raw Request octet 2-7 maybe provider’s current BLE address or provider’s public address. Provider’s current BLE address means the resolvable private address used in advertising, and provider’s public address means the BR/EDR public address, right? In what circumstances Raw Request contain current BLE address or public address?

Those are both correct. Android will automatically resolve the BLE address into the BR/EDR address in some cases if the two devices have connected previously, meaning there isn't a way for us to know whether we're sending the provider its BLE address or BR/EDR address, so that is why this provision needed to be included.

**20.  ** After pairing, the Fast Pair Seeker may write an Account Key to the Fast Pair Provider. So, sometimes seeker may not send account key to provider, in what circumstances seeker will distribute account key and what circumstances won’t?

We'll always write the account key as long as the GATT connection is maintained (and we'll try and recreate it if it isn't maintained). I'll reword this so that it is clearer. 

**21.  ** If no key could successfully decrypt the value, ignore the write and exit. a. Keep a count of these failures. When the failure count hits 10, fail all new requests immediately. Reset the failure count after 5 minutes, after power on, or after a success. Does the “fail all new requests immediately” means provider disconnect the link?

If provider didn’t analysis request successful, no need to response, seeker will retry write request, after retry 3 times and get no response, seeker will disconnect the link. Provider only need to disconnect the link once calculate failure times up to 10.

**22.  ** If the decrypted request’s Flags bit requesting discoverability is set to 1, become discoverable for 10 seconds, or until this pairing process completes, whichever comes first. I am not sure about this process. Can you analyze it?

Broadcast for 10 seconds or broadcast until the pairing process complete (the pairing process may be completed in 3s), clarifying that this is for work around an android bug.

**23.  ** When confirmation of the passkey is needed, wait up to 10 seconds for a write to the Passkey characteristic. If provider doesn’t receive passkey in 10 seconds, what shall provider do?

Try to disconnect the link if provider doesn’t receive passkey in 10 seconds.

 

相关jira：  BUMBEERD-667 - [BBPro] [Upperstack][BLE]Google Fast Pairing Service Resolved