Audio switch Certification Guidelines

Preparation for Certification

  1. Prepare test devices.
    • You will need 5 Android devices.
      • These devices must include:
        • At least one Android T (13) and one Android S (12).
        • At least one Samsung and one Pixel.
        • For example:
          • 1 OnePlus (Android 10).
          • 3 Samsung (Android 11, 12, 13).
          • 1 Pixel (Android 13).
    • 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.
  2. 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.
  3. Ensure all Android devices have GmsCore version 23.xx.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.

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

  • Run all test cases at least twice.
  • Tests should be executed in the following form:
  1. Device A=Android S (12) + Device B=Android T (13)
  2. Device A=Android T (13) + Device B=Android S (12)
  3. 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

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:

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

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

  1. 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.
  • 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
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.
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(e.g. 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.