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 11+.
  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).
  10. Support Hearable Controls to provide better access controls for important Hearable features.

Feature Requirements

Based on the device type , the requirement for feature support would differ. See the Device Feature Requirements for more details.

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.