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

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

テスト

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

単体テスト

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

Wi-Fi Manager のテスト:

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

    % ./frameworks/base/wifi/tests/runtest.sh
        

Wi-Fi Service のテスト:

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

    % ./frameworks/opt/net/wifi/tests/wifitests/runtest.sh
        

Android Comms Test Suite

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

Wi-Fi の ACTS テストは tools/test/connectivity/acts/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/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 フレームワークは、デバイスがネットワークにアソシエートまたはアソシエーション解除する電波強度を制御するために、enty と 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