Audio switch Validator App User Manual

Setup

To enable Audio switch testing in the Validator app:

  • Ensure the device has GmsCore version 22.08.xx or later.
  • Ensure your testing emails are part of the Audio switch Partner Testing Group.
    • It may take 6-24 hours for newly registered emails and/or devices to synchronize permissions.
    • Logging in and out of the associated Google Account may also trigger an immediate sync.

Example: Supported GMS Version and details

Testing Requires Fast Pair

Audio switch tests require the phones to be paired via Fast Pair:

  1. Prepare two phones, A and B, logged into the same Google Account.
  2. Pair headset with phone A (Initial pairing).
  3. Enter pairing mode, wait for HalfSheet UI popup.
  4. Click Connect.
  5. Click Done.
  6. Pair headset with phone B (Subsequent pairing).
    1. Wait for notification that both pairings have completed.
  7. Click system notification.

Example flow:

Figure 2: This shows the button sequence for the initial pairing Device A.
Figure 3: This shows the button sequence for the subsequent pairing Device B.

Basic UI Flow

The general UI flow is pictured below:

Figure 4: This shows the initial sign-in and discovery of devices.
Figure 5: This shows how to select a device for testing.
Figure 6: This shows the different types of tests and which device they correspond to.
Figure 7: This shows how to target a particular device for a given test.

Audio Switch Single-Point Tests

Audio switch Test (Single-Point)

This test performs the following functions:

  • Payload verification.
    • Verifies the advertising data for different scenarios.
  • Message stream verification.
    • Verifies message stream communication.
  • Switch back.
    • Verifies switchback behavior.

Payload Verification (Single-point)

The Payload Verification sequence is as follows:

  1. Connect to the headset.
  2. Verify that the first byte of the account key is 0x06, as required by the standard.
  3. Disconnect from device.
  4. Verify that the first byte of the account key is 0x05, as required by the standard.
  5. Re-connect to headset.
  6. Play music.
  7. Verify the connection state is one of the following:
    1. 0x4: A2DP streaming only.
    2. 0x5: A2DP streaming with AVRCP.
  8. Start a SCO connection.
  9. Verify the SCO connected succeeded.
  10. Verify the connection state is:
    1. 0x6: HFP (phone/voip call) streaming, including inband and non-inband ringtone.

An Example of Payload Verification (single-point):

Figure 8: This shows the payload verification test results for an example device.

Message Stream Verification (Single-Point)

The Message Stream Verification sequence is as follows:

  1. Verify session nonces between different RFCOMM connections.
    1. Connect to the headset.
    2. Get the nonce X from headset (within 5 seconds).
    3. Reconnect to the headset.
    4. Get another nonce Y from the headset (within 5 seconds).
    5. Verify if X and Y are different.
  2. Send the Get Audio switch Capability request.
    1. Verify the response was sent within 2 seconds. Contents are not checked.
  3. Send the Indicate in-use Account Key request.
    1. Verify the response was sent within 2 seconds. Contents are not checked.
  4. Send the Notify Initiated Connection request.
    1. Verify the response was sent within 2 seconds. Contents are not checked.
  5. Send the Send Custom Data request.
    1. Verify the ACK is returned within 2 seconds.
    2. Verify if adv data contains the set custom data (in 10 seconds).

An example of Message Stream verification (single-point):

Figure 9: This shows the message stream verification test results for an example device.

Switch Back (Single-Point)

This test requires two devices: a Primary and Secondary Seeker. The test sequence is as follows:

  1. The Primary Seeker connects to the headset (within 10 seconds).
  2. Secondary Seeker connects to the headset (within 10 seconds).
  3. Secondary Seeker sends switching back request to the headset.

Within 15 seconds, the following should occur:

  • Primary Seeker connects back to the headset.
  • Secondary Seeker disconnects from the headset.

Figure 10: This shows the Secondary's Display options allowing sufficient test time for the Primary device.

The following shows an example of the Switch-Back test:

Figure 11: This shows how to initialize the Switch-Back test.
Figure 12: This shows how to define which device handles which role.
Figure 13: This shows how to proceed once roels are defined.
Figure 14: This shows how the devices appear while waiting for verification.
Figure 15: This shows where it is necessary to keep the Seocndary device powered and active.
Figure 16: This shows the results of a successful test.

Audio switch Multi-Point Tests

Payload Verification (Multi-Point)

The Payload Verification sequence is as follows:

  1. Connect to the headset.
  2. Verify that the first byte of the account key is 0x06, as required by the standard.
  3. Disconnect from device.
  4. Verify that the first byte of the account key is 0x05, as required by the standard.
  5. Re-connect to headset.
  6. Play music.
  7. Verify the connection state is one of the following:
    1. 0x4: A2DP streaming only.
    2. 0x5: A2DP streaming with AVRCP.
  8. Start a SCO connection.
  9. Verify the SCO connected succeeded.
  10. Verify the connection state is:
    1. 0x6: HFP (phone/voip call) streaming, including inband and non-inband ringtone.

Message Stream (Multi-Point)

This test requires a Primary and Secondary Seeker. Tests with the multiplint configurability flag set TRUE will have additional steps to test this state through the message stream command.

An example of a Non-configurable Message Stream test (Multi-point):

Figure 17: This shows the results of a successful non-configurable test.
An example of a Configurable Message Stream test (Multi-point):
Figure 18: This shows the results of a successful configurable test.

Switch Back (Multi-Point)

This test requires a Primary and Secondary Seeker. This test is nearly identical to the single-point version. The only difference is: since the Provider supports multiple connections, when Secondary Seeker connects to the Provider, the Primary Seeker will still connect to the Provider.

An example of the Multi-point Switch-Back test:

Figure 19: This shows how the test allows the switch-back on a Multi-Point device.

Switch Active (Multi-Point Only)

This test requires a Primary and Secondary Seeker.

This test only verifies that the Provider sends the expected messages via the message stream channel.

Test steps:

  1. The Primary Seeker connects to the Provider
  2. The Primary Seeker checks the capability of the Provider.
    1. If Multi-Point is off AND Multi-Point Configurable is TRUE it will try to enable Multi-Point.
  3. The Primary Seeker will invoke Switch active audio source (to connected device) (0x30) to self.
  4. The Secondary Seeker connects to the Provider.
  5. The Primary Seeker will invoke Switch active audio source (to connected device) (0x30) to another device.
  6. The Provider will ACK the Primary Seeker.
  7. The Secondary Seeker will receive Notify multipoint-switch event (0x32) with the active state.

An example of the Switch Active (Multi-point Only) test:

Figure 20: This shows how the test allows the switch-back on a Multi-Point-only device.

Uploading Results To Device Console

Submitting Your Results

The App provides a button for uploading results once the tests are complete, as shown below:

Figure 21: This shows how to submit test results with the 'submit' button.
Figure 22: This shows how the result of submitting a test.

Using Device Console

Submitted test results can be found on the Nearby Console. (Distance Metrics & Duration Metrics will be removed for Audio switch test cases). For example:

Figure 23: This shows a set of example test reports on the Nearby Console.

Troubleshooting

Try toggling Bluetooth off and on if all your tests failed.

Figure 24: This shows an example of how to toggle the Bluetooth settings.

If your Switch-Back test failes and is stuck in the below state (fig1): Try going back to the Test-device page (fig2) and retesting.

Figure 25: This shows an example of how to re-test a Switch-Back case.