Capture and Analyze Android Network Logs with ADB

Why you might need a NetLog

When an app or a system service cannot reach the internet, the usual suspects—Wi‑Fi signal, carrier data, or a mis‑behaving VPN—are easy to check. However, many connectivity problems stem from DNS failures, TCP retransmissions, or malformed packets that are invisible in the standard Settings > Network diagnostics screen. Android’s NetLog feature records low‑level network events (socket creation, DNS queries, TCP state changes, etc.) in a binary file that can be inspected with Android Studio’s Network Profiler or third‑party parsers. By capturing a NetLog you get a timeline of exactly what the OS tried to do, which often reveals the root cause of “Why can’t I load this page?” or “Why does my app keep timing out?”

Before you start

• Computer with ADB installed – The Android SDK Platform‑Tools package provides the adb binary. It works on Windows, macOS, and Linux.
• USB cable (or Wi‑Fi ADB) – A reliable connection prevents intermittent data loss during the capture.
• Device charge ≥ 50 % – NetLog can generate several megabytes of data quickly.
• Free storage on the device – Allocate at least 50 MB in /sdcard/ for the log file.
• Optional: Android Studio – The built‑in Network Profiler makes visual analysis easier, but you can also use the free netlog2json script.

If any of these items are missing, pause and acquire them now. Skipping a prerequisite often leads to incomplete logs or a failed capture.

Step 1 – Enable Developer Options and USB Debugging

Why this matters: ADB communicates with the device through a debugging bridge. Without USB debugging, adb cannot issue the netlog command.

Step 2 – Grant the NetLog permission (Android 10+)

Starting with Android 10, NetLog is considered a privileged operation. The system will prompt the user to allow “Network logging” the first time you run the command. You must confirm this dialog; otherwise the command silently fails.

After the permission is granted once, Android remembers it for the lifetime of the user profile, so you won’t be asked again for subsequent captures.

Step 3 – Choose a destination path for the log file

NetLog writes a binary .bin file to the location you specify. It’s best to store it on the primary external storage (/sdcard/) because pulling files from there is straightforward.

Step 4 – Start the NetLog capture

Why you stop manually: NetLog does not have a built‑in timeout; leaving it running can quickly fill the storage and degrade performance.

Step 5 – Pull the log file to your computer

Step 6 – Convert the binary NetLog to a readable format

Android Studio can open the binary directly, but many users prefer a JSON view. The Android Open Source Project provides a small Python script called netlog_to_json.py. Below is a quick way to use it without installing the full Android source.

If you prefer a graphical view, skip the conversion and open the .bin directly in Android Studio’s Profiler → Network panel. Choose “Import…”, select the file, and the timeline appears.

Step 7 – Analyze the data

Below are common patterns to look for. Use the JSON viewer of your choice (VS Code, jq, or a web‑based formatter) and search for the fields that match the symptom you’re investigating.

7.1 DNS failures

• Event type: DnsLookupStart followed quickly by DnsLookupFailed.
• Check the hostname field – if it’s your app’s API endpoint, the DNS server may be unreachable.
• Resolution: Verify the device’s DNS settings (Settings → Network → Private DNS) or try a public resolver like 1.1.1.1.

7.2 TCP retransmissions

• Look for repeated TcpSend events with the same seq number.
• High retransmission counts often indicate a weak Wi‑Fi signal or a mis‑behaving firewall.
• Resolution: Move closer to the router, disable aggressive power‑saving Wi‑Fi modes, or test on mobile data.

7.3 TLS handshake errors

• Events: TlsHandshakeStart → TlsHandshakeFailed.
• The error_code field may read SSL_ERROR_BAD_CERTIFICATE or SSL_ERROR_HANDSHAKE_FAILURE.
• Resolution: Check the device date/time (TLS is time‑sensitive) and ensure the server’s certificate chain is trusted.

7.4 Unexpected network interface switches

• Event: NetworkChange indicating a switch from WIFI to MOBILE or vice‑versa.
• If the switch happens mid‑request, the app may see a “connection reset”.
• Resolution: Disable “Smart network switch” or set the app’s android:usesCleartextTraffic flag appropriately.

These examples cover the majority of connectivity complaints. The full NetLog contains many more event types; the AOSP documentation lists them if you need deeper digging.

Alternative ways to view NetLog

• Chrome DevTools – Open chrome://inspect, select the device, and use the “Network” tab to import the .bin file.
• Wireshark – Convert the NetLog to PCAP using the netlog2pcap utility (available in the Android SDK’s platform-tools folder). Then open the PCAP in Wireshark for packet‑level analysis.
• Third‑party apps – Some Play Store utilities (e.g., “NetLog Viewer”) can read the binary directly without a PC.

Troubleshooting common problems

Problem 1 – “netlog: command not found”

Older Android versions (pre‑Android 10) do not ship the netlog binary. In that case you can fall back to adb shell logcat -b all -s ConnectivityService which records similar information in plain text, albeit without the detailed socket timeline.

Problem 2 – Log file is empty or only a few kilobytes

• Make sure you granted the “Network logging” permission when the prompt appeared.
• Confirm that the device’s storage path is writable: adb shell ls -l /sdcard/Android.
• Check that you actually generated network traffic while the logger was active.

Problem 3 – Pull fails with “permission denied”

Some OEMs restrict access to /sdcard/Android for non‑system apps. Use the run-as command with a rooted device, or store the file in /sdcard/Download instead.

Problem 4 – Android Studio cannot import the file

Make sure you are using Android Studio 4.2 or newer. Older versions lack NetLog support. Updating the IDE resolves the issue.

Safety and privacy considerations

• NetLog captures every socket opened by every app, including URLs, IP addresses, and sometimes clear‑text payload headers. Treat the file as sensitive data.
• Never share a NetLog publicly unless you have removed or redacted personally identifiable information (PII).
• If you are troubleshooting a corporate device, verify that your organization’s policy permits capturing network logs.

Wrap‑up

By following the steps above you now have a reproducible workflow for capturing Android network activity, converting it to a readable format, and extracting actionable insights. The same process can be reused whenever a new app misbehaves, a VPN drops, or a DNS change causes outages. Remember to keep the device’s storage tidy—delete old .bin files after analysis—to avoid accidental data exposure.