Audio switch Certification Guidelines

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).
    • 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.

  • 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.
    • 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.).

Scope

  • All Headsets run tests from the various tabs in the Audio switch self test template.
  • 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

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:

This picture shows the results of an example test

BLE with LE Audio

  1. Device A=Android V (15) + Device B=Android T (13)
  2. Device A=Android T (13) + Device B=Android V (15)
  3. Device A=Android T (13) + Device B=Android S (12)
  4. Device A=Android T (15) + Device B=Android V (15)
  5. 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:

This picture shows the results of an example test

Audio Events:

  • The 4 types of tested audio events and recommended testing apps are:

    1. Call:
      1. The built-in phone app.
    2. VoIP: Any VoIP App will work, such as:
      1. The Audio switch test app.
      2. FB Messenger.
      3. Line.
      4. WhatsApp.
      5. Google Meet.
      6. Google Meet.
    3. Media: Any audio player will work, such as:
      1. The Audio switch test app.
      2. Youtube Music.
      3. Apple Music.
      4. Spotify.
      5. Google Podcasts.
    4. Game:
      1. The Audio switch test app.

Debug Information:

  • Notifications are enabled after joining the fp-sass-partner-test group. Here are some examples:

    • Latest state notification:

    Figure 1: This shows the 'latest state notification' message.

    • No switch notification:

    Figure 2: This shows the 'no switch notification' message.

    • Switch latency notification:

    Figure 3: This shows the 'switch latency notification' message.

Latency Measurement

  • There are two kinds of switch latency:
    1. Connecting a Bluetooth profile to a disconnected Seeker.
      • This include all SinglePoint cases, and some MP cases whose target Seeker (device B) is disconnected.
    2. Switching the active connected Seeker.
      • This includes some MP cases which the target Seeker (device B) is already connected.
  • There are two ways to retrieve latency info:
    1. 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.
    2. 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.

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.
    • Version latest 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:
    1. click "OK"
    2. Choose "FP SASS test" in the app list
    3. Allow notification access.

App Overview:

This picture is an example of the app running

  • 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 call AudioManager.startBluetoothSco, then play audio with USAGE_VOICE_COMMUNICATION.
    • The stream type is STREAM_VOICE_CALL.
    • The provider connection state should switch to CONNECTED_HFP within 5 seconds.
  • 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.
  • 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.

BLE with LE Audio

  • VoIP

    • Selecting this mode will change the audio mode to AudioManager.MODE_IN_COMMUNICATION and play audio with USAGE_VOICE_COMMUNICATION.
    • The stream type is STREAM_VOICE_CALL.
    • The provider connection state should switch to CONNECTED_LE_AUDIO_CALL within 5 seconds.

  • 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.

  • 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.

  • 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's SwitchHistory section:
            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:

Examples of logs from the latency test

Known Issues:

The following are known bugs caused by the Seeker:

  1. Incorrect game audio switching.
    • Samsung phones will set the connection state to CONNECTED_A2DP_WITH_AVRCP, instead of CONNECTED_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.