[null,null,["最后更新时间 (UTC):2025-08-22。"],[[["\u003cp\u003eThis guide focuses on using the Audio switch version of the Validator App for testing Fast Pair devices.\u003c/p\u003e\n"],["\u003cp\u003eSetup involves ensuring your device has the correct GmsCore version and your testing emails are registered with the Fast Pair Partner Testing Group.\u003c/p\u003e\n"],["\u003cp\u003eThe app tests various aspects of audio switching, including payload verification, message stream communication, and switch back functionality, in both single-point and multi-point scenarios.\u003c/p\u003e\n"],["\u003cp\u003eTo submit test results to Google, press the 'SUBMIT' button on the results page after reviewing them.\u003c/p\u003e\n"],["\u003cp\u003eUploaded results can be viewed on the Nearby Console.\u003c/p\u003e\n"]]],[],null,["# Audio switch Validator App User Manual\n\nThis page is specific to the Audio switch version of the Validator App. See the\n[LE Audio Validator App page](/nearby/fast-pair/lea-validator-app-user-manual \"Link to the LE Audio Validator App User Manual page.\") for help on the LE Audio\nversion of the Validator App.\n\nSetup\n-----\n\nTo enable testing in the Validator app:\n\n- Ensure the device has GmsCore version 22.08.xx or later.\n- Ensure your testing emails are part of the [Fast Pair Partner Testing Group](mailto:fast-pair-integrations@google.com \"MailTo link for the Support group.\").\n - It may take 6-24 hours for newly registered emails and phones to synchronize permissions.\n - Logging in and out of the associated Google Account may also trigger an immediate sync.\n\nExample:\n\n### Required Devices\n\nAudio switch tests require the phones to be paired using Fast Pair:\n\n1. Prepare two phones, A and B, logged into the same Google Account.\n2. Pair headset with phone A (Initial pairing).\n3. Enter pairing mode, wait for Half Sheet UI notification.\n4. Click Connect.\n5. Click Done.\n6. Pair headset with phone B (Subsequent pairing).\n 1. Wait for notification that both pairings have completed.\n7. Click system notification.\n\nExample flow:\n\n\nBasic UI Flow\n-------------\n\nThe following shows the general UI flow:\n\n\nAudio Switch Single-Point Tests\n-------------------------------\n\n### Audio switch Test (Single-Point)\n\nThis test performs the following functions:\n\n- Payload verification.\n - Verifies the advertising data for different scenarios.\n- Message stream verification.\n - Verifies message stream communication.\n- Switch back.\n - Verifies switchback behavior.\n\n### Payload Verification (Single-point)\n\n| **Note:** each step has a 10-second timeout.\n\nThe Payload Verification sequence is as follows:\n\n1. Connect to the headset.\n2. Verify that the first byte of the account key is 0x06, as [required by the specification](/nearby/fast-pair/specifications/extensions/sass#SassInUseAccountKey \"Link to the in-use Account Key section.\").\n3. Disconnect from device.\n4. Verify that the first byte of the account key is 0x05, as [required by the specification](/nearby/fast-pair/specifications/extensions/sass#SassInUseAccountKey \"Link to the in-use Account Key section.\").\n5. Re-connect to headset.\n6. Play music.\n7. Verify the connection state is one of the following:\n 1. 0x4: A2DP streaming only.\n 2. 0x5: A2DP streaming with AVRCP.\n8. Start a SCO connection.\n9. Verify the SCO connected succeeded.\n10. Verify the connection state is:\n 1. 0x6: HFP (phone/voip call) streaming, including inband and non-inband ringtone.\n\nAn Example of Payload Verification (single-point):\n\n### Message Stream Verification (Single-Point)\n\nThe Message Stream Verification sequence is as follows:\n\n1. Verify session nonces between different Message Stream connections.\n 1. Connect to the headset.\n 2. Get the nonce X from headset (within 5 seconds).\n 3. Reconnect to the headset.\n 4. Get another nonce Y from the headset (within 5 seconds).\n 5. Verify if X and Y are different.\n2. Send the [Get Audio switch Capability](/nearby/fast-pair/specifications/extensions/sass#GetCapabilityOfSass \"Link to the Get Audio switch Capability requirement page.\") request.\n 1. Verify the response was sent within 2 seconds. Contents are not checked.\n3. Send the [Indicate in-use Account Key](/nearby/fast-pair/specifications/extensions/sass#IndicateInUseAccountKey \"Link to the In-use Account Key requirement page.\") request.\n 1. Verify the response was sent within 2 seconds. Contents are not checked.\n4. Send the [Notify Initiated Connection](/nearby/fast-pair/specifications/extensions/sass#NotifySassInitiatedConnection \"Link to the Notify Indicated Connection requirement page.\") request.\n 1. Verify the response was sent within 2 seconds. Contents are not checked.\n5. Send the [Send Custom Data](/nearby/fast-pair/specifications/extensions/sass#SendCustomData \"Link to the Send Custom Data requirement page.\") request.\n 1. Verify the ACK is returned within 2 seconds.\n 2. Verify if adv data contains the set custom data (in 10 seconds).\n\nAn example of Message Stream verification (single-point):\n\n### Switch Back (Single-Point)\n\nThis test requires two devices: a Primary and Secondary Seeker.\nThe test sequence is as follows:\n\n1. The Primary Seeker connects to the headset (within 10 seconds).\n2. Secondary Seeker connects to the headset (within 10 seconds).\n3. Secondary Seeker sends switching back request to the headset.\n\nWithin 15 seconds, the following should occur:\n\n- Primary Seeker connects back to the headset.\n- Secondary Seeker disconnects from the headset.\n\n| **Note:** You don't need to upload the Secondary Seeker's test results. Ensure the Secondary Seeker's screen does not timeout during the test.\n\nThe following shows an example of the Switch-Back test:\n\n\nAudio switch Multi-Point Tests\n------------------------------\n\n### Payload Verification (Multi-Point)\n\n| **Important:** Before starting the test, ensure that the Provider is not connected to any Seeker. Note: each step has a 10-second timeout.\n\nThe Payload Verification sequence is as follows:\n\n1. Connect to the headset.\n2. Verify that the first byte of the account key is 0x06, as [required by the specification](/nearby/fast-pair/specifications/extensions/sass#SassInUseAccountKey \"Link to the in-use Account Key section.\").\n3. Disconnect from device.\n4. Verify that the first byte of the account key is 0x05, as [required by the specification](/nearby/fast-pair/specifications/extensions/sass#SassInUseAccountKey \"Link to the in-use Account Key section.\").\n5. Re-connect to headset.\n6. Play music.\n7. Verify the connection state is one of the following:\n 1. 0x4: A2DP streaming only.\n 2. 0x5: A2DP streaming with AVRCP.\n8. Start a SCO connection.\n9. Verify the SCO connected succeeded.\n10. Verify the connection state is:\n 1. 0x6: HFP (phone/voip call) streaming, including inband and non-inband ringtone.\n\n### Message Stream (Multi-Point)\n\nThis test requires a Primary and Secondary Seeker. Tests with the\n[multipoint configurability flag](/nearby/fast-pair/specifications/extensions/sass#SassCapabilityFlags \"Link to the Multipoint Capability Flags requirement page.\") set `TRUE` will have\nadditional steps to test this state through the message stream command.\n\nAn example of a Non-configurable Message Stream test (Multi-point):\n\nAn example of a Configurable Message Stream test (Multi-point):\n\n### Switch Back (Multi-Point)\n\nThis test requires a Primary and Secondary Seeker. This test is nearly identical\nto the [single-point version](/nearby/fast-pair/validator-app-guide#switch_back_single-point \"Link to the single-point version section.\"). The only difference is: since\nthe Provider supports multiple connections, when Secondary Seeker connects to\nthe Provider, the Primary Seeker will still connect to the Provider.\n\nAn example of the Multi-point Switch-Back test:\n\n### Switch Active (Multi-Point Only)\n\nThis test requires a Primary and Secondary Seeker.\n\nThis test only verifies that the Provider sends the expected messages using the\nmessage stream channel.\n\nTest steps:\n\n1. The Primary Seeker connects to the Provider\n2. The Primary Seeker checks the capability of the Provider.\n 1. If Multi-Point is off AND Multi-Point Configurable is `TRUE` it will try to enable Multi-Point.\n3. The Primary Seeker will invoke [Switch active audio source (to connected device)](/nearby/fast-pair/specifications/extensions/sass#SwitchActiveAudioSource \"Link to the Switch Active Audio Source section.\") (0x30) to self.\n4. The Secondary Seeker connects to the Provider.\n5. The Primary Seeker will invoke [Switch active audio source (to connected device)](/nearby/fast-pair/specifications/extensions/sass#SwitchActiveAudioSource \"Link to the Switch Active Audio Source section.\") (0x30) to another device.\n6. The Provider will ACK the Primary Seeker.\n7. The Secondary Seeker will receive [Notify multipoint-switch event](/nearby/fast-pair/specifications/extensions/sass#NotifyMultipointSwitchEvent \"Link to the Notify Multipoint Switch Event section.\") (0x32) with the active state.\n\nAn example of the Switch Active (Multi-point Only) test:\n\nHow to Upload Results to the Device Console\n-------------------------------------------\n\n### How to Submit Your Results\n\nThe \"SUBMIT RESULT' button will present a summary of the test results but does\nnot actually submit the results to Google.\n\nAfter reviewing all results, press the 'SUBMIT' button at the bottom of the\nresults page to submit results to Google.\n\nViewing Uploaded Results in the Device Console\n----------------------------------------------\n\nSubmitted test results can be found on the [Nearby Console](/nearby/devices \"Link to the Nearby console.\").\n(Distance Metrics \\& Duration Metrics will be removed for Audio switch test\ncases). For example:\n\nTroubleshooting\n---------------\n\nTry toggling Bluetooth off and on if all your tests failed.\n\n### Switch-Back Test\n\nIf your Switch-Back test failed and is stuck like shown in fig1: Try going\nback to the Test-device page (fig2) and retesting:"]]