Connect your Android users with a tap: Fast Pair (Part 3 of 3)

Isai Damier
Android Developers
Published in
6 min readJul 16, 2021

--

If you are a device manufacturer or a developer working on an app that accompanies a particular device (such as a wearable or IoT app), you can use the Fast Pair Service to reduce the amount of work that you and your end users have to do to pair your devices to an Android phone.

In fact, there is no coding to enable Fast Pairing, unless you want to handle pairing within your companion app as opposed to letting the API do it for you.

There only are three parts to the pairing process:

  1. Ensure your peripheral device follows all registration prerequisites.
  2. Register the device model with Google.
  3. When a user needs to pair, advertise your device to their phone (information collected in step 1 is displayed to the user as shown in Figure 1).

Figure 1: Fast Pair notification to connect

As soon as the user puts your peripheral device into pairing mode, their Android phone displays a bottom sheet dialog that shows your device’s name, a photo of it, and a single Connect button (also shown in Figure 1).

Your user needs only to click the button to pair the devices, after which they’ll enjoy a delightful and stress-free experience.

The Fast Pair Service also makes it possible for users to help locate misplaced devices using their phone, or even display the battery level for True Wireless Stereo (TWS) earbuds.

Finally, Fast Pair can prompt users to install any companion app for your device.

Registration Prerequisites

To ensure your device works properly with Fast Pair and provides an enhanced end-user experience, it should meet the following requirements:

Privacy and BLE

To protect the privacy of your users and prevent tracking, we require devices to use Bluetooth Low Energy (BLE) advertisement with random resolvable private addressing (RPA).

The address should change about every 15 minutes and every time an advertisement session begins. However, do not rotate the address during pairing mode; rotating can prevent connections from being established and maintained, since the connection drops when the address is no longer available.

Account Keys

Fast Pair uses Account Keys to represent distinct individual users of a peripheral device. An Account Key maps to a Gmail address.

Your peripheral device is required to store at least five Account Keys, so that multiple people can use the same device. For instance, a family with parents and teens may share a single car where each individual would use their own Gmail address as an Account Key.

As an added feature, a single individual that uses the same Gmail account on multiple Android phones or tablets is still considered a single Account Key by the Fast Pair Service. Hence, if ten different Android devices share a single Gmail account, your peripheral device won’t know the difference as far as Fast Pair is concerned — it’s just one user.

BLE GATT

Your device is required to support BLE GATT Profiles with Services and Characteristics.

Using Fast Pair requires you to define a service with a UUID of 0xFE2C and the following custom Characteristics:

  • Model ID
  • Key-based Pairing
  • Passkey
  • Account Key

These are in addition to the standard Characteristics and any custom Characteristics (optionally used for communication with an accompanying app).

If you do have a companion app and it’s installed on the central device, your custom data will be relayed to the app. Otherwise, the custom data will simply be ignored.

You may optionally have your app register a BroadcastReceiver for com.google.android.gms.nearby.fastpair.ACTION_LOG_BUFFER_FULL. This is optional because using this feature requires your peripheral device to notify the central device that the buffer is full — meaning that there is work required by both the peripheral firmware and the companion app to be able to do anything with the data.

Headphones

A common application of Fast Pair is for headphones, which require either A2DP or HFP to be supported. As long as the device supports one of these profiles, after bonding has finished Fast Pair attempts to connect to A2DP then to HFP, in that order.

For TWS buds, the following are required:

  • The advertising payload includes the battery level of your device.
  • Users can enter a custom name for the device.

While these aren’t required for other peripheral devices, Fast Pair supports them and they are highly recommended.

Devices with Companion App

Fast Pair has a more universal app launch flow that supports a variety of companion devices. In this flow, Fast Pair discovers only the closest device, checks for the device companion app (prompting users to install it if it isn’t already), and redirects users to the specified screens of the companion app. There’s no BT bonding involved in this flow.

FitBit uses this flow to simplify their device setup process. Another example of a device using this flow might be a smart scale or electric toothbrush using it to promote its companion app and simplify the out-of-box experience.

Figure 2: Companion app redirect

Two-way communication

Although advertising is a one-way communication, two-way communication becomes possible once your device has successfully connected to a central device such as an Android phone.

Fast Pair provides an RFCOMM channel for your peripheral device to maintain continuous communication with a central device. It’s perfectly fine to switch to classic Bluetooth for two-way communication once connection has been established.

Registration

You will need to register your device model with Google as a Fast Pair Provider.

A Fast Pair Provider is a peripheral device — such as a pair of headphones — that advertises it’s eligible for pairing.

On the opposite side, a Fast Pair Seeker is a central device — such as an Android phone or tablet — that looks for other devices to pair with. The Google Play Services framework handles that portion of the work with no action needed from partners, so that’s not covered here.

To register your peripheral device, you need only the following:

  • The name of the device
  • An image of the device
  • A measured value of the transmit power (TxPower) of the device

While the name and image of the device are straightforward, measuring the power takes a little more work. We recommend measuring the strength of the device’s beacon one meter away from an Android phone and then add 41dBm to that measurement (as described in more detail in an article on Eddystone-UID).

There are two options for submitting the TxPower: you can manually submit it during registration or your device can include it as part of the payload during device advertisement.

If you provide the device TxPower during registration, you are submitting that all units of that model are calibrated to that exact TxPower level. On the other hand, if you decide that your device will provide the TxPower level as part of the Advertisement Record, the TxPower level is treated on a per-unit basis.

Once registration is complete, we’ll provide you with a Model ID and a cryptographic public/private key pair. As with any asymmetric cryptographic system, it is strongly advised to store the private key in a Secure Element (SE) on the device so that adversaries cannot access it. (You can learn more about asymmetric keys in this article about improving your app’s cryptography.)

During advertisement, the payload (Advertisement Record) of your device should include the Model ID that you received from Google and the TxPower level of the unit, if it wasn’t provided during registration.

Summary

Fast Pair is a service that Google offers as part of Google Play Services to simplify the pairing process for Android users. In addition to making pairing convenient, Fast Pair offers many additional desirable features, including helping users locate misplaced devices and prompting them to install your device’s companion app. Although there are many prerequisites to ensure the best experience for your users, the registration process itself is a breeze because it only requires the device name and photo. Happy coding!

--

--

Isai Damier
Android Developers

Android Engineer @ Google; founded geekviewpoint.com; Haitian; enjoy classical lit and chess. Twitter: @isaidamier