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:
- 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.
- Associating the device with the user's account after the initial pairing has completed.
- 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.
- Associating a personalized name with the device.
- Battery notifications are displayed for the headphones.
- Shows device details in Android 10+.
- Ability for users to locate a lost headset or buds.
- Offline pairing is available for low-network situations.
- 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.