How to Inspect Network Capabilities and Active Default Networks on Android Using ADB dumpsys connectivity

Modern mobile applications operate across diverse and volatile network environments, continuously transitioning between cellular data, Wi-Fi networks, VPN tunnels, and captive portals. When an Android application fails to connect, encounters unexpected metering restrictions, or routes traffic through the wrong network interface, developers must look beyond simple ping tests. The Android connectivity framework manages multi-network routing, validation states, and socket permissions through the ConnectivityService. The Android Debug Bridge (ADB) dumpsys connectivity command provides deep diagnostic visibility into active transport agents, network capabilities, DNS servers, and network policy restrictions.

Understanding the Android ConnectivityService Architecture

Unlike desktop operating systems that typically bind to a single default gateway, Android maintains multiple concurrent network interfaces. The ConnectivityService daemon running inside system_server continuously evaluates available physical transports (such as TRANSPORT_WIFI, TRANSPORT_CELLULAR, TRANSPORT_ETHERNET, and TRANSPORT_VPN).

Every active network connection is registered as a NetworkAgent and characterized by a bitmask of NetworkCapabilities, including:

• NET_CAPABILITY_INTERNET: The interface can reach public internet IP endpoints.
• NET_CAPABILITY_VALIDATED: Android’s captive portal detector successfully probed Google/carrier endpoints without receiving a redirection page.
• NET_CAPABILITY_NOT_METERED: The network is marked unmetered (such as unconstrained home Wi-Fi), lifting background sync limits.
• NET_CAPABILITY_NOT_VPN: Confirms that traffic on this network does not traverse a virtual private network tunnel.
• NET_CAPABILITY_FOREGROUND: The network currently satisfies an active foreground application request.

The dumpsys connectivity tool outputs the exact runtime state of these capability flags and network scores.

Extracting a Connectivity Diagnostic Dump

Connect your Android device to your computer via USB or Wi-Fi debugging and confirm that USB debugging is authorized:

adb devices

To inspect the connectivity service, execute:

adb shell dumpsys connectivity

Because the connectivity dump logs every network request, legacy interface, and validation transaction, the full report can span several thousand lines. Using targeted search filters allows you to extract specific sections quickly.

Auditing Active Default Networks and Transport Interfaces

To identify which network interface is currently designated as the default outbound pathway for system applications, search the dump for the active network summary:

adb shell dumpsys connectivity | grep -E "Active default network" -A 10

The terminal outputs the active default network record:

Active default network: 104
NetworkAgentInfo{ ni{[type: WIFI[], state: CONNECTED/CONNECTED, reason: (unspecified), extra: "Office-5GHz", failover: false, available: true, roaming: false]}  network{104}  handle{446714574944}  lp{{InterfaceName: wlan0 LinkAddresses: [fe80::1234/64,192.168.1.150/24]  Routes: [fe80::/64 -> :: wlan0, 192.168.1.0/24 -> 0.0.0.0 wlan0, 0.0.0.0/0 -> 192.168.1.1 wlan0] DnsAddresses: [1.1.1.1,8.8.8.8]}}  nc{[ Transports: WIFI Capabilities: NOT_METERED&INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VPN&VALIDATED&NOT_ROAMING&FOREGROUND Specifier: <null> LinkUpBandwidth>=104000Kbps LinkDnBandwidth>=104000Kbps]}  Score{60} }

This single entry provides crucial diagnostic data:

• InterfaceName: Identifies the underlying Linux network device (e.g., wlan0 for Wi-Fi or rmnet_data0 for cellular).
• Capabilities: Confirms that the connection is VALIDATED and NOT_METERED. If VALIDATED is absent, Android treats the connection as degraded and may route app traffic through cellular data instead.
• LinkUpBandwidth / LinkDnBandwidth: Hardware-reported physical bandwidth estimations.
• Score: The integer score used by Android to resolve competing transports (higher scores take precedence).

Inspecting Assigned DNS Servers and Routing Tables

When an application reports DNS resolution failures or timeouts, verify which nameservers the Android system assigned to the active link properties.

Search for link properties within the dump:

adb shell dumpsys connectivity | grep -A 4 "LinkAddresses:"

This displays all active IPv4 and IPv6 addresses, default gateway routes, and active DNS resolvers assigned via DHCP or cellular PDP context. If your device utilizes Private DNS (DNS-over-TLS), the dump confirms whether the TLS handshake succeeded or fell back to cleartext port 53 resolvers.

Auditing Network Requests Registered by Apps

Modern Android applications request specialized networks using the ConnectivityManager.requestNetwork() API. For example, an IoT setup app might request a direct Wi-Fi network without internet connectivity while keeping the cellular default network alive.

To inspect all currently registered network requests across all running applications, execute:

adb shell dumpsys connectivity | grep -A 6 "Network Requests:"

Each request record details the calling application UID, requested capability bitmask, and whether the operating system successfully bound an interface to satisfy the request.

Simulating Captive Portal and Validation Recovery

If a device is connected to Wi-Fi but displays an exclamation mark or reports “No Internet”, the network failed captive portal validation. You can force Android to re-evaluate network validation immediately via ADB:

adb shell cmd connectivity reevaluate 104

(Replace 104 with the network ID reported in your active default network summary). The operating system re-dispatches HTTP probe requests to the captive portal test URLs, refreshing the VALIDATED capability bit upon success.

Using dumpsys connectivity equips developers and network engineers with complete, low-level insight into Android’s multi-network routing engine, ensuring reliable network performance across complex mobile environments.