Testen, Debuggen und Optimieren von WLAN

Auf dieser Seite wird beschrieben, wie Sie die Wi-Fi-Implementierung mithilfe der in AOSP bereitgestellten Tools testen, debuggen und optimieren.

Testen

Um das Wi-Fi-Framework zu testen, bietet AOSP eine Mischung aus Unit-Tests, Integrationstests (ACTS) und CTS-Tests.

Unit-Tests

AOSP umfasst Funktions- und Komponententests für das Standard-Wi-Fi-Framework: sowohl für den Wi-Fi Manager (App-seitiger Code) als auch für den Wi-Fi-Dienst.

Wi-Fi Manager-Tests:

• Befindet sich in packages/modules/Wifi/framework/tests/

• Führen Sie es mit der folgenden ausführbaren Shell-Datei aus (lesen Sie die Datei für weitere Ausführungsoptionen):

  atest FrameworksWifiApiTests
  

Wi-Fi-Diensttests:

• Befindet sich in packages/modules/Wifi/service/tests/wifitests/

• Führen Sie es mit der folgenden ausführbaren Shell-Datei aus (lesen Sie die Datei für weitere Ausführungsoptionen):

  atest FrameworksWifiTests
  

Testsuite für Android-Kommunikation

Die Android Comms Test Suite (ACTS) führt automatisierte Tests von Konnektivitätsstacks wie WLAN, Bluetooth und Mobilfunkdiensten durch. Das Testtool erfordert adb und Python und ist unter tools/test/connectivity/acts zu finden.

Die ACTS-Tests für WLAN finden Sie unter tools/test/connectivity/acts_tests/tests/google/wifi , mit einer Beispieltestkonfiguration im selben Verzeichnis: example_config.json .

CTS-Tests

Die Compatibility Test Suite (CTS) umfasst Tests für das Wi-Fi-Framework. Diese befinden sich in cts/tests/tests/net/src/android/net/wifi . Für die Wi-Fi-CTS-Tests ist es erforderlich, dass das zu testende Gerät zu Beginn des Testlaufs einem Access Point zugeordnet wird.

Erweiterte Protokollierungsoptionen zum Debuggen

Android 9 hat die WLAN-Protokollierung verbessert, um die Fehlerbehebung bei WLAN-Problemen zu erleichtern. In Android 9 oder höher können Treiber-/Firmware-Ringpuffer immer aktiviert sein. Fehlerberichte können automatisch ausgelöst werden, wenn ein fehlerhafter Zustand erkannt wird (nur in Userdebug- und Eng-Builds). Wenn Wi-Fi HAL (AIDL oder HIDL Version 1.2 oder höher) verwendet wird, werden Firmware-Debug-Puffer im HAL statt im Framework gespeichert, um IPC-Kosten zu sparen.

Implementierung

Eine Referenzimplementierung finden Sie in der Standardimplementierung im HAL des Anbieters.

Sie können die Firmware-Protokollierung deaktivieren, indem Sie die Ressource config_wifi_enable_wifi_firmware_debugging auf false setzen.

Integrationstest (ACTS)

Den Integrationstest finden Sie unter /tools/test/connectivity/acts_tests/tests/google/wifi/WifiDiagnosticsTest.py .

Verifizierte Firmware-Dumps werden für Userdebug-Builds im entsprechenden Tombstone-Verzeichnis im Flash gespeichert. Dumpstate sammelt Daten aus diesem Verzeichnis, wenn ein Fehlerbericht erstellt wird.

Manueller Test

Führen Sie diesen manuellen Test aus, um zu überprüfen, ob alte Dateien im Tombstone-Verzeichnis gelöscht werden.

1. Schalten Sie WLAN ein.
2. Mit einem Netzwerk verbinden.
3. Erstellen Sie einen Fehlerbericht .

4. Überprüfen Sie die Zip-Datei des Fehlerberichts und stellen Sie sicher, dass die archivierten Firmware-Protokolle vorhanden sind. Die Protokolle befinden sich an folgenden Orten:

   • AIDL HAL: dumpsys Abschnitt der Haupt-Bugreport-Datei
   • HIDL HAL: /lshal-debug/android.hardware.wifi@1.x::IWifi_default.txt

Konfigurationsoptimierung

Um die Signalstärke zu steuern, mit der sich ein Gerät mit einem Netzwerk verbindet oder die Verbindung trennt, verwendet das Wi-Fi-Framework die Eingangs- und Ausgangs -RSSI-Schwellenwerte.

Die Eintritts- und Austrittsschwellenwerte werden als überladbare Konfigurationsparameter mit den folgenden Namen gespeichert (wobei sich der bad Parameter auf den Austritts -RSSI-Schwellenwert bezieht):

• 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

Die Parameter werden in <root>/frameworks/base/core/res/res/values/config.xml gespeichert und können mithilfe der Overlay-Datei <root>/device/<dev_dir>/overlay/frameworks/base/core/res/res/values/config.xml überladen werden. <root>/device/<dev_dir>/overlay/frameworks/base/core/res/res/values/config.xml .

Hinweis: Die bad Konfigurationsparameter (für 2,4-GHz- und 5-GHz-Bänder) wurden vor Android 8.1 eingeführt. Die entry wurden in Android 8.1 eingeführt, wobei die Standardwerte den entsprechenden fehlerhaften Parametern entsprechen. Diese Standardeinstellungen führen zu einem Verhalten vor Android 8.1, bei dem bei der Netzwerkauswahl keine Hysterese verwendet wird. Um die in Android 8.1 eingeführte Hysteresefunktion zu nutzen, stellen Sie die entry mithilfe der oben angegebenen Overlay-Datei auf 3 dB oder mehr über den bad Parametern ein.

Sie können neue Schwellenwerte testen, indem Sie das Gerät mithilfe von ADB-Befehlen konfigurieren. (Alternativ können Sie einen Build mit neuen Overlays erstellen, aber die Verwendung von ADB-Befehlen sorgt für eine schnellere Testdurchlaufzeit.)

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

Mit dem folgenden Befehl werden beispielsweise neue Schwellenwertparameter konfiguriert (die in diesem Beispielbefehl verwendeten Werte sind die konfigurierten Standardwerte in der AOSP-Codebasis):

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

Um die integrierten Parameterwerte wiederherzustellen (d. h. die Überschreibungen zu entfernen), verwenden Sie den folgenden adb-Befehl:

adb shell settings delete global wifi_score_params