Wi-Fi のテスト、デバッグ、チューニング

このページでは、AOSP で提供されているツールを使用して Wi-Fi の実装をテスト、デバッグ、チューニングする方法について説明します。

テスト

Wi-Fi フレームワークをテストするために、AOSP には単体テスト、統合テスト(ACTS)、CTS テストがあります。

単体テスト

AOSP には、デフォルトの Wi-Fi フレームワークの機能テストと単体テストが用意されており、Wi-Fi マネージャー(アプリ側のコード)と Wi-Fi Service の両方に対応しています。

Wi-Fi マネージャーのテスト:

  • packages/modules/Wifi/framework/tests/ にあります
  • 次のシェル実行可能ファイルを使用して実行します(ファイルを読んで実行オプションを確認してください)

    atest FrameworksWifiApiTests
    

Wi-Fi Service のテスト:

  • packages/modules/Wifi/service/tests/wifitests/ にあります
  • 次のシェル実行可能ファイルを使用して実行します(ファイルを読んで実行オプションを確認してください)

    atest FrameworksWifiTests
    

Android Comms テストスイート

Android Comms テストスイート(ACTS)では、Wi-Fi、Bluetooth、モバイル通信サービスなどの接続スタックの自動テストを実行できます。テストツールには tools/test/connectivity/acts にある adb と Python が必要です。

Wi-Fi の ACTS テストは tools/test/connectivity/acts_tests/tests/google/wifi にあり、同じディレクトリにはテスト構成のサンプル example_config.json があります。

CTS テスト

互換性検証スイート(Compatibility Test Suite、CTS)には、Wi-Fi フレームワークのテストが用意されています。これらは cts/tests/tests/net/src/android/net/wifi にあります。Wi-Fi CTS テストでは、テスト実行開始時にアクセス ポイントに device-under-test を関連付ける必要があります。

デバッグ用の拡張ロギング オプション

Android 9 では Wi-Fi ロギングが改善されており、Wi-Fi の問題を簡単にデバッグできます。Android 9 以降では、ドライバやファームウェアのリングバッファを常にオンに設定できます。バグレポートは、不正な状態が検出されたときに自動的にトリガーできます(userdebug ビルドと eng ビルドの場合のみ)。Wi-Fi HAL(バージョン 1.2 以降)を使用すると、ファームウェア デバッグ バッファがフレームワークではなく HAL に保存され、IPC コストが節約できます。

実装

参照の実装については、ベンダー HAL のデフォルト実装をご覧ください。

ファームウェア ロギングを無効にするには、リソース config_wifi_enable_wifi_firmware_debugging を false に設定します。

統合テスト(ACTS)

統合テストは /tools/test/connectivity/acts_tests/tests/google/wifi/WifiDiagnosticsTest.py にあります。

検証済みのファームウェア ダンプは、userdebug ビルド用フラッシュの適切な tombstone ディレクトリに保存されます。Dumpstate はバグレポートの作成時にこのディレクトリから収集します。

手動テスト

手動テストを実行して、tombstone ディレクトリの古いファイルが削除されていることを確認します。

  1. Wi-Fi をオンにします。
  2. ネットワークに接続します。
  3. バグレポートを生成します。
  4. bugreport zip ファイルを調べて、/lshal-debug/android.hardware.wifi@1.2__IWifi_default.txt がアーカイブされたファームウェア ログを保持していることを確認します。

構成のチューニング

Wi-Fi フレームワークは、デバイスがネットワークにアソシエートまたはアソシエーション解除する電波強度を制御するために、entry と exit の RSSI しきい値を使用します。

entry と exit のしきい値は、次の名前を持つオーバーロード可能な構成パラメータとして格納されます。その際、bad パラメータは exit の RSSI しきい値を参照します。

  • config_wifi_framework_wifi_score_bad_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_bad_rssi_threshold_24GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_24GHz

パラメータは <root>/frameworks/base/core/res/res/values/config.xml に格納され、オーバーレイ ファイル <root>/device/<dev_dir>/overlay/frameworks/base/core/res/res/values/config.xml を使用してオーバーロードされる可能性があります。

adb コマンドを使用してデバイスを構成すると、新しいしきい値をテストできます。 新しいオーバーレイを使用してビルドを作成することもできますが、adb コマンドを使用するとテストの処理が速くなります。

adb shell settings put global wifi_score_params \
                             [rssi2|rssi5]=<bad>:<entry>:<low>:<good>

たとえば、次のコマンドは新しいしきい値パラメータを構成します(このサンプル コマンドで使用する値は、AOSP コードベースでデフォルト値として構成されています)。

adb shell settings put global wifi_score_params \
                       rssi2=-85:-85:-73:-60,rssi5=-82:-82:-70:-57

組み込みのパラメータ値を復元する(オーバーライドを削除する)には、次の adb コマンドを使用します。

adb shell settings delete global wifi_score_params