How to sniff Bluetooth LE on Android — no extra hardware

You don't need a $100 dongle to start sniffing Bluetooth Low Energy. The radio in your Android phone already receives every BLE advertisement in range — the OS just doesn't show them to you. This guide covers what a phone can capture, how to do it, and where the honest limits are.

What an Android phone can and can't capture

Can: every advertising packet from every BLE device in range — device name, hardware address, RSSI, manufacturer data, service UUIDs and service data, plus scan responses. That's the full discovery layer of BLE, and for most practical questions ("what's broadcasting in here?", "what is this device sending?", "is my firmware advertising correctly?") it's the layer that matters.

Can't: link-layer traffic between two other devices. Android doesn't expose raw radio access to apps, so no app can follow another pair of devices' connection. Any app that claims otherwise is overselling. For that job you need dedicated sniffer hardware.

There's one useful exception for your own phone's traffic — the HCI snoop log, covered at the end.

Step 1: Scan and enumerate

Install a scanner app — BLE Sniffer is free, has no ads, and sends nothing off your device. Start a scan and you'll see devices appear with:

• Name — if the device broadcasts one. Many don't; "Unknown" is normal.
• Address — the MAC-style hardware address. Note that most modern devices (phones especially) rotate randomized addresses every few minutes to resist tracking, so one physical device can appear as several addresses over time.
• RSSI — received signal strength in dBm. Closer to 0 is stronger: −40 dBm is usually within arm's reach, −90 dBm is at the edge of range.
• Manufacturer — decoded from the company identifier in the advertisement's manufacturer-specific data.

Expect more devices than you'd guess. A quiet apartment commonly has a dozen broadcasters; an office or coffee shop can have fifty or more.

Step 2: Read the payloads

Tap into a device to inspect what it's actually transmitting. Advertisements are built from length-type-value structures — flags, service UUID lists, local name, TX power, service data, and manufacturer-specific data. The manufacturer data field is where the interesting bytes usually live: beacon identifiers, sensor readings, state flags. Our guide to the advertisement format walks through decoding it byte by byte.

Step 3: Log and export

Watching live is fine for a quick look; real analysis wants data you can sort and diff. BLE Sniffer logs every scan session on-device and exports to CSV, so you can pull sessions into a spreadsheet, Python, or your tool of choice and answer questions like:

• Which addresses appeared in every session? (Fixed infrastructure.)
• Which appeared once and vanished? (Passers-by, or address rotation.)
• How does RSSI for one device change across locations? (Rough localization — see the device-finding walkthrough.)

Bonus: capture your own phone's connections with the HCI snoop log

Android has a built-in developer feature that logs every Bluetooth packet your phone sends and receives — including connection traffic to devices you're paired with:

1. Enable Developer options, then turn on Enable Bluetooth HCI snoop log.
2. Toggle Bluetooth off and on, then use the connection you want to inspect.
3. Generate a bug report (or pull btsnoop_hci.log via adb) and open it in Wireshark, which dissects BLE natively.

This is the cheapest way to reverse-engineer how an app talks to its gadget — GATT reads, writes, and notifications, all in the clear from the HCI layer's point of view. It only works for connections your phone is a party to, which for debugging and reverse-engineering your own devices is exactly what you want.

When to graduate to hardware

If you need to watch a connection between two devices you don't control the phone side of, verify timing at the radio level, or capture Bluetooth 5 extended advertising exhaustively, move up to an