ファスト ペアリングの資料と技術ノート

このページでは、パートナーがファスト ペアリング プロジェクトの計画とシステム統合の両方で必要とする有用な情報について説明します。

ファスト ペアリングの素材とプロセス

このセクションでは、一般的なマーケティングとプロセスに関する情報へのリンクを提供します。

マーケティング、ブランディング、メッセージング

ブランディングとメッセージングに関するガイダンスについては、パートナー マーケティング ハブをご覧ください。新規パートナーはアクセスを申請する必要があります。既存のパートナーは、パートナー ドメイン アカウントからコンテンツにアクセスできます。

ファスト ペアリング プロジェクトのライフサイクル

ファスト ペアリングを製品に統合するパートナーのプロジェクト ライフサイクルと責任の概要については、システム インテグレーター（SI）の役割と責任のページをご覧ください。

認定プロセス

ファスト ペアリングを実装するデバイスは、この機能を搭載した製品を販売する前に認定を受ける必要があります。ファスト ペアリング認定ガイドラインでは、認定の準備方法と、認定前のセルフテストの実施方法について説明しています。

認定資格に関するよくある質問では、完全な認定（または再認定）が必要になる場合の一般的な説明など、さまざまなよくある質問について説明しています。

音声の切り替えなどのファスト ペアリング拡張機能を実装または使用するデバイスも、認定を受ける必要があります。音声切り替えには、セルフテストの手順とサードパーティ ラボ認定の準備について説明した別の認定ガイドラインがあります。

サードパーティ ラボは、ファスト ペアリングと音声の切り替えを順番に認定できます。どのラボがどの認定サービスを提供しているかについては、サードパーティ ラボへのデバイスの配送ページをご覧ください。

技術ノート

このセクションでは、パートナーの開発と統合を支援するための技術的な実装に関する注意事項について説明します。

ファスト ペアリングと同時に他のプロトコルをアドバタイズする方法

デバイスによっては、ファスト ペアリングに加えて、Google アシスタントや Eddystone などの追加機能をサポートするために、追加のアドバタイズ スペースが必要になる場合があります。このような場合は、アドバタイズ データをローテーションするのが最適なオプションです。ただし、ファスト ペアリングのアドバタイズは、検出可能モードと検出不可モードに従って、アドバタイズ間隔内でアドバタイズする必要があります。

広告のローテーションは、認定プロセスの第三者テストフェーズでテストされます。認証の遅延、再テスト、費用の発生を避けるため、認証前に必ず ファスト ペアリング Validator アプリでローテーション スキームを検証してください。

BLE 接続間隔を短縮する

GATT 接続のパフォーマンスを向上させるため、プロバイダは接続間隔をできるだけ短くする必要があります。想定される最適な値は 7.5 ミリ秒で、ほとんどのシーカーに適用されます。

BLE アドバタイズとヘッドセットの接続状態

ファスト ペアリング ヘッドセットがモデル ID またはアカウント データをアドバタイズするかどうかは、接続状態ではなく、ヘッドセットの BR/EDR 検出可能モードによって異なります。以下のリンクから、ファスト ペアリング サービスの仕様を参照してください。

• 「プロバイダー デバイスが BR/EDR 検出可能（つまり、ペア設定モード）な場合、BLE 経由でファスト ペアリング モデル ID データをアドバタイズする必要があります。」- リンク
• 「検出可能でない（ペア設定モードでない）場合、プロバイダはファスト ペアリングのアカウント データをアドバタイズする必要があります」- リンク

TxPower

仕様で定義されているように、シーカーは、指定された TxPower レベルに基づいて RSSI で距離を推定します。推定距離は、通知を表示するかどうかを判断する重要な要素です。

TxPower を決定するプロセスは次のとおりです。

1. 1 メートル離れた Android スマートフォンを使用してデバイスの実際の出力を測定し、それに 41 dBm を加えます。
2. この値を BLE アドバタイズに含めます。
3. この値は、セルフテスト レポートのテスト用スマートフォンの情報に含めます。

注: Device Console に保存されている TxPower 値を使用すると、パートナーは出荷済みデバイスの TxPower 値を更新できます。Device Console に TxPower 値を送信する必要はありません。Device Console の値は、すべてのデバイスの TxPower 設定をオーバーライドします。

Validator アプリで TxPower を測定して設定する

Validator アプリには、テスト用スマートフォンで TxPower を適切なレベルに手動で調整するためのテストが用意されています。パートナーは、このテストを使用して、セルフテストまたは認定の前に DUT の適切な TxPower レベルを判断できます。

