Wi-Fi Aware

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:

AIDL: hardware/interfaces/wifi/aidl
HIDL: hardware/interfaces/wifi/1.2 or later

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.

Implementation

Device manufacturers need to provide both framework and HAL/firmware support:

Framework:
- 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:

In BoardConfig.mk or BoardConfig-common.mk located in device/<oem>/<device>, add the following flag:
```
WIFI_HIDL_FEATURE_AWARE := true
```

In device.mk located in device/<oem>/<device>, modify the PRODUCT_COPY_FILES environment 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.

The WIFI_HIDL_FEATURE_AWARE flag is ignored if the WIFI_HAL_INTERFACE_COMBINATIONS flag is specified. For more information, see Wi-Fi multi-interface concurrency.

MAC randomization

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.macAddressRandomizationIntervalSec parameter. This is configured by the framework by default to be 30 minutes.

Note: Per the Wi-Fi Aware spec, randomization may be suspended while an NDP is configured. Suspension does not imply that the factory MAC address is used (it must never be used for Wi-Fi Aware), but that the MAC address is re-randomized less frequently than otherwise required.

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 IWifiNanIface.java.

Device manufacturers can use out-of-band communications (for example, BLE) to synchronize suspend and resume on multiple devices.

Validation

Android provides a set of unit tests, 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).

Unit tests

The Wi-Fi Aware package tests are executed using:

Service tests:

atest com.android.server.wifi.aware

Manager tests:

atest android.net.wifi.aware

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:

atest SingleDeviceTest

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.