音声の切り替え検証ツール ユーザー マニュアル

このページは、オーディオ スイッチ バージョンの検証ツール アプリに固有のものです。LE Audio バージョンの検証ツール アプリについては、LE Audio 検証ツール アプリのページをご覧ください。

セットアップ

Validator アプリでテストを有効にするには:

• デバイスに GmsCore バージョン 22.08.xx 以降が搭載されていることを確認します。
• テスト用メールが Fast Pair パートナー テスト グループに含まれていることを確認します。
  • 新しく登録したメールアドレスとスマートフォンの権限が同期されるまでに、6 ～ 24 時間ほどかかることがあります。
  • 関連付けられた Google アカウントにログインしたりログアウトしたりすると、即時同期がトリガーされることもあります。

例:

必要なデバイス

オーディオ スイッチ テストでは、スマートフォンをファスト ペアリングでペア設定する必要があります。

1. 同じ Google アカウントにログインしている 2 台のスマートフォン（A と B）を用意します。
2. ヘッドセットをスマートフォン A とペア設定します（初回ペア設定）。
3. ペア設定モードに入り、ハーフシート UI の通知が届くまで待ちます。
4. [接続] をクリックします。
5. [完了] をクリックします。
6. ヘッドセットをスマートフォン B とペア設定します（2 回目以降のペア設定）。
   1. 両方のペア設定が完了したことを通知するメッセージが表示されるまで待ちます。
7. システム通知をクリックします。

質問の流れの例を次に示します。

基本的な UI フロー

一般的な UI フローは次のとおりです。

オーディオ スイッチの単一ポイント テスト

オーディオ スイッチ テスト（単一ポイント）

このテストでは、次の関数が実行されます。

• ペイロードの確認。
  • さまざまなシナリオで広告データを検証します。
• メッセージ ストリームの検証。
  • メッセージ ストリームの通信を確認します。
• 元の画面に戻ります。
  • スイッチバックの動作を確認します。

ペイロードの検証（単一ポイント）

ペイロードの検証シーケンスは次のとおりです。

1. ヘッドセットに接続します。
2. 仕様で要求されているように、アカウント キーの最初のバイトが 0x06 であることを確認します。
3. デバイスの接続を解除します。
4. 仕様で要求されているように、アカウント キーの最初のバイトが 0x05 であることを確認します。
5. ヘッドセットに再接続します。
6. 音楽を再生する。
7. 接続状態が次のいずれかであることを確認します。
   1. 0x4: A2DP ストリーミングのみ。
   2. 0x5: AVRCP を使用した A2DP ストリーミング。
8. SCO 接続を開始します。
9. SCO の接続が成功したことを確認します。
10. 接続状態が次の状態であることを確認します。
    1. 0x6: HFP（電話/VoIP 通話）ストリーミング（インバンドとインバンド以外の着信音を含む）。

ペイロード検証の例（単一ポイント）:

メッセージ ストリームの検証（単一ポイント）

メッセージ ストリームの検証シーケンスは次のとおりです。

1. 異なるメッセージ ストリーム接続間のセッション ノンスを検証します。
   1. ヘッドセットに接続します。
   2. ヘッドセットからノンス X を取得します（5 秒以内）。
   3. ヘッドセットに再接続します。
   4. ヘッドセットから別のノンス Y を取得します（5 秒以内）。
   5. X と Y が異なるかどうかを確認します。
2. Get Audio switch Capability リクエストを送信します。
   1. レスポンスが 2 秒以内に送信されたことを確認します。コンテンツはチェックされません。
3. 使用中のアカウント キーを示すリクエストを送信します。
   1. レスポンスが 2 秒以内に送信されたことを確認します。コンテンツはチェックされません。
4. Notify Initiated Connection リクエストを送信します。
   1. レスポンスが 2 秒以内に送信されたことを確認します。コンテンツは確認されません。
5. Send Custom Data リクエストを送信します。
   1. ACK が 2 秒以内に返されることを確認します。
   2. 広告データに設定したカスタムデータが含まれていることを確認します（10 秒）。

メッセージ ストリームの検証の例（単一ポイント）:

スイッチバック（単一ポイント）

このテストでは、プライマリ シーカーとセカンダリ シーカーの 2 台のデバイスが必要です。テストの順序は次のとおりです。

