Capture Android Network Traffic with ADB and tcpdump (No Root)

12 min read Step‑by‑step guide to install tcpdump via ADB, capture network packets on any Android device without rooting, and analyze the log. October 02, 2026 12:00 How to Capture Android Network Traffic with ADB and tcpdump (No Root)

Why capture network traffic on Android?

Many developers, security enthusiasts, and power users need to see exactly what data their phone is sending and receiving. Whether you are debugging an app, checking for unwanted ads, or verifying that a VPN is really encrypting traffic, a raw packet capture (PCAP) gives you the most accurate view.

Android does not ship with a built‑in packet sniffer, and most commercial sniffers require root. Fortunately, the open‑source tool tcpdump can run from the device’s user space when you push it with ADB. This tutorial shows you how to do it safely, without rooting, on any Android 5.0+ device.

Before you start

  • USB debugging enabled: Settings > About phone > tap Build number seven times, then Settings > System > Developer options > enable USB debugging.
  • Computer with ADB installed: The Android SDK Platform‑Tools package is sufficient. Verify with adb version.
  • Enough storage: A capture can grow quickly. Allocate at least 200 MB on the device’s internal storage or an SD card.
  • Wi‑Fi or cellular connection you want to monitor. The capture records everything that traverses the selected interface.
  • Patience for a short test run. Capture for a few minutes first to confirm the workflow before a long session.

Step 1 – Download the correct tcpdump binary

tcpdump is compiled for different CPU architectures. Most modern phones use arm64-v8a or armeabi‑v7a. Choose the binary that matches your device.

  1. Open a web browser on your computer and go to the official tcpdump site or a trusted mirror that hosts Android builds.
  2. Download tcpdump-arm64 for 64‑bit devices or tcpdump-arm for 32‑bit devices.
  3. Rename the file to tcpdump (no extension) for simplicity.

If you are unsure about the architecture, you can query the device via ADB:

adb shell getprop ro.product.cpu.abi

Typical outputs:

  • arm64-v8a → use the arm64 binary.
  • armeabi-v7a → use the arm binary.

Step 2 – Push tcpdump to the device and make it executable

  1. Connect the phone via USB and verify the connection:
    adb devices
    You should see your device listed as device.
  2. Push the binary to /data/local/tmp, a writeable location that does not require root:
    adb push tcpdump /data/local/tmp/
  3. Set the executable flag:
    adb shell chmod 755 /data/local/tmp/tcpdump
  4. Confirm it works by running a short help command:
    adb shell /data/local/tmp/tcpdump -h
    You should see the usage text, confirming the binary runs.

If you receive Permission denied, double‑check that you pushed the file to /data/local/tmp and not to a system directory.

Step 3 – Identify the network interface you want to capture

Android devices usually have at least two interfaces: wlan0 for Wi‑Fi and rmnet0 (or similar) for cellular. To list them:

adb shell "cat /proc/net/dev"

Look for the interface names in the left column. Choose the one that matches the connection you are testing.

Step 4 – Start the packet capture

  1. Decide on a file name and location. We will store the capture in /sdcard/Download because it is easy to pull later.
    CAP_FILE="/sdcard/Download/android_capture.pcap"
  2. Run tcpdump with the chosen interface. The -i flag selects the interface, -w writes raw packets, and -s 0 captures the full packet length.
    adb shell "su -c '/data/local/tmp/tcpdump -i wlan0 -s 0 -w $CAP_FILE'"
    Note: On non‑rooted devices the su -c wrapper is not needed; the command can be executed directly. The example includes it for devices that have a temporary root shell via adb root, but most users will omit it:
    adb shell "/data/local/tmp/tcpdump -i wlan0 -s 0 -w $CAP_FILE"
  3. The command runs in the foreground and prints a short summary line for each packet. To stop the capture, press Ctrl+C in the terminal.

Typical output looks like:

tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes

When you stop the capture, you will see a line such as 123 packets captured.

Step 5 – Pull the PCAP file to your computer