注: テストが完了したら、DUT とデバイス コンソールで TxPower レベルを設定してください。

TxPower の測定手順

Validator アプリで TxPower を測定するには:

1. テスト用スマートフォンで Validator アプリを開きます。
2. アプリの上部にあるその他メニューを開きます。

   

3. DUT をスマートフォンから 1 メートル離して置き、[START] ボタンをタップします。

   

4. デバイスリストから DUT を選択します。

   

   1. デバイスリストを更新するには、[CANCEL] ボタンをタップして [START] ボタンを再度選択します。
5. 赤色の線（TxPower を表す）が黄色の領域の上部にわずかに触れるまで調整します。

   

   1. [-1] ボタンを使用して、赤い線を黄色い領域に移動します。
   2. 「+1」ボタンを使用して、赤色の線を黄色の領域から遠ざけます。
   3. 信号干渉により、赤い線が不安定になることがあります。赤色の線が不規則に動く場合は、電波干渉の少ない場所に移動してみてください。
6. TxPower の値を保存し、DUT とデバイス コンソールの両方で更新します。

   

バッテリーに関する通知

仕様で定義されているように、プロバイダはアドバタイズにバッテリー情報を含めることができます。シーカーは、タイプに応じてバッテリー通知を表示するか非表示にするかを決定します。バッテリー通知を表示する場合は 0b0011、非表示にする場合は 0b0100 です。広告にバッテリー情報を含めるタイミングと、使用するタイプに関するガイドラインは次のとおりです。

1. ケースが開いていて、両方のイヤホンがドッキングされている場合は、バッテリー通知 0b0011 を表示して、アドバタイズにバッテリー情報を含めます（少なくとも 8 秒間）。
2. ケースが閉じられ、両方のイヤホンがドッキングされているときに、バッテリー通知を非表示にする 0b0100 を 5 秒以上使用して、広告にバッテリー情報を含めます。
3. バッテリー通知の表示 / 非表示を迅速に切り替えるには、アドバタイズが 2 秒以内に実際の状態を反映する必要があります。
4. バッテリー通知を非表示にする方法は 2 つあります。
   1. アドバタイズにバッテリー情報を含めるのを停止すると、シーカーはしばらくしてから通知を非表示にします（現在は 20 秒に設定されています）。
   2. バッテリー通知を非表示にする 0b0100 を使用して、アドバタイズにバッテリー情報を含めます。シーカーは、アドバタイズを取得するとすぐに通知を非表示にします。
5. ケースの開閉時に 1 つのイヤホンのみがドッキングされている場合、アドバタイズにバッテリー情報を含めるかどうかは任意です。
6. イヤホンがケースから取り外されたとき、またはケースにドッキングされたときに、アドバタイズにバッテリー情報を含めるかどうかは任意です。
7. トラッキングを防ぐため、プロバイダは、必要な場合にのみ（常にではなく）アドバタイズに未加工のバッテリー データを含める必要があります。

実装は、認証のセルフテスト結果に記載する必要があります。

ファスト ペアリングのロギングを有効にする方法

デバッグの前に、デバイスで Bluetooth HCI スヌープログが有効になっていることを確認します。また、セキュリティ上の理由から、重要なファスト ペアリング ログが削除されないように、テスト用の Google アカウントでファスト ペアリング パートナー テスト Google グループ（[e-mail]）に参加してください。

デバッグログでファスト ペアリング メッセージをキャプチャするには、次のコマンドを実行します。

$ adb logcat -G 16M
$ adb shell setprop log.tag.NearbyMessages VERBOSE
$ adb shell setprop log.tag.NearbyDiscovery VERBOSE
$ adb shell setprop log.tag.FastPair VERBOSE

Google では、ブート シーケンスごとに上記のコマンドを実行することをおすすめします。

注: VERBOSE ログは、製品版ビルドでは削除される可能性があります。

デバッグログを抽出する方法

$ adb bugreport を実行して、すべてのデータを含む ZIP ファイルを生成します。ZIP ファイルのファイル生成には数分かかることがあります。

Android のバージョンに応じて、次のいずれかのコマンドを実行して btsnoop_hic.log を取得します。

• Android 8.x 以降の場合: shell $ adb pull data/misc/bluetooth/logs logs
• Android 7.x の場合: shell $ adb pull sdcard/btsnoop_hci.log

注: バグレポートの ZIP ファイルをダウンロードする前に、スマートフォンを Bluetooth デバイスの近くに数分間置いておくことをおすすめします。