1. プライマリ シーカーがヘッドセットに接続します（10 秒以内）。
2. セカンダリ シーカーがヘッドセットに接続します（10 秒以内）。
3. セカンダリ シーカーがヘッドセットに切り替えリクエストを送信します。

15 秒以内に、次の処理が行われます。

• プライマリ シーカーがヘッドセットに再接続します。
• セカンダリ シーカーがヘッドセットから切断される。

以下に、Switch-Back テストの例を示します。

オーディオ スイッチのマルチポイント テスト

ペイロードの検証（マルチポイント）

ペイロードの検証シーケンスは次のとおりです。

1. ヘッドセットに接続します。
2. 仕様で要求されているように、アカウント キーの最初のバイトが 0x06 であることを確認します。
3. デバイスの接続を解除します。
4. 仕様で要求されているように、アカウント キーの最初のバイトが 0x05 であることを確認します。
5. ヘッドセットに再接続します。
6. 音楽を再生する。
7. 接続状態が次のいずれかであることを確認します。
   1. 0x4: A2DP ストリーミングのみ。
   2. 0x5: AVRCP を使用した A2DP ストリーミング。
8. SCO 接続を開始します。
9. SCO の接続が成功したことを確認します。
10. 接続状態が次の状態であることを確認します。
    1. 0x6: HFP（電話/VoIP 通話）ストリーミング（インバンドとインバンド以外の着信音を含む）。

メッセージ ストリーム（マルチポイント）

このテストには、プライマリ シーカーとセカンダリ シーカーが必要です。マルチポイント構成可能フラグが TRUE に設定されたテストでは、メッセージ ストリーム コマンドを使用してこの状態をテストするための追加の手順があります。

構成不可のメッセージ ストリーム テスト（マルチポイント）の例:

構成可能なメッセージ ストリーム テスト（マルチポイント）の例:

戻る（マルチポイント）

このテストには、プライマリ シーカーとセカンダリ シーカーが必要です。このテストは、単一ポイント バージョンとほぼ同じです。唯一の違いは、プロバイダが複数の接続をサポートしているため、セカンダリ シーカーがプロバイダに接続しても、プライマリ シーカーは引き続きプロバイダに接続することです。

マルチポイント スイッチバック テストの例:

スイッチが有効（マルチポイントのみ）

このテストには、プライマリ シーカーとセカンダリ シーカーが必要です。

このテストでは、Provider がメッセージ ストリーム チャンネルを使用して期待されるメッセージを送信することを確認します。

テスト手順:

1. プライマリ シーカーがプロバイダに接続する
2. プライマリ シーカーは、プロバイダの機能をチェックします。
   1. マルチポイントがオフで、マルチポイントの構成が TRUE の場合、マルチポイントを有効にしようとします。
3. プライマリ シーカーは、自身に対して アクティブなオーディオ ソースを切り替える（接続済みデバイスに）（0x30）を呼び出します。
4. セカンダリ シーカーがプロバイダに接続します。
5. プライマリ シーケンサーは、別のデバイスにアクティブなオーディオ ソースを切り替える（接続済みデバイスに）（0x30）を呼び出します。
6. プロバイダはプライマリ シーカーに ACK を送信します。
7. セカンダリ シーケンサーは、アクティブな状態のマルチポイント スイッチ通知イベント（0x32）を受信します。

スイッチのアクティブ（マルチポイントのみ）テストの例:

デバイス コンソールに結果をアップロードする方法

結果を送信する方法

[結果を送信] ボタンをクリックすると、テスト結果の概要が表示されますが、実際には Google に送信されません。

すべての結果を確認したら、結果ページの下部にある [送信] ボタンをクリックして、結果を Google に送信します。

デバイス コンソールでアップロードされた結果を表示する

送信されたテスト結果は、Nearby Console で確認できます。（オーディオ スイッチのテストケースでは、距離の指標と時間の指標が削除されます）。例:

トラブルシューティング

すべてのテストが失敗した場合は、Bluetooth のオンとオフを切り替えてみてください。

スイッチバック テスト

図 1 のように、Switch-Back テストが失敗して停止している場合: テストデバイスのページ（図 2）に戻って、再度テストしてみてください。