Connect your Android users with a tap: Fast Pair

Isai Damier
Jul 16 · 6 min read

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

Privacy and BLE

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

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.


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 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.


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

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

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.


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.


Android Developers

The official Android Developers publication on Medium