Google Fast Pair Service

Introduction

The Google Fast Pair Service (GFPS) utilizes Bluetooth Low Energy (BLE) to discover nearby Bluetooth devices without using significant phone battery, enabling “magical” scenarios based on device proximity.

Features

GFPS is aimed at facilitating the pairing of Bluetooth and BLE devices, such as speakers, headphones, car kits, mice and keyboards, with as little user interaction required as possible. By implementing the following spec, Google will continue to release additional features that build upon it. This includes:

  1. Displaying a half page notification when the device is in pairing mode to facilitate easy initial pairing. Additionally companion apps are easily marketed to users.
  2. Associating the device with the user's account after the initial pairing has completed.
  3. Displaying a subsequent pairing notification when the device is turned on and near another phone, tablet, or desktop that the user owns, so that the user does not need to know how to put the device back into pairing mode before pairing with their other devices.
  4. Associating a personalized name with the device.
  5. Battery notifications are displayed for the headphones.
  6. Shows device details in Android 10+.
  7. Ability for users to locate a lost headset or buds.
  8. Offline pairing is available for low-network situations.
  9. Support Audio switch to seamlessly transition headset connections between devices based on user activity (e.g. starting a movie) and prioritized events (e.g. an incoming call).

Feature Requirements

The following table describes which types of devices must implement specific features for a given specification version:

Spec version Feature Speaker Headset TWS Single Earbud
V2.0 Initial Pairing
Subsequent Pairing		 Yes
Yes		 Yes
Yes		 Yes
Yes		 Yes
Yes
V3.0
&
V3.1		 Battery Level Notification
Personalized Name
Ring the Device
Retroactive Account Key Writing
Yes
Yes
Yes		 Yes
Yes
Yes
Yes
V3.2 Audio switch

Profile dependencies

The GFPS implementation is compatible with the Bluetooth Core Specification v4.2 or later.

Octet order

Wherever a field consists of multiple bytes, the byte ordering is big-endian, that is, network byte order (most-significant octet to least-significant octet).

Note that while this is standard for bytes transferred over networks, it is different from the byte ordering for multi-byte fields in Bluetooth SIG specifications (for example, a service UUID in an advertisement is little-endian).

Reference Implementation

See Nearby embedded SDK library for the reference implementation.