How to Inspect Active Debugging Connections and Wireless ADB Sessions on Android Using ADB dumpsys adb

The Android Debug Bridge (ADB) is the foundational developer interface for communicating with physical Android devices, emulators, and development boards. Historically, ADB operations were managed by a monolithic background daemon (adbd) communicating over physical USB connections or insecure unauthenticated TCP ports. In modern Android releases (Android 11 and newer), Google refactored the debugging architecture to support native Wireless Debugging, TLS-based mutual authentication, dynamic port pairing, and fine-grained connection controls managed by a dedicated system service.

When auditing mobile device security in enterprise environments, troubleshooting intermittent Wireless ADB disconnects, or verifying authorized development workstations, security teams and developers can inspect internal debugging state using ADB via dumpsys adb. This command exposes active transport connections, authorized RSA public key fingerprints, pairing server status, and TLS connection handshakes.

Architecture of Modern Android Debugging

The Android debugging architecture consists of two cooperative layers: the user-space daemon adbd running natively on the device, and the framework-level system service AdbService managed by system_server. Modern enhancements include:

• Wireless Debugging via TLS: Instead of opening an unencrypted TCP port on port 5555, Android uses TLS encryption with dynamically generated certificates to secure wireless debugging traffic against network eavesdropping.
• Wi-Fi Pairing via mDNS: Devices advertise their pairing port using multicast DNS (mDNS). Workstations pair using a one-time 6-digit numeric pairing code or QR code exchanged over a secure TLS channel.
• Key Authorization Persistence: Public RSA keys from authorized computers are stored securely in /data/misc/adb/adb_keys, protected by hardware keystore backing on supported hardware.
• Automated Revocation: Android automatically revokes authorizations for development computers that have not connected to the device within a configurable timeout period (defaulting to 7 days).

Inspecting ADB Service State with dumpsys

To inspect the current status of ADB connections, connect your device to an authorized computer and execute dumpsys adb via the command line:

# Inspect the ADB system service status
adb shell dumpsys adb

The output presents a comprehensive breakdown of active transports, pairing state, and security configurations:

ADB MANAGER STATE (dumpsys adb):
  Adb Enabled: true
  Adb Wireless Enabled: true
  Adb Wifi Port: 38451
  Adb Pairing Port: 42109
  Connected transports:
    [USB] serial: 98451FFA0201 transport_id: 1 auth_state: AUTHENTICATED
    [WIFI] ip: 192.168.1.145:38451 transport_id: 2 auth_state: AUTHENTICATED

This output reveals the dynamic port assigned for the wireless connection (Adb Wifi Port), the current pairing listening port (Adb Pairing Port), and whether connected clients are properly authenticated.

Auditing Authorized Workstation Keys

To verify which computers currently have permission to access your device via USB or Wireless ADB, inspect the authorized keys list in the dumpsys output:

# Query authorized ADB RSA key fingerprints
adb shell dumpsys adb | grep -A 10 "User Keys:"

The terminal lists the SHA-256 fingerprints of every authorized computer’s ADB public key, alongside the hostname and username of the developer workstation:

User Keys:
  Fingerprint: 4a:2b:8c:91:de:10:fa:44:bc:55:66:77:88:99:aa:bb
  Key info: [email protected]
  Last connection time: 2026-11-08 07:12:00
  Fingerprint: 11:22:33:44:55:66:77:88:99:00:aa:bb:cc:dd:ee:ff
  Key info: [email protected]

If you identify an unknown key fingerprint or a decommissioned workstation, you can revoke all authorizations immediately from Developer Options on the device by selecting Revoke USB debugging authorizations.

Verifying Wireless Debugging and TLS Handshakes

When connecting over Wi-Fi, connection failures often stem from mDNS resolution failures or TLS certificate mismatches. You can check the active TLS state and pairing server status:

# Check pairing and TLS authentication logs
adb shell dumpsys adb | grep -A 8 "TLS State:"

The service displays whether the pairing server is actively accepting connections:

TLS State:
  Pairing server active: false
  Adbd TLS enabled: true
  Active sessions: 1
  Handshake protocol: TLSv1.3
  Cipher suite: TLS_AES_128_GCM_SHA256

If Pairing server active is false, you must open Settings > Developer Options > Wireless Debugging > Pair device with pairing code to temporarily enable the pairing server on the displayed dynamic port.

Troubleshooting Stale ADB Transports

Occasionally, an ADB connection drops but the internal daemon continues holding a stale transport handle, preventing successful re-connections. You can safely restart the on-device debugging daemon directly via ADB:

# Terminate the adbd process to force a clean service restart
adb shell setprop ctl.restart adbd

The device terminates the adbd process, which init automatically respawns within seconds. After restarting, re-run adb shell dumpsys adb to confirm that fresh, clean transport channels have been initialized.