Die in Android 8.0 hinzugefügte Wi-Fi Aware-Funktion ermöglicht es unterstützenden Geräten, einander (in Android 9 hinzugefügt) direkt über das Wi-Fi Aware-Protokoll ohne Internet- oder Mobilfunknetz-Zugriff zu erkennen, eine Verbindung zu ihnen herzustellen und sich gegenseitig zu verbinden. Diese Funktion basiert auf der Wi-Fi Aware-Spezifikation der Wi-Fi Alliance (WFA) (Versionen 2.0, 3.0, 3.1 und 4.0). Sie ermöglicht die einfache Freigabe von Daten mit hohem Durchsatz zwischen vertrauenswürdigen Geräten und Apps, die sich ansonsten außerhalb des Netzwerks befinden.
Beispiele und Quelle
Um diese Funktion zu nutzen, sollten Gerätehersteller den WLAN-Anbieter HAL implementieren. Ab Android 14 wird die HAL-Schnittstelle des Anbieters mithilfe von AIDL definiert. Unter Android 13 und niedriger wird die HAL-Schnittstelle des Anbieters mithilfe von HIDL definiert.
Folgen Sie der WLAN-Benutzeroberfläche, um die Wi-Fi Aware-Funktion zu verwenden. Je nachdem, welche Schnittstelle implementiert ist, ist dies entweder:
- AIDL:
hardware/interfaces/wifi/aidl - HIDL:
hardware/interfaces/wifi/1.2oder höher
Sie können dem alten Wi-Fi-HAL entnehmen, wie es mit den AIDL- und HIDL-Schnittstellen korreliert: hardware/libhardware_legacy/+/main/include/hardware_legacy/wifi_nan.h.
Implementierung
Gerätehersteller müssen sowohl Framework- als auch HAL-/Firmware-Unterstützung anbieten:
- Framework:
- AOSP-Code
- Aware aktivieren: Erfordert sowohl ein Funktions- als auch ein Build-Flag
- Wi-Fi Aware (NAN) HAL-Unterstützung (was Firmware-Unterstützung impliziert)
Zur Implementierung dieser Funktion implementieren Gerätehersteller die WLAN-Schnittstelle und aktivieren zwei Funktions-Flags:
Fügen Sie in
BoardConfig.mkoderBoardConfig-common.mkindevice/<oem>/<device>das folgende Flag hinzu:WIFI_HIDL_FEATURE_AWARE := trueÄndern Sie in
device.mkindevice/<oem>/<device>die UmgebungsvariablePRODUCT_COPY_FILES, um die Wi-Fi Aware-Funktion zu unterstützen:PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.wifi.aware.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.aware.xml
Mit Wi-Fi Aware können Sie über das IEEE 802.11mc-Protokoll, auch als „Round Trip Time“ (RTT) bezeichnet, eine Verbindung zu Peer-Geräten herstellen. Diese Unterfunktion von Wi-Fi Aware ist auf dem Gerät erforderlich, das die WLAN-RTT-Funktion unterstützt. Das heißt, das Gerät muss sowohl Wi-Fi Aware als auch Wi-Fi RTT unterstützen. Weitere Informationen finden Sie unter WLAN-RTT.
Andernfalls ist alles, was für diese Funktion erforderlich ist, in AOSP enthalten.
Das Flag WIFI_HIDL_FEATURE_AWARE wird ignoriert, wenn das Flag WIFI_HAL_INTERFACE_COMBINATIONS angegeben ist. Weitere Informationen finden Sie unter Gleichzeitigkeit von WLAN-Multi-Schnittstellen.
Randomisierung bei MAC
Bei Android muss die MAC-Adresse der Wi-Fi Aware-Discovery (NMI) und Datenschnittstellen (NDPs) zufällig angeordnet sein und nicht mit der tatsächlichen MAC-Adresse des Geräts identisch sein. Folgende MAC-Adressen sind erforderlich:
- Wird bei der Aktivierung oder erneuten Aktivierung von WLAN Aware zufällig ausgewählt.
Wenn Wi-Fi Aware aktiviert ist, muss die MAC-Adresse in einem regelmäßigen Intervall zufällig angeordnet werden, das über den Parameter
NanConfigRequest.macAddressRandomizationIntervalSeckonfiguriert wird. Dies wird vom Framework standardmäßig auf 30 Minuten konfiguriert.
Sperren und fortsetzen
Ab Android 14 unterstützt Wi-Fi Aware privilegierte Apps, aktive Erkennungssitzungen zu sperren und wieder zu aktivieren (einschließlich aller Datenpfade, die mit diesen Sitzungen verknüpft sind). Dadurch können Geräte Erkennungssitzungen schneller fortsetzen und verbrauchen weniger Energie, da Erkennungssitzungen ausgesetzt werden können.
Wenn ein Gerät diese Funktion zum Sperren und Fortsetzen unterstützt, unterbricht die Firmware die Wi-Fi Aware-Sitzung, wenn eine privilegierte App die Erkennungssitzung sperrt. Wenn eine Erkennungssitzung angehalten ist, sendet oder empfängt das Gerät keine Frames für diese Sitzung, auch keine aktiven NDPs in dieser Sitzung. Wenn alle Erkennungssitzungen ausgesetzt sind, überträgt oder empfängt das Gerät keine Wi-Fi Aware-Frames.
Wenn eine privilegierte App eine gesperrte Erkennungssitzung fortsetzt, setzt das Framework die Sitzung auf den vorherigen Status zurück, einschließlich aller verknüpften NDP-Sitzungen. Das Fortsetzen einer angehaltenen Erkennungssitzung ist schneller als das Aufrufen von Wi-Fi Aware und das Erstellen einer neuen Erkennungssitzung.
Damit Erkennungssitzungen aus- und fortgesetzt werden können, müssen Gerätehersteller HAL- und Firmware-Support anbieten. Weitere Informationen finden Sie unter IWifiNanIface.java.
Gerätehersteller können die Out-of-Band-Kommunikation (z. B. BLE) verwenden, um den Ruhemodus auf mehreren Geräten zu synchronisieren.
Zertifizierungsstufe
Android bietet eine Reihe von Unit-, Integrationstests (ACTS), Kompatibilitätstest-Suite (CTS)- und CTS Verifier-Tests zur Validierung der Wi-Fi Aware-Funktion. Wi‐Fi Aware kann auch mit der Vendor Test Suite (VTS) getestet werden.
Einheitentests
Die Tests des Wi-Fi Aware-Pakets werden folgendermaßen ausgeführt:
Diensttests:
atest com.android.server.wifi.aware
Tests für Manager:
atest android.net.wifi.aware
Integrationstests (ACTS)
Die in tools/test/connectivity/acts_tests/tests/google/wifi/aware/README.md beschriebene acts/sl4a-Testsuite bietet Funktions-, Leistungs- und Stresstests.
CTS-Tests (Compatibility Test Suite)
Prüfen Sie die Wi-Fi Aware-Funktion mithilfe von CTS-Tests. CTS erkennt, wann die Funktion aktiviert ist, und schließt die zugehörigen Tests automatisch ein.
Die CTS-Tests können folgendermaßen ausgelöst werden:
atest SingleDeviceTest
Tests zur CTS-Prüfung
Der CTS Verifier prüft das Wi-Fi Aware-Verhalten mit zwei Geräten: einem Testgerät und einem als gut bekannten Gerät. Öffnen Sie CTS Verifier und gehen Sie zum Abschnitt mit dem Titel „Wi-Fi Aware Tests“, um die Tests auszuführen.