The Wi-Fi Aware feature added in Android 8.0 enables supporting devices to discover, connect, and range (added in Android 9) to one another directly using the Wi-Fi Aware protocol without internet or cellular network access. This feature, built upon the Wi-Fi Alliance (WFA) Wi-Fi Aware specification (versions 2.0, 3.0, 3.1 and 4.0), allows easy sharing of high-throughput data among trusted devices and apps that are otherwise off-network.
Examples and source
To use this feature, device manufacturers should implement the Wi-Fi Vendor HAL. In Android 14 and higher, the Vendor HAL interface is defined using AIDL. For Android 13 and lower, the Vendor HAL interface is defined using HIDL.
Follow the Wi-Fi interface to employ the Wi-Fi Aware feature. Depending on which interface is implemented, this is either:
You can refer to the legacy Wi-Fi HAL to see how it correlates with the AIDL and HIDL interfaces: hardware/libhardware_legacy/+/main/include/hardware_legacy/wifi_nan.h.
Device manufacturers need to provide both framework and HAL/firmware support:
- AOSP code
- Enable Aware: Requires both a feature flag and a build flag
- Wi-Fi Aware (NAN) HAL support (which implies firmware support)
To implement this feature, device manufacturers implement the Wi-Fi interface and enable two feature flags:
device/<oem>/<device>, add the following flag:
WIFI_HIDL_FEATURE_AWARE := true
device/<oem>/<device>, modify the
PRODUCT_COPY_FILESenvironment variable to include support for the Wi-Fi Aware feature:
PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.wifi.aware.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.aware.xml
Wi-Fi Aware includes ranging to peer devices using the IEEE 802.11mc protocol, also known as Round Trip Time (RTT). This sub-feature of Wi-Fi Aware is conditional on the device supporting the Wi-Fi RTT feature, that is, it requires the device to support both Wi-Fi Aware and Wi-Fi RTT. For more details, see Wi-Fi RTT.
Otherwise, everything required for this feature is included in AOSP.
WIFI_HIDL_FEATURE_AWARE flag is ignored if the
flag is specified. For more information, see
Wi-Fi multi-interface concurrency.
Android requires the MAC address of the Wi-Fi Aware discovery (NMI) and data interfaces (NDPs) to be randomized and not be identical to the true MAC address of the device. The MAC addresses must be:
- Randomized whenever Wi-Fi Aware is enabled or re-enabled.
When Wi-Fi Aware is enabled, the MAC address must be randomized at a regular interval configured by the
NanConfigRequest.macAddressRandomizationIntervalSecparameter. This is configured by the framework by default to be 30 minutes.
Suspend and resume
In Android 14 and higher, Wi-Fi Aware supports the ability for privileged apps to suspend and resume active discovery sessions (including all data paths associated with those sessions). Supporting this ability lets devices resume discovery sessions faster and use less power because discovery sessions can be suspended.
If a device supports this suspend and resume ability, the firmware suspends the Wi-Fi Aware session when a privileged app suspends the discovery session. When a discovery session is in a suspended state, the device doesn't transmit or receive any frames for that session including any active NDPs in that session. If all discovery sessions are suspended, the device doesn't transmit or receive any Wi-Fi Aware frames.
When a privileged app resumes a suspended discovery session, the framework returns the session to its previous state, including all associated NDP sessions. Resuming a suspended discovery session is faster than bringing up Wi-Fi Aware and creating a new discovery session.
To support the ability to suspend and resume discovery sessions, device
manufacturers must provide HAL and firmware support. For details, see
Device manufacturers can use out-of-band communications (for example, BLE) to synchronize suspend and resume on multiple devices.
Android provides a set of unit tests, integration tests (ACTS), Compatibility Test Suite (CTS) tests, and CTS Verifier tests to validate the Wi-Fi Aware feature. Wi-Fi Aware can also be tested using the Vendor Test Suite (VTS).
The Wi-Fi Aware package tests are executed using:
Integration tests (ACTS)
acts/sl4a test suite, described in
functional, performance, and stress tests.
Compatibility Test Suite (CTS) tests
Use CTS tests to validate the Wi-Fi Aware feature. CTS detects when the feature is enabled and automatically includes the associated tests.
The CTS tests can be triggered using:
CTS Verifier tests
CTS Verifier tests validate Wi-Fi Aware behavior using two devices: a test device and a known good device. To run the tests, open CTS Verifier and navigate to the section titled Wi-Fi Aware Tests.