> [!NOTE]
> **Note:** Google recommends using the [Validator App](https://play.google.com/apps/testing/com.google.location.nearby.apps.fastpair.validator "Link to the Validator App on the Google Play Store.") for self-testing to verify your implementation. The Validator App is a self-verification tool and does not replace official 3rd Party Lab certification.
Last updated: November 9, 2026
- The device under test ("DUT") must be a factory-clean device (i.e., the DUT cannot be a personal device or a device that contains any personal information).
- The test materials available here (e.g., processes, guidelines, and other information) are part of Google services, subject to Google's intellectual property rights and subject to the Google Terms of Service located at [http://www.google.com/accounts/TOS](https://policies.google.com/terms "Link to the ToS page for a Google Account.") as if they were "software." ## 1. Preparation for Certification
This section describes the necessary preparations before starting the
certification process. It outlines key definitions, requirements, and setup
steps to verify a smooth certification experience.
### 1.1 Definition
- **Initial pairing** is the sequence of events that occur when a user pairs a
device to a Google Account signed-in on phone for the very first time. In this
sequence, a phone detects the advertisement from the device and displays a
notification prompting the user to connect to and save the device. (In
this guideline, 'device' means the Bluetooth headset or speaker instead of a
reference phone).
- **Subsequent pairing** is the sequence of events that occur when a user signs
into their Google Account on a new phone and attempts to pair a device already
saved to their Google Account. In this sequence, the new phone recognizes that
the advertised Model ID is already saved to the user's Google Account and
provides a notification to expedite pairing the device to this phone.
### 1.2 Requirements
- All phones should be connected to the Internet and have Bluetooth and Location turned on in Settings.
- All phones should be logged in to the same Google Account.
- Reference phones should be phones actively on the market and cover a reasonably large population of users.
- A Bluetooth device implementing the version of Fast Pair, and associated extensions, that are to be certified.
### Classic with A2DP+HPF
- Three (3) reference phones with three (3) different versions of Android. The Android OS versions must be at least Version 11.
- Suggested reference phones to cover all Android OS versions:
- Google Pixel 8 (Android 15)
- Samsung S23 or later running Android 14
- Google Pixel 7 (Android 13)
- Google Pixel 6 (Android 12)
- Google Pixel 5 (Android 11)
- Samsung S20 or a later running Android 12 or 13
### BLE with Data Only
- Five (5) reference phones with three (3) different versions of Android. The Android OS versions must be at least Version 11.
- Suggested reference phones to cover all Android OS versions:
- Google Pixel 8 (Android 15)
- Samsung S23 or later running Android 14
- Google Pixel 7 (Android 13)
- Google Pixel 6 (Android 12)
- Google Pixel 5 (Android 11)
- Samsung S20 or a later running Android 12 or 13
### BLE with LE Audio
- Five (5) reference phones with three (3) different versions of Android. The Android OS versions must be at least Version 11.
- Suggested reference phones to cover all Android OS versions:
- Google Pixel 8 (Android 15)
- Samsung S23 or later running Android 14
- Google Pixel 7 (Android 13)
- Google Pixel 6 (Android 12)
- Google Pixel 5 (Android 11)
- Samsung S20 or a later running Android 12 or 13
> [!NOTE]
> **Note:** Screenshots in this guideline are from Android P.
### 1.3 Check Google Play Service version
- Purpose: To confirm the correct GMS Core version is used for testing.
- Go to **Settings \> Google \> Question mark on the right corner \> Three dots on
right corner \>"Version info"** , then check Google Play services version
(It should be `22.XX.XX` or higher).
### 1.4 Enable debug mode ID
- The model ID provided to you is a debug mode ID. To enable it, go to **Settings \> Google \> Devices \& Sharing \> Devices** to enable "Include debug results". If the option "Include debug results" is missing in this page, verify that Developer options in the Seeker is enabled.
> [!NOTE]
> **Note:** Older devices have a slightly different path, such as **Settings \>
> Google \> Devices connections \> Device \> top right 3 dot menu** for Android 12.
### 1.5 Enable Google Play services notifications
- Go to **Settings \> Notifications \> App settings \> Google Play services** and verify the switch Notifications is on.
### 1.6 Verify you can reach the test result server
Some test data is uploaded directly to Google servers. This data is required to
complete Self-Testing prior to starting Lab Certification. Verify your test
phone has the following:
- A logged-in test account that has joined [the FP test group](https://groups.google.com/g/fast-pair-partner-test/ "Link to the public Fast-Pair Test group.").
- The ability to stay powered and connected to the internet for 25 hours during and after running the initial and subsequent pairing tests. The phone will be attempting to upload test data and results during this time.
- A testing period and testing model ID matching the values provided in the [BT Classic](https://developers.google.com/static/nearby/fast-pair/downloads/self-test-reports/Bluetooth_Classic_-_Google_Fast_Pair_Self_Test_Report_10142020.zip "Link to the Fast Pair Bluetooth Classic Self-Test Report sheet.") or [BT LE Audio](https://developers.google.com/static/nearby/fast-pair/downloads/self-test-reports/LE_Audio_Dual_mode_-_Google_Fast_Pair_Self_Test_Report_2025_Q4.zip "Link to the Fast Pair LE Audio Self-Test Report sheet.") Self-Test Report.
- Usage \& diagnostics settings enabled on the test device. This can be verified by navigating to: **Settings \> Google \> 3 dots at top right corner \> Usage \&
diagnostics \> turn on usage \& diagnostics**.
## 2. Certification Criteria
This section details the specific criteria that must be met for a device to be
certified. These criteria cover various aspects of Fast Pair performance,
including pairing success rates, timing, and distance-based notification
behavior.
### 2.1 Definitions
- "All phones" refers to all reference phones with an OS matching the minimum versions defined in the [Requirements section](https://developers.google.com/nearby/fast-pair/fast-pair-certification-guideline#requirements).
- "Average pairing time" is (the sum of all the successful pairing times) / (10 - the number of failed pairings). Pairing time calculation starts when the user taps the Fast Pair notification, and ends when the phone displays a 'successful connection' notification to the user.
- "Success rate" for distance testing is (the number of notification pop up within 1 min / 10).
### 2.2 Notification dialog for initial pairing
- The notification should appear within 5 seconds.
### 2.3 Certification specification for pairing
> [!NOTE]
> **Note:** Google strongly recommends using the [Fast Pair Validator App](https://play.google.com/apps/testing/com.google.location.nearby.apps.fastpair.validator "Link to the Validator App on the Google Play Store.") to facilitate the pairing tests. Pairing is measured over a total of 100 tests, and the Validator App will automatically measure each pairing time and send it to the [Device console](https://developers.google.com/nearby/devices "Link to the Nearby console."). Without the app, you will need to manually record the times for each test in the [BT Classic](https://developers.google.com/static/nearby/fast-pair/downloads/self-test-reports/Bluetooth_Classic_-_Google_Fast_Pair_Self_Test_Report_10142020.zip "Link to the Fast Pair Bluetooth Classic Self-Test Report sheet.") or [BT LE Audio](https://developers.google.com/static/nearby/fast-pair/downloads/self-test-reports/LE_Audio_Dual_mode_-_Google_Fast_Pair_Self_Test_Report_2025_Q4.zip "Link to the Fast Pair LE Audio Self-Test Report sheet.") Self-Test Report.
- Each reference phone will be tested for initial and subsequent pairings 100 times respectively.
- The success rate for initial and subsequent pairing is measured by placing the
device 0.3 meters away from the reference phone.
- Average pairing time must be within 12 seconds when pairing firmware supporting just one component (e.g. a headset or single speaker).
- Average pairing time must be within 14 seconds when pairing firmware supporting Coordinated set members (e.g. left and right earbuds).
### Classic with A2DP+HPF
- Initial and subsequent pass rate must be at least 95%.
### BLE with Data Only
- Initial and subsequent pass rate must be at least 90%.
### BLE with LE Audio
- Initial and subsequent pass rate must be at least 90%.
- 80% of all reference phone's initial and subsequent pairing time must meet the
criteria.
### 2.4 Certification specification for distance
At least 80% of all reference phones must meet the criteria of this section when
tested at the 3 proscribed distances (0.3 meters, 1.2 meters, and 2 meters).
- The success rate at 0.3 meters must be 100%. In other words, each reference phone must run the 0.3 meters test 10 times and show every notification.
- The pairing notification appearance rate sent to reference phones at 1.2 meters must be less than or equal to 20% in 10 times.
- Each test performed at a 2 meter distance must never cause a notification to appear on the reference phones for at least 1 minute.
- Each distance will be tested 10 times for each reference phone.
### 2.5 \[Optional\] Certification specification for application launch
> [!NOTE]
> **Note:** This section is not a mandatory part of the standard Fast Pair certification. It is an optional test case, to be processed only when both Google and the product owner agree, depending on the specific product type and features.
This specification details the criteria for application launch,
which includes:
- Redirection to the Play Store for downloading the companion application when it is not installed on the reference phone.
- Direct launch of the companion application when it is already installed on the reference phone.
- Each scenario must be validated through three repetitions to ensure consistent performance.
Refer to [section 4.6 Application Launch](https://developers.google.com/nearby/fast-pair/fast-pair-certification-guideline#46_application_launch) for detailed
test procedures.
## 3. Fast Pair 2.0 Testing Guideline
This section provides a detailed guideline for testing Fast Pair 2.0,
covering user interface verification, test case procedures, and expected
behaviors.
### 3.1 User interface
The following images describe 4 different paring flow:
1. Initial Pairing without the device's Companion App downloaded.
1. Initial Pairing with the device's Companion App downloaded.
1. Subsequent Pairing with the device's Companion App downloaded.
2. Subsequent Pairing without the device's Companion App downloaded.
Cases 3 and 4 use the same flow.
- Error status
The notification to download a companion app will only appear if the Model ID
of the DUT is associated with a companion app link. Instead, if no companion
app association exists, the tester will only see the device name under
"Device connected" notification like they will see for subsequent pairings.
### 3.2 Test case 1: Initial pairing
This section outlines the steps for testing the initial pairing process,
verifying that devices can be successfully paired for the first time.
#### 3.2.1 Setup \& Test
- Verify the DUT doesn't appear as a saved device on any phone. On every phone that has saved the DUT and is logged in to the test Google Account: go to Bluetooth settings, choose "Forget Device", and toggle Airplane mode to ensure the DUT is forgotten.
- Verify "Automatically save devices" is ON. This switch is OFF by default.
You can find this option in **Settings \> Google \> Devices \> Saved devices**
of phone A.
### Classic with A2DP+HPF
No additional steps required.
### BLE with Data Only
No additional steps required.
### BLE with LE Audio
- Navigate to **Settings \> Connected devices \> Device details**
- Verify that the **LE Audio toggle** is set to "Disabled".
- Phones only supporting Bluetooth Classic (like the Pixel 6 and older) won't have this toggle in their menu settings.
- For the phones supporting LE Audio used in testing:
- Navigate to **Settings \> Connected devices \> Device details**
- Verify that the **LE Audio toggle** is set to "Enabled".
- Put the Bluetooth device in pairing mode.
- Place the Bluetooth device 0.3m away from the phone A.
- Wait for notification dialog in the reference phone A. The notification
should appear within 5 seconds.
- Start timing since tapping the initial notification until you see the
notification dialog 'Device connected' in phone A.
- Record the time in Initial pairing section of test report.
#### 3.2.2 Expected behavior
- Initial pairing half sheet appears:
- Tap the notification to start Fast Pair pairing. The notification will show progress:
- The phone will display a notification when Fast Pair pairing succeeds. The phone will also prompt the user to download the device's companion app from the Google Play store if the device maker releases a companion app.
- The phone will display an error if Fast Pair pairing fails: 
### 3.3 Test case 2: Pair this device to two reference phones signed in to the same Google-account (Subsequent pairing)
This section outlines the steps for testing the subsequent pairing process,
verifying that devices can be successfully paired to a new phone when already
saved to a Google Account.
#### 3.3.1 Setup \& Test
- Verify the DUT previously been paired with the other phone (phone A) that is
logged in with the same Google Account.
- To verify that the Bluetooth device has been paired with phone A:
- First, navigate to **Settings \> Google \> Devices \& sharing (or Device
connections) \> Devices \> Saved devices** on the phone that performed the initial pairing (phone A). The DUT should appear in the phone's saved devices list, like depicted here:
- Second, navigate to **Settings \> Google \> Devices \& sharing (or Device
connections) \> Devices \> Saved devices** on the device that has not paired with the DUT (phone B). Phone B will be able to display the subsequent pairing notification only if the DUT **also** appears in its saved devices list.
- Basically, after you run Test Case 1 (Initial Pairing) with phone A, you use
the other reference phone B with the same account to verify this Test Case 2
(Subsequent Pairing).
### Classic with A2DP+HPF
No additional steps required.
### BLE with Data Only
No additional steps required.
### BLE with LE Audio
- When testing the extensions features on a LE Audio capable device, the tests must be run with the LE Audio toggle set ON and OFF on the reference phone.
- This verifies that the device can connect to the reference phone using both L2CAP (When LE Audio is ON) and RFCOMM (when LE Audio is OFF).
- When testing a LE Audio capable device, the phones need to be arranged in the following configurations:
- Phone A supports LE Audio.
- Phone B does not support LE Audio.
- Phone C does not support LE Audio.
- Phone D supports LE Audio.
- When testing subsequent pairing for a LE Audio capable device, the tests must be run for the following combinations of test devices:
- The subsequent pairing notifications must appear correctly between LE Audio and non-LE Audio capable phones.
- For example: Confirm that, when Phone A performs initial pairing, Phone B can perform subsequent pairing. Also confirm that Phone B can perform initial pairing and Phone A can perform subsequent pairing.
- The subsequent pairing notifications must appear correctly between non-LE Audio capable phones.
- For example: Confirm that, when Phone B performs initial pairing, Phone C can perform subsequent pairing. Also confirm that Phone C can perform initial pairing and Phone B can perform subsequent pairing.
- The subsequent pairing notifications must appear correctly between a LE Audio capable phones and a phone supporting multiple, simultaneous LE Audio connections.
- For example: Confirm that, when Phone A performs initial pairing, Phone D can perform subsequent pairing. Also confirm that Phone D can perform initial pairing and Phone A can perform subsequent pairing.
- Place the Bluetooth device 0.3 m away from the phone.
- Wait for the device name sync to the account: Go to **Settings \> Google \>
Devices \& Sharing (or Device Connections) \> Devices \> Saved Devices** to check
whether the device name is shown. Return to the home screen once the DUT
appears in the phone's device list.
- Wait for the subsequent notification dialog.
- Measure the time from tapping the subsequent notification on the second phone
until you see the notification dialog 'Device connected'.
- Record the time in Subsequent section for the second phone.
- Clear the saved record by the following steps, which is precondition for the
next test.
- Forget the connected device by removing it from the Bluetooth settings list.
- Go to **Settings \> Google \> Devices \& sharing (or Device connections) \>
Devices \> Saved devices**.
- Turn off the 'Automatically save devices'
- Return to the previous page
- Turn On the 'Automatically save devices'
- Verify that you see 'No devices' in the device list like shown:
- Turn the device to get into pairing mode.
#### 3.3.2 Expected behavior
- Pairing notification for previously-associated device pops up
- Tap the notification to start subsequent pairing. The notification will show progress:
- When the Fast Pair pairing is completed, you will see the following notification:
- The phone will display an error if Fast Pair pairing fails:
### 3.4 Test case 3 : Check the BLE account key is still being broadcasted
- Make sure the headset [still broadcasts Account Data](https://developers.google.com/nearby/fast-pair/specifications/service/provider#AdvertisingWhenNotDiscoverable "Link to the Fast Pair specification page describing advertising intervals.") when it's not discoverable, for example: after initial pairing is completed and connected, unless the headset is powered off.
- Choose a reference phone and test it once for at least 30 minutes.
### 3.5 Test case 4 : Distance criteria
- Test each distance (0.3m,1.2m and 2m) 10 times individually.
- Record every time a reference phone displays a notification for each distance.
- For example, "0.3 meters - Yes (7/10)", would mean "This reference phone receives the pairing Notification 7 times (out of 10 times) at 0.3 meters"
### 3.6 How to capture debug log
This section guides you through the process of capturing debug logs, which are
essential for troubleshooting and analyzing issues during the certification
process.
#### 3.6.1 How to capture debugging information
> [!NOTE]
> **Note:** You must complete all these steps to capture the necessary debugging information. Google advises running these commands every time a phone is rebooted.
- To turn on logging and grab the bug report, run the following:
- `adb logcat -G 16M`
- Verify you have turned on "Bluetooth HCI snoop log for debugging". For Pixel
phones, this is accomplished by:
- Going to **Settings \> System \> About Phone \> Build number**.
- Tapping "Build number" 7 times to enable developer options.
\* Going to **Settings \> System \> Advanced \> developer options**.
\* Enabling Developer options and HCI snoop log.
\* This option enables the phone to collect the HCI packet log file.
\* Toggle airplane mode on and off to ensure the changes are applied.
#### 3.6.2 How to get logcat log file
- Run `adb devices` to show all the serial number of the devices on the terminal.
- Run `adb -s {device serial number} logcat > {logcat name}.txt` (You can name your logcat file arbitrarily and logcat multiple devices at the same time).
- Reproduce the bug.
- Run `Ctrl+C` to stop the logcat.
- Run `adb bugreport` to generate a zip file that should contain all of the data. It may take several minutes.
- Run the following commands to get btsnoop_hci.log (The devices need to be rooted).
- For Android O (8.0) or newer: `adb pull data/misc/bluetooth/logs/btsnoop_hci.log`
- For Android N: `adb pull sdcard/btsnoop_hci.log`
- If the earlier paths don't contain the hci.log : `adb shell; find hci.log` to get the location.
## 4. Feature Certification Criteria:
Need to pass all test cases, Battery notification is only mandatory for
true wireless headset.
> [!NOTE]
> **Note:** HUN represents the Heads up notification, Remember to enable HCI log when testing.
### 4.1 Battery notifications
> [!NOTE]
> **Note:** The thresholds of low battery notification of true wireless headset are 15% for buds and 19% for case. Verify that battery level for all device components is above the low battery threshold.
#### 4.1.1 Show left + right + case battery notification.
> [!NOTE]
> **Note:** Only the headsets which supports case battery notification needs to show the case battery level.
Procedure:
1. Pair the test phone with the true wireless headset.
2. Close case
3. Open case and verify.
Verify:
1. Battery notification shows 3 images of left, case, right, and the battery levels are correct within 10 seconds. (with charging icon on the left and right earbuds)
#### 4.1.2 Battery info should be updated after the battery level changes.
Procedure:
1. Pair the test phone with the true wireless headset.
2. Use true wireless headset to play any video for 10 min. (To reduce the power.)
3. Go to **Settings \> Google \> Devices \& sharing (or Device connections) \>
Devices \> Saved devices \> Headset name**.
Verify:
1. Battery info should be updated after the battery level changes.
2. The battery level should be the same as the battery level reported in the Bluetooth shortcut (Pull down quick setting bar), battery level should align one of the buds level, it's better to show the lowest battery level.
#### 4.1.3 Suppress notification, HUN should be dismissed (Close Case)
Procedure:
1. Pair the test phone with the true wireless headset.
2. Open case.
3. When HUN shows, Close case.
Verify:
1. Battery heads up notification dismissed within 3 seconds.
### 4.2 Personalized Name
This section covers the procedures for verifying that a device can be given a
personalized name, and that this name is consistently displayed across
different devices.
#### 4.2.1 Headset base case 1, Phone 1, account A, initial pair
Precondition:
1. Phone 1 never paired with the headset (in case phone has the cached alias)
2. Factory reset the headset before testing.
Procedure:
1. Login Phone 1 with Gmail account A. Pair Phone 1 with the Headset. Don't change the device name after paired.
2. Check 3 places shown.
Verify:
1. After paired, on the 3 places, phone 1 should show the account A user's first name + headset info. In the form of \[User's First Name\]'s \[Device Name\].
- Check name in 3 places
1. **Settings \> Google \> Devices \& Sharing \> Saved Devices**:
2. Quick Setting Bluetooth icon text (Pull down the quick setting bar):
3. Bluetooth settings:
#### 4.2.2 Headset base case 2, Phone 2, account B, initial pair \> edit device name
> [!NOTE]
> **Note:** This case is to verify two features: 1. When user #1 headset is borrowed by user #2 to initial pair with #2 phone. After pairing, phone 2 should see user #1 device name. 2. If user #2 wants to change the headset's device name, the new name should be updated to the headset and shown on phone #2.
Procedure:
1. Continue from Headset based case 1 of 3.
2. Phone 2, account B, initial paired successfully.
3. Check 3 places.
4. Go to **Bluetooth settings \> gear icon \> pencil icon \> change device
name**.
Verify:
1. After pairing, should show account A user's first name + headset info on
the following places:
1. **Settings \> Google \> Devices \& Sharing \> Saved Devices**:
2. Quick Setting Bluetooth icon text (Pull down the quick setting bar):
3. Bluetooth settings:
2. After changing the device name, the new name should appear in the following
places:
1. **Settings \> Google \> Devices \& Sharing \> Saved Devices**:
2. Quick Setting Bluetooth icon text (Pull down the quick setting bar):
3. Bluetooth settings:
#### 4.2.3 Headset base case 3, Phone 3, account C, initial pair
> [!NOTE]
> **Note:** This case is to make sure when user #3 borrowed user #2 headset, after user #3 initial pair with phone 3, User #2 new device names should show on phone 3.
Procedure:
1. Continue from Headset based case 2 of 3.
2. Phone 3, account C, initial paired successfully.
3. Check the 3 places listed:
1. **Settings \> Google \> Devices \& Sharing \> Saved Devices**:
2. Quick Setting Bluetooth icon text (Pull down the quick setting bar):
3. Bluetooth settings:
Verify :
1. Phone 3 should show phone 2's new device name in the same 3 places listed in the earlier Procedure steps.
### 4.3 Find Device - Ring Headset
This section covers the procedures for verifying that a device can be located
and rung using the Find My Device feature.
#### 4.3.1 Ring device headset function
Procedure:
1. Pair phone with headset successfully.
2. Go to **Settings \> Google \> Devices \& sharing (or Device connections) \>
Devices \> Saved devices \> Headset name \> Find device**.
3. Keep a distance of 2m between DUT and handset then tapping Ring device
button. (If test headset have right and left buds, it
should show two button for left and right)
4. Tap Mute device button.
Verify:
1. The status under headset name should show "Connected".
2. Headset should ring when tap this button with customized ringtone(TWS should ring corresponding side right/left). (For formal certification is based on the listening experience of lab staff)
3. Headset should mute immediately without any delay.
> [!NOTE]
> **Note:** Ring features need to test more than five times.
### 4.4 Retroactively Write Account Key
This section outlines the procedure for verifying that a device can
retroactively write an account key, enabling it to be recognized and managed by
a Google Account even if it wasn't initially paired through a Fast Pair
notification.
#### 4.4.1 Retroactive Pair and Confirm
Procedure:
1. Put fast pair device into pairing mode
1. You will see a heads-up notification, don't tap it.
2. Go to **Settings \> Connected devices \> Pair new device,** tap to pair 
3. Wait for a minute, you'll see a notification for retroactive pair.
4. Tap the notification to save the headset to your account. 
5. Go to **Settings \> Google \> Devices \& sharing (or Device connections) \>
Devices \> Saved devices**
Verify:
1. Retroactive Pair notification should show up.
2. You will see the device is in the saved device list. The device now has
full support for Fast Pair.
### 4.5 Active Noise Control
Active Notification Control, ANC, is an optional feature. ,Devices implementing ANC must verify it in Validator app and fill in the results in to their Self-Test Report, but don't need to have the feature certified in a 3rd Party Lab.
#### 4.5.1 Active Noise Control Verification
Procedure:
1. In the Validator app, select the mode that the DUT supports.
2. Pair the DUT to the Seeker.
3. Connect to the DUT from the Seeker.
Verify:
1. The Seeker sends ANC state (0x11) to the DUT after pairing.
2. The DUT responded with Notify ANC state (0x13) within 3 seconds.
3. The Seeker sends ANC state (0x12) for each supported ANC mode.
4. The DUT responds with Notify ANC state (0x13) within 5 seconds for every message sent in step 3.
#### 4.5.2 Active Notification Control Disable
Procedure:
1. In the Validator app, select the mode that the DUT supports.
2. Pair the DUT to the Seeker.
3. Connect to the DUT from the Seeker.
Verify:
1. The Seeker sends ANC state (0x11) to the DUT after pairing.
2. The DUT responded with Notify ANC state (0x13) within 3 seconds.
3. Confirm that Octet 5 matches the supported ANC modes for this Seeker.
4. Confirm that Octet 6 is 0b00000000
### 4.6 Application launch
This section details the test procedures for the optional Application Launch
feature. To enable this feature, the device must successfully pass the
following test cases and record the results in the [Self-Test Report](https://developers.google.com/static/nearby/fast-pair/downloads/self-test-reports/App_launch_Self_Test_Report_09022026.zip "Link to the App Launch Self-Test Report sheet."): Test Fast Pair notifications with the device placed at distances of 0.3, 1.2, and 2 meters from the phone.
- Redirection to the companion application download page in the Play Store when the companion application is not installed.
- Direct launch of the companion application when it is already installed.
Each scenario must be validated through three repetitions to ensure consistent
performance.
#### 4.6.1 Companion Application Download
- **Precondition:** The companion application must not be installed on the reference phone.
- **Test Steps:**
1. Place the device into pairing mode.
2. Observe the phone screen for the appearance of the Fast Pair half-sheet notification.
3. Tap the "Set up" button on the Fast Pair half-sheet notification. 
4. Confirm that the Play Store application is launched, specifically displaying the download page for the companion application.
5. Verify steps 1 to 4 for 3 repetitions to verify consistent behavior.
- **Expected Result:** Upon tapping "Set up" on the Fast Pair half-sheet notification, the user must be successfully redirected to the Play Store to download the companion application.
#### 4.6.2 Companion Application Launch
- **Precondition:** The companion application must already be installed on the reference phone.
- **Test Steps:**
1. Place the device into pairing mode.
2. Observe the phone screen for the appearance of the Fast Pair half-sheet notification.
3. Tap the "Set up" button on the Fast Pair half-sheet notification. 
4. Confirm that the companion application launches correctly.
5. Verify steps 1 to 4 for 3 repetitions to verify consistent behavior.
- **Expected Result:** Upon tapping "Set up" on the Fast Pair half-sheet notification, the companion application must successfully launch.
### 4.7 Sharing using Fast Pair
This section details the criteria for Sharing functionalities, building upon the Fast Pair BLE with LE Audio features.
#### 4.7.1 Preconditions and Test Environment
- **Phone Requirements:**
- **OS:** Android 16 or higher.
- **Devices:** Bluetooth LE Audio allowlist capable Pixel phones (mandatory).
- **Settings:** Enable Bluetooth, Location, "Scan for nearby devices", and "Include debug results".
- **Allowlist:** Verify that the Provider is included in the phone's LEA allowlist for sharing features prior to testing. *Note : Reach out to the Pixel Bluetooth team for the Allowlist verification process.*
- **Headset Requirements:**
- **Primary (Headset A):** Bluetooth LE Audio allowlist validated headset with BIS (Broadcast Isochronous Stream) support, connected to the phone with the LE Audio toggle enabled in its Bluetooth device settings.
- **Guest (Headset B):** Sharing using Fast Pair capable headset, to be used for joining the share.
- **Key Toggle:** Be familiar with the "Audio sharing" toggle under `Settings > Connected devices > Connection preferences > Audio sharing`.
#### 4.7.2 Functional Test Cases
**Reporting:** Test results (Pass/Fail/Notes) for each phone model used during testing should be recorded in the designated self-test report template.
- **Test Case 1: Audio Share - Temporary Account Key for sharing**
- **Goal / Objective:** Guest device joins the audio sharing session using Fast Pair half-sheet while media is playing.
- **Validation Points:** Ensure the Fast Pair sharing half-sheet is displayed correctly, while properly handling the temporary account key and successfully joining the audio sharing session.
- **Precondition:**
1. Primary Headset A connected, LE Audio active.
2. Media content is playing on Headset A.
- **Test Steps (Repeat for each Phone Model):**
1. Put Guest Headset B into pairing mode.
2. On the phone, tap the "Share" button on the Fast Pair sharing half-sheet.
- **Expected Result:**
1. Toast "Sharing with {Guest Device Name}" is shown.
2. Silent notification "You're sharing audio" is shown.
3. Media continues playing on both Headset A and Headset B.
- **Test Case 2: Audio Share - Temporary Account Key for pairing**
- **Goal / Objective:** Guest device joins the audio sharing session by selecting "Pair new device" within the Audio Sharing settings, where the sharing connection is secured using a temporary account key.
- **Validation Points:** Successful handling of the temporary account key, and successful joining the audio sharing session.
- **Precondition:**
1. Primary Headset A connected, LE Audio active.
- **Test Steps (Repeat for each Phone Model):**
1. Navigate to Headset A Device Details \> "Audio sharing".
2. Tap "Pair new device".
3. Put Guest Headset B into pairing mode.
4. Select Guest Headset B from the list in the "Pair new device" page to initiate pairing.
- **Expected Result:**
1. Guest Headset B successfully pairs and connects to the phone.
2. Media audio is now playing on both Headset A and Headset B.
#### 4.7.3 Pairing and Sharing Time Measurement
- **Test Case: Pairing and Sharing Time**
- **Precondition:** Media content is playing on Primary Headset A.
- **Test:** Measure time from tapping "Share" on the half-sheet until audio is playing on the Guest device. Repeat 30 times.
- **Criteria:**
- Average \<= 12 seconds.
- 95th percentile End-to-end latency \< 15 seconds.
#### 4.7.4 Pairing and Sharing Success Rate
- **Test Case: Pairing and Sharing Success Rate**
- **Precondition:** Media content is playing on Primary Headset A.
- **Test:** Attempt the sharing process (measure from tapping "Share" until audio plays on the Guest device) 30 times.
- **Criteria:** Success rate \>= 95%.
#### 4.7.5 Certification Template
- Partners should download the latest version of the [Fast Pair LE Audio Sharing self-test template](https://developers.google.com/static/nearby/fast-pair/downloads/self-test-reports/LEA_Sharing_v1.2_OEM_Self-test_case.zip "Link to the Fast Pair LE Audio Sharing Self-Test Report sheet.") provided by Google.
- All test results should be recorded and provided in the standard [Fast Pair LE Audio Sharing self-test template](https://developers.google.com/static/nearby/fast-pair/downloads/self-test-reports/LEA_Sharing_v1.2_OEM_Self-test_case.zip "Link to the Fast Pair LE Audio Sharing Self-Test Report sheet.").
- Partners should reach out to their SoC partner for failure case debugging.
### 4.8 LE Audio Hearing Aid without Internal Communication Channel
This section describes the certification criteria for LE Audio hearing aid
Providers that have one or more components and **no internal communication
channel** between them. Because the components cannot share data such as the
Account Key, the Seeker runs the full Fast Pair procedure once per component.
During initial and retroactive pairing, the Seeker writes the Account Key to
each component one at a time. Subsequent pairing doesn't write an Account Key.
For the Coordinated Set Info advertising payload, the FP Device Action
characteristic, and the pairing procedures, refer to
[BLE Device without Internal Channel](https://developers.google.com/nearby/fast-pair/specifications/bledevicewithoutinternalchannel).
#### 4.8.1 Preconditions and Test Environment
- **Provider Requirements:**
- An LE Audio hearing aid Provider, monaural or binaural, that implements [BLE Device without Internal Channel](https://developers.google.com/nearby/fast-pair/specifications/bledevicewithoutinternalchannel).
- Unless a test case says otherwise, the Provider has no Account Key (factory-reset it if needed), is not paired with the Seeker, and has no footprints on the test Google Account.
- **Phone Requirements:**
- **Devices and OS:** Test on the latest and the previous (latest minus
one) phone models and Android versions. Run every required test case
on each of the following phones:
- Two Pixel phones that cover the latest two Pixel models and the latest two Android versions, for example Pixel 10 (Android 16) and Pixel 11 (Android 17).
- One Samsung phone, for example Samsung Galaxy S26 (Android 16).
- **Accounts:** Two phones (phone A and phone B) signed in to the same
Google Account are required for the Subsequent Pairing test cases.
#### 4.8.2 Required Test Cases
| **Provider type** | **Required test cases** |
|---|---|
| Monaural (single component, single address) | 1, 4, 5 |
| Binaural | 1 -- 6 |
The Fast Pair Validator App covers Test Cases 1, 4 and 5. Test Cases 2, 3 and
6 must be run manually.
**Common verification:** After each test case that ends with the Provider
paired, verify the following:
1. **Settings \> Connected devices**: the Provider is paired.
2. **Settings \> Google \> Devices \> Saved devices** : the Provider appears in
footprints. The details page shows **one address** for a monaural
Provider and **two addresses** for a binaural Provider.
For a monaural Provider, "both components" in Test Cases 1, 4 and 5 means
the single component, and step 4 of Test Case 4 (waiting for the Account Key
to be written to the second component) does not apply.
#### 4.8.3 Functional Test Cases
**Reporting:** Record the result (Pass/Fail/Notes) of each test case for each
phone model in the designated self-test report template.
- **Test Case 1: First phone - Initial Pairing, both components at the same
time**
- **Goal / Objective:** Both components are paired and saved to the user's account with a single tap of **Connect**.
- **Test Steps:**
1. Put both components into discoverable mode.
2. On the phone, tap **Connect** on the initial pairing half-sheet.
3. Wait until both components are bonded.
- **Expected Result:** All checks in **Common verification** pass.
- **Test Case 2: First phone - Initial Pairing first, Incremental Pairing
second (binaural)**
- **Goal / Objective:** After the first component is paired, the second component is paired from the **Connect right/left hearing aid** prompt.
- **Test Steps:**
1. Put the first component into discoverable mode.
2. On the phone, tap **Connect** on the initial pairing half-sheet, then wait for the first component to bond.
3. Verify the half-sheet shows **Connect right/left hearing aid** and **Skip**.
4. Put the second component into discoverable mode.
5. Tap **Connect right/left hearing aid**, then wait for the second component to bond.
- **Expected Result:** All checks in **Common verification** pass.
- **Test Case 3: First phone - Initial Pairing first, Connect second
(binaural)**
- **Goal / Objective:** After the user skips the incremental prompt, the second component can still be paired later.
- **Test Steps:**
1. Put the first component into discoverable mode.
2. On the phone, tap **Connect**, then wait for the first component to bond.
3. When the half-sheet shows **Connect right/left hearing aid** and **Skip** , tap **Skip**.
4. Put the second component into discoverable mode. One of the following happens:
- **Found by Fast Pair:** the initial pairing half-sheet appears. Tap **Connect**.
- **Found by Bluetooth** (the usual case): the Bluetooth pairing dialog appears. Tap **Pair**.
5. Wait for the second component to bond.
- **Expected Result:** All checks in **Common verification** pass.
- **Test Case 4: First phone - Retroactive Pairing**
- **Goal / Objective:** A hearing aid paired from Bluetooth settings is saved to the user's account with a single tap of **Save**.
- **Test Steps:**
1. Put both components into discoverable mode.
2. Go to **Settings \> Connected devices \> Pair new device** and pair the hearing aid, then wait for the components to bond.
3. When the half-sheet with **Save** appears, tap **Save**.
4. Wait about 10 seconds for the Account Key to be written to the second component.
- **Expected Result:**
1. The **Save** half-sheet appears **only once**.
2. All checks in **Common verification** pass.
- **Test Case 5: Second phone - Subsequent Pairing, both components at the
same time**
- **Precondition:** Test Case 1 has passed on phone A. Phone B is signed in to the same Google Account and has never paired with the Provider.
- **Test Steps (on phone B):**
1. Keep both components in non-discoverable mode.
2. Wait for the subsequent pairing notification to appear, then tap it.
3. When the half-sheet appears, wait for both components to bond.
- **Expected Result:** All checks in **Common verification** pass.
- **Test Case 6: Second phone - Subsequent Pairing first, Incremental Pairing
second (binaural)**
- **Precondition:** Test Case 1 has passed on phone A. Phone B is signed in to the same Google Account and has never paired with the Provider.
- **Test Steps (on phone B):**
1. Keep the first component in non-discoverable mode.
2. Tap the subsequent pairing notification, then wait for the first component to bond.
3. Verify the half-sheet shows **Connect right/left hearing aid** and **Skip**.
4. Keep the second component in non-discoverable mode. The phone finds it through the Account Key Data advertisement.
5. Tap **Connect right/left hearing aid**, then wait for the second component to bond.
- **Expected Result:** All checks in **Common verification** pass.
#### 4.8.4 Distance and Initial Pairing Latency
The following hearing aid criteria replace the generic criteria in sections 2.3
and 2.4. Run each test 10 times on each target phone in section 4.8.1, and
record the results in the "Distance Test / Pairing Latency" sheet of the
self-test template.
- **Distance (threshold 45 cm):**
- **Test:** Put the Provider in discoverable mode at 15 cm, 60 cm and 100 cm from the phone, and check whether the initial pairing half-sheet appears within 1 minute.
- **Criteria:**
- 15 cm: the half-sheet appears in 10 of 10 attempts.
- 60 cm and 100 cm: the half-sheet does not appear in any of the 10 attempts.
- **Initial Pairing Latency:**
- **Test:** Run Test Case 1 at 15 cm, and measure the time from tapping **Connect** until all components are bonded. Repeat 10 times.
- **Criteria:** Record each result and the average in the template.
#### 4.8.5 Certification Template
- Partners should download the latest version of the [Fast Pair LE Audio Hearing Aid self-test template](https://developers.google.com/static/nearby/fast-pair/downloads/self-test-reports/LEA_Hearing_Aid_v1.00_OEM_Self-test_case.zip "Link to the Fast Pair LE Audio Hearing Aid Self-Test Report sheet.") provided by Google.
- All test results should be recorded and provided in the standard [Fast Pair LE Audio Hearing Aid self-test template](https://developers.google.com/static/nearby/fast-pair/downloads/self-test-reports/LEA_Hearing_Aid_v1.00_OEM_Self-test_case.zip "Link to the Fast Pair LE Audio Hearing Aid Self-Test Report sheet.").
- Partners should reach out to their SoC partner for failure case debugging.