How to Inspect Wi-Fi Aware Discovery Sessions and Data Paths on Android Using ADB dumpsys wifiaware

Modern wireless mobile applications frequently require peer-to-peer discovery and direct high-throughput local data transfers without relying on an active cellular network, external internet connectivity, or a common Wi-Fi access point. In the Wi-Fi Alliance standard and Android operating system (Android 8.0+), this capability is provided by Wi-Fi Aware—also standardized as Neighbor Awareness Networking (NAN). Wi-Fi Aware allows nearby devices to discover each other, negotiate peer clusters, exchange application service messages, and establish high-speed point-to-point IP data links over synchronized radio discovery windows. To inspect active publish/subscribe discovery sessions, review cluster synchronization states, audit MAC address randomization, and diagnose data-path network interface links, Android exposes the dumpsys wifiaware diagnostic service via ADB.

Understanding Android Wi-Fi Aware Architecture

The Wi-Fi Aware software stack on Android spans multiple hardware and framework tiers:

• Wi-Fi Chipset and Firmware: Hardware supporting the Wi-Fi Alliance NAN specification. It synchronizes radio clocks with nearby peer devices, listening on specific 500ms discovery windows across 2.4 GHz (Channel 6) and 5 GHz (Channel 149) frequencies while keeping radios powered down during idle intervals to maximize battery life.
• Wi-Fi HAL (android.hardware.wifi): Manages low-level firmware messaging, nan-interface creation, and packet routing.
• WifiAwareService: The core Android system server component (com.android.server.wifi.aware.WifiAwareStateManager) managing client session registrations, publish/subscribe matching tables, message routing, and security key exchanges.
• Publish and Subscribe Sessions:
  • Publish Session: An application advertises an available service (e.g., local multi-player gaming, zero-infrastructure file sharing, or sensor streaming).
  • Subscribe Session: An application scans for matching published service strings without broadcasting probe requests.
• Aware Data Path (NAN Data Path / NDP): When two peers decide to communicate directly, Wi-Fi Aware instantiates a dedicated network interface (e.g., aware_data0) with link-local IPv6 addresses and optional pre-shared key (PSK) encryption.

Querying Wi-Fi Aware Telemetry via ADB

To inspect the active state of the Wi-Fi Aware subsystem, connect an Android device with USB debugging enabled and execute:

adb shell dumpsys wifiaware

The command dumps information regarding hardware capabilities, active client apps, discovery sessions, and cluster parameters. A typical output structure includes:

WifiAwareStateManager:
  mCapabilities:
    maxConcurrentAwareDataInterfaces: 2
    maxPublishSessions: 8
    maxSubscribeSessions: 8
    maxServiceNameLen: 255
    maxMatchFilterLen: 255
  Cluster Information:
    Cluster ID: 0x4a12
    Master Preference: 0
    Cluster Role: NON_MASTER_SYNC
    Active Channel: 6 (2437 MHz)
  Clients:
    Client ID: 1, UID: 10214, Package: com.google.android.nearby
      Sessions:
        Session ID: 101, Type: PUBLISH
          Service Name: NearbyShare-Direct
          Match Style: ALL
        Session ID: 102, Type: SUBSCRIBE
          Service Name: NearbyShare-Direct
  Active Data Paths (NDP):
    NDP ID: 42, Interface: aware_data0, State: CONFIRMED
      Peer MAC: 02:1a:2b:3c:4d:5e
      Local MAC: 02:4f:5e:6d:7c:8b
      Channel: 149 (5745 MHz)

Key operational fields include:

• mCapabilities: Hardware limits defined by the device’s wireless chipset (e.g., Qualcomm, Broadcom, or MediaTek), indicating maximum concurrent discovery sessions and data interfaces.
• Cluster Role: The device’s operational role within the local NAN cluster: MASTER (maintaining cluster beacon timing), NON_MASTER_SYNC (synchronized to master beacons), or NON_MASTER_NON_SYNC.
• Session Type and Service Name: Active discovery channels established by foreground or background applications.
• Active Data Paths (NDP): High-throughput point-to-point data connections, displaying assigned dynamic network interfaces, operating frequencies, and temporary randomized MAC addresses.

Auditing Randomized MAC Addresses and Privacy Safeguards

To prevent malicious tracking of user devices via passive radio sniffers, the Wi-Fi Aware specification mandates frequent MAC address rotation. Android generates a temporary, randomized MAC address for NAN management frames and rotates it periodically (or upon every cluster re-synchronization).

In dumpsys wifiaware, inspect the Local MAC and Cluster Information sections to verify that the MAC address used for discovery is randomized (indicated by the locally administered bit set to 2 in the first octet, e.g., 02:...) and distinct from the device’s physical Wi-Fi hardware MAC.

Inspecting Active Aware Network Interfaces via ifconfig and ip

When an active data path (NDP) is negotiated between two devices, Android creates a synthetic network interface named aware_data0 or aware_data1. You can inspect its network configuration and link-local IPv6 routing via ADB:

# Inspect active Aware network interface
adb shell ip addr show aware_data0

# Inspect IPv6 neighbor table
adb shell ip -6 neigh show dev aware_data0

Applications communicate across this interface by binding sockets directly to the peer’s link-local IPv6 address (e.g., fe80::...%aware_data0).

Tracing Discovery and Session Handshakes in Logcat

To monitor real-time service discovery events, message exchanges, and NDP connection setups, filter logcat for Wi-Fi Aware tags:

adb logcat -s WifiAwareService:V WifiAwareHal:V WifiAwareStateManager:V

When two devices discover each other, logcat outputs the service match events:

WifiAwareStateManager: onMatch: discoverySessionId=102, peerId=12, peerMac=02:1a:2b...
WifiAwareStateManager: Service discovery match successful: 'NearbyShare-Direct'
WifiAwareStateManager: Initiating NAN data path setup request to peer 12

By using dumpsys wifiaware alongside ADB network inspection tools, wireless systems engineers, IoT architects, and mobile application developers can verify peer-to-peer discovery protocols, audit MAC privacy controls, and diagnose zero-infrastructure data paths with technical rigor.