Preparation for Certification
- Prepare test devices.
- You will need 5 Android devices.
- These devices must include:
- At least one Android T (13) and one Android V (15).
- At least one Samsung and one Pixel.
- For example:
- 1 OnePlus (Android 10).
- 3 Samsung (Android 11, 12, 13).
- 1 Pixel (Android 15).
- These devices must include:
- One device without Audio switch:
- Any iPhone, PC, Bluetooth (BT)-enabled laptop, or an Android phone
which Audio switch disabled.
- You can turn off Audio switch from Bluetooth device detail setting.
- Multipoint (MP) Test case 2.8 needs a device without Audio switch in addition to the 5 test phones.
- Any iPhone, PC, Bluetooth (BT)-enabled laptop, or an Android phone
which Audio switch disabled.
- You will need 5 Android devices.
Join the Audio switch test group with your test accounts in order to show debug notifications on test phones.
- This also enables Google to collect test data through Google Analytics.
Classic with A2DP+HFP
- Ensure all Android devices have GmsCore version
23.xx.xx
or later installed.
BLE with LE Audio
- At least two of the reference phones must support LE Audio.
- For example, one Samsung phone and one Pixel phone that support LE Audio.
- Ensure all Android devices have GmsCore version
24.33.xx
or later installed.
Certification Criteria
- Target Switching success rate must exceed 95% in all test cases.
In tests requiring a switch, the profile connection and switch active state must complete within 3 seconds after triggering audio events in at least 75% of cases.
Classic with A2DP+HFP
Self-Tests must be performed in the following combinations:
- Phone A=Android S (12) + Phone B=Android T (13)
- Phone A=Android T (13) + Phone B=Android S (12)
BLE with LE Audio
Self-Tests must be performed in the following combinations:
- Phone A: BT Classic, Phone B: BT Classic
- Phone A: LE Audio, Phone B: BT Classic
- Phone A: BT Classic, Phone B: LE Audio
Optionally, Providers that support Dual LE Audio connections should test:
- Phone A: LE Audio, Phone B: LE Audio
Testing Guide
Device Under Test (DUT) Preparation
- Verify that the BT device hasn't previously been paired with any phone
logged-in to the testing Google Account.
- If the device has been paired to the testing Google Account, do the
following to clear the pairing:
- In the paired devices:
- Navigate to the Bluetooth settings.
- Choose "Forget Device".
- Toggle Airplane mode on and off.
- In the paired devices:
- Ensure "Automatically save devices" is ON.
- This switch is OFF by default.
- You can find this option in Settings > Google > Devices > Saved devices (one per DUT).
- Put the Bluetooth device in Pairing Mode.
- Pair the initial Bluetooth device (A).
- Pair subsequent Bluetooth devices with other devices (B, C, D, etc.).
- If the device has been paired to the testing Google Account, do the
following to clear the pairing:
Scope
- All Headsets run tests from the various tabs in either the BT Classic or BT LE Audio Self-Test report.
- Headsets supporting only SinglePoint (SP) mode run the following:
- The Generic_test tab.
- Headsets supporting MP mode run the following:
- The Generic_test tab.
- The Multipoint_only tab.
- MP headsets that can be toggled into SP mode run the following:
- The Generic_test tab with MP off.
- The Generic_test tab with MP on.
- The Multipoint_only tab with MP on.
Completing Self-Rest and the Self-Test Report
- Make a copy of either the BT Classic or BT LE Audio Self-Test Reports.
- Run all test cases at least twice.
Tests should be executed in the following form:
Classic with A2DP+HFP
- Device B will be the main DUT.
- Enter Device B's details into the "Phone" and "OS" fields on the top of the template.
An example test case:
Test phones:
- Device 1: Samsung (Android 13)
- Device 2: Pixel (Android 12 or 13) and others.
Executed tests:
- Run 1. Device A=Samsung S10+ (12), Device B=Pixel 7 pro (13) column D: Phone=Pixel 7 pro, OS=Android 13
- Run 2. Device A=Pixel 7 pro (13), Device B=Pixel 6(12) column E: Phone=Pixel 6, OS=Android 12
An example of a completed test in the self-test template:
BLE with LE Audio
- Device A=Android V (15) + Device B=Android T (13)
- Device A=Android T (13) + Device B=Android V (15)
- Device A=Android T (13) + Device B=Android S (12)
- Device A=Android T (15) + Device B=Android V (15)
- Device B will be the main DUT.
- Enter Device B's details into the "Phone" and "OS" fields on the top of the template.
An example test case:
Test phones:
- Device 1: Samsung (Android 13)
- Device 2: Pixel (Android 15) and others.
Executed tests:
- [LEA+BT]: Device A= Pixel 8 (15), Device B=Pixel 7 pro (13) column D: Phone=Pixel 7 pro, OS=Android 13
- [BT+LEA]: Device A=Pixel 7 (13), Device B=Pixel 8 (Android 15) column E: Phone=Pixel 8, OS=Android 15
- [BT+BT]: Device A=Pixel 7 pro (13), Device B=Samsung S10+ (12) column E: Phone=Samsung S10+, OS=Android 12
- [LEA+LEA]: Device A=Pixel 8 (15), Device B=Pixel 8(15) column E: Phone=Pixel 8, OS=Android 15
An example of a completed test in the self-test template:
Audio Events:
The 4 types of tested audio events and recommended testing apps are:
- Call:
- The built-in phone app.
- VoIP: Any VoIP App will work, such as:
- The Audio switch test app.
- FB Messenger.
- Line.
- WhatsApp.
- Google Meet.
- Google Meet.
- Media: Any audio player will work, such as:
- The Audio switch test app.
- Youtube Music.
- Apple Music.
- Spotify.
- Google Podcasts.
- Game:
- The Audio switch test app.
- Call:
Debug Information:
Notifications are enabled after joining the fp-sass-partner-test group. Here are some examples:
- Latest state notification:
- No switch notification:
- Switch latency notification:
Latency Measurement
- There are two kinds of switch latency:
- Connecting a Bluetooth profile to a disconnected Seeker.
- This include all SinglePoint cases, and some MP cases whose target Seeker (device B) is disconnected.
- Switching the active connected Seeker.
- This includes some MP cases which the target Seeker (device B) is already connected.
- Connecting a Bluetooth profile to a disconnected Seeker.
- There are two ways to retrieve latency info:
- All latency can be dumped by adb command.
- Refer to the dump latency section for details.
- This command can provide and record latency after finishing at least one test case.
- Using the Audio switch test app.
- The App running on the target Seeker will display latency after switching.
- If there was no switch, the app will display the 'no switch' reason.
- All latency can be dumped by adb command.
Audio switch Test App:
- Using the app to trigger VoIP/Media/Game audio events during a self test
will simplify test setup and reduce the Seeker's event latency.
- The latest version can be downloaded here.
- The LE Audio VoIP test needs a policy to be manually enabled: > adb root > adb shell settings put global hidden_api_policy 1 > adb reboot
- App Installation:
- Copy the apk to your test phone and open it.
- Alternatively, use
adb install audio_test_app.apk
.
- If you see a dialog asking for notification access:
- click "OK"
- Choose "FP SASS test" in the app list
- Allow notification access.
App Overview:
Target provider
- This button will show a list of paired Bluetooth devices when clicked. Select the one you want to test.
- The Connect and Disconnect buttons works like the one in the Bluetooth settings' device detail.
Current state
- This field shows the last connection state the Seeker received from a Provider using BLE advertising or event stream.
- Audio switch debug notifications are also shown here.
Seeker type
- This option is used to switch the device between audio streams.
Audio type
Classic with A2DP+HFP
- VoIP
- Selecting this mode will change the audio mode to
AudioManager.MODE_IN_COMMUNICATION
and callAudioManager.startBluetoothSco
, then play audio withUSAGE_VOICE_COMMUNICATION
. - The stream type is
STREAM_VOICE_CALL
. - The provider connection state should switch to
CONNECTED_HFP
within 5 seconds.
- Selecting this mode will change the audio mode to
- Media
- Selecting this mode will play audio supporting AVRCP. The audio usage
type is:
USAGE_MEDIA
. - The provider connection state should switch to
CONNECTED_A2DP_WITH_AVRCP
within 5 seconds. - The connection state may briefly switch to
CONNECTED_A2DP_ONLY
when started or stopped.
- Selecting this mode will play audio supporting AVRCP. The audio usage
type is:
- Game
- Selecting this mode plays audio which doesn't support AVRCP. The audio
usage type is:
USAGE_GAME
. - The provider connection state should switch to
CONNECTED_A2DP_ONLY
within 5 seconds.
- Selecting this mode plays audio which doesn't support AVRCP. The audio
usage type is:
BLE with LE Audio
VoIP
- Selecting this mode will change the audio mode to
AudioManager.MODE_IN_COMMUNICATION
and play audio withUSAGE_VOICE_COMMUNICATION
.
- The stream type is
STREAM_VOICE_CALL
. - The provider connection state should switch to
CONNECTED_LE_AUDIO_CALL
within 5 seconds.
- Selecting this mode will change the audio mode to
Media
- Selecting this mode will play audio with stream type as
STREAM_MUSIC
. The audio usage type is:USAGE_MEDIA
. - The provider connection state should switch to
CONNECTED_LE_AUDIO_MEDIA_WITH_CONTROL
within 5 seconds. - The connection state may briefly switch to
CONNECTED_LE_AUDIO_MEDIA_WITHOUT_CONTROL
when started or stopped.
- Selecting this mode will play audio with stream type as
Game
- Selecting this mode plays audio which the user doesn't have direct
control over. The audio usage type is:
USAGE_GAME
. - The provider connection state should switch to
CONNECTED_LE_AUDIO_MEDIA_WITHOUT_CONTROL
within 5 seconds.
- Selecting this mode plays audio which the user doesn't have direct
control over. The audio usage type is:
Play and Stop buttons
- The PLAY and STOP buttons start or stop the audio.
Switch result
- This field displays the Connect and Switch active latency. It also displays the reason for denying a switch if an audio event was triggered but the switch didn't happen.
- Latency is measured in milliseconds (ms).
- In general, latency is measured from the start of the Audio switch trigger to the receipt of a BT profile connected or Notify multipoint-switch event.
- Provider-triggered switches measure latency from audio start.
Dump Latency
- The following command allows a user to capture latency measurements when
running manual tests:
adb shell dumpsys activity service com.google.android.gms/.nearby.discovery.service.DiscoveryService
- Latency measurements are shown under
NearbyDeviceManager
'sSwitchHistory
section:
- Latency measurements are shown under
NearbyDeviceManager
Nearby Sass device count: 1
Sass device - address:XX:XX:XX:XX:XX:XX, name:Googler's Pixel Buds, accountKey:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, modelId:6edaf7
SwitchHistory
15:30:21:166 - 15:30:25:201, latency 3035ms, Succeed, SASS_TRIGGERED_CONNECT, SASS switch, A2DP
15:34:58:568 - 15:34:58:568, latency 0ms, Succeed, SWITCH_ACTIVE_TO_SELF, SASS switch, HFP
15:36:26:615 - 15:36:31:603, latency 1988ms, Succeed, SASS_TRIGGERED_CONNECT, SASS switch, A2DP
15:37:56:108 - 15:37:56:250, latency 142ms, Succeed, SWITCH_ACTIVE_TO_SELF, SASS switch, A2DP"
- Any switch that GmsCore cannot measure (e.g. active switch for HFP) will be recorded as 0ms latency.
Reference of log patterns:
Known Issues:
The following are known bugs caused by the Seeker:
- Incorrect game audio switching.
- Samsung phones will set the connection state to
CONNECTED_A2DP_WITH_AVRCP
, instead ofCONNECTED_A2DP_ONLY
when playing games. - Some games (such as Candy crush) may replay background music and trigger a new audio event without user input. The connected phones may constantly switch audio on every phone that opens the game.
- Samsung phones will set the connection state to