Now that the capture is saved on the device, copy it to your analysis workstation:

adb pull /sdcard/Download/android_capture.pcap ./

The file is now ready for inspection with Wireshark, tshark, or any other PCAP viewer.

Step 6 – Quick sanity check in Wireshark

Open the file in Wireshark and apply a simple filter to verify you captured the intended traffic, for example:

  • All HTTP traffic: http
  • All DNS queries: dns
  • All traffic to a specific host: ip.addr == 93.184.216.34

If you see packets, the capture succeeded. If the file is empty, revisit the interface name and ensure the device was actively using that network during the capture window.

Troubleshooting common issues

1. tcpdump reports "not enough privileges"

On some OEM skins, the /data/local/tmp directory is mounted with the nosuid flag, preventing execution of binaries that need raw sockets. In that case, try pushing the binary to /data/local/tmp and executing it with the run-as trick for a specific app’s UID:

adb shell "run-as com.android.shell /data/local/tmp/tcpdump -i wlan0 -s 0 -w /sdcard/Download/capture.pcap"

If this still fails, the device may block raw socket access for non‑system users. The only reliable workaround is to use a rooted device or a custom recovery that allows packet capture.

2. Capture file is zero bytes

  • Make sure the network interface was active during the capture. Switch Wi‑Fi on/off or generate traffic (open a website) while tcpdump runs.
  • Check storage permissions: the /sdcard/Download folder must be writable. You can test with a simple adb shell touch /sdcard/Download/test.txt.
  • Some manufacturers (e.g., Samsung) enforce a per‑app sandbox that blocks writing to /sdcard from ADB shell. Use /data/local/tmp instead, then pull the file from there.

3. ADB cannot find the device

Ensure USB debugging is still enabled and the USB cable is data‑capable. On Windows, reinstall the Google USB driver. On macOS/Linux, you may need to add your user to the plugdev group.

4. The capture is too large

Use the -c flag to limit the number of packets, or the -W flag to rotate files after a size threshold. Example to stop after 10,000 packets:

adb shell "/data/local/tmp/tcpdump -i wlan0 -s 0 -c 10000 -w /sdcard/Download/capture.pcap"

Advanced tips

  • Capture only specific ports: Add a filter expression after the options, e.g., tcp port 443 to record only HTTPS traffic.
    adb shell "/data/local/tmp/tcpdump -i wlan0 -s 0 -w /sdcard/Download/https.pcap tcp port 443"
  • Run tcpdump in the background so you can continue using the terminal:
    adb shell "nohup /data/local/tmp/tcpdump -i wlan0 -s 0 -w /sdcard/Download/bg.pcap &"
    Remember to kill it later with adb shell pkill -f tcpdump.
  • Combine with Wi‑Fi Direct to capture traffic between two Android devices without the interference of other network users.
  • Decrypt TLS (HTTPS) traffic only if you have the server’s private key or you are using a debugging proxy that performs TLS termination. tcpdump itself cannot decrypt encrypted payloads.

Safety and privacy considerations

Capturing network traffic can expose passwords, tokens, and personal data. Treat the resulting PCAP file as sensitive:

  • Store it in an encrypted folder.
  • Delete it from the device after pulling.
  • Never share raw captures publicly unless you have removed or anonymized personal identifiers.

Because the method uses a user‑space binary, it does not modify system partitions, so there is no risk of bricking the device. However, running any executable from an unknown source carries a small security risk. Only download tcpdump from reputable mirrors.

Wrapping up

By following these steps you have installed tcpdump on a non‑rooted Android phone, captured live network traffic, and exported the data for deep analysis. The workflow is repeatable, works across most manufacturers, and does not require flashing custom recoveries or unlocking the bootloader.

Use the captured data to verify VPN tunnels, debug app networking, audit data‑leakage, or simply satisfy curiosity about what your phone talks to on the internet. With the troubleshooting notes above, you should be able to adapt the process to edge‑case devices and avoid the most common pitfalls.

User Comments (0)

Add Comment
We'll never share your email with anyone else.