BSSID

When a phone scans for wifi it does not just collect network names. Each result carries a BSSID, an SSID, a signal strength in dBm, a frequency in MHz and a capabilities string describing the security modes on offer. The SSID is a label anyone can duplicate. The BSSID is the access point’s hardware MAC address, and it is what actually identifies a specific box on a specific wall.

Reading a scan result

• BSSID — six hex pairs. On an access point broadcasting several networks, the virtual BSSIDs differ only in the low bits of the last octet, so 04:18:d6:a1:22:80 and 04:18:d6:a1:22:81 are one physical router, not two.
• RSSI — roughly -30 dBm on top of the router, -67 dBm as the usual threshold for reliable use, -90 dBm at the edge of detection.
• Frequency — 2412 to 2472 MHz for 2.4 GHz channels 1 to 13, 5180 to 5825 MHz for 5 GHz, 5955 MHz and above for 6 GHz.
• Capabilities — a string such as [WPA2-PSK-CCMP][WPS][ESS], describing what the access point supports.

Why a BSSID list is a location

Google, Apple and independent projects such as WiGLE maintain databases mapping BSSIDs to coordinates, built by correlating scan results with GPS fixes from millions of handsets. Feed a handful of visible BSSIDs and their signal strengths into such a database and you get a position accurate to roughly 20 to 50 metres in a dense urban area — faster than a GPS fix, and working indoors where GPS does not. This is how a phone knows where it is within a second of unlocking. It is also why the visible BSSID set is a geolocation claim independent of, and checkable against, the IP address.

Network owners can opt out by appending _nomap to the SSID, which Google honours by excluding the access point from its database. That mechanism is worth knowing because it explains legitimate gaps: an access point absent from every database is not automatically suspicious.

Why it exposes emulated environments

A real phone sits in a real place. It sees somewhere between three and thirty neighbouring access points depending on density, that set changes slowly as neighbours reconfigure their routers, and the signal strengths jitter by several dBm between consecutive scans because radio propagation is never static. An emulator typically presents a single synthetic network — the Android SDK image famously exposes one called AndroidWifi — with a fixed BSSID and an RSSI that reads the same value forever. Three distinct anomalies follow: a scan list of length one, an RSSI with zero variance, and a BSSID that appears in no database anywhere.

The empty result is the ambiguous case, and it cuts both ways. Since Android 9, an app needs ACCESS_FINE_LOCATION to receive scan results at all, and Android 8 throttles foreground scans to four per two minutes. So an app that sees nothing cannot immediately distinguish a denied permission from a device with no radio. What it can distinguish is a device that reports a populated list which never changes.

Inspecting scans yourself

• adb shell cmd wifi list-scan-results — on Android 11 and later, a clean table of BSSID, RSSI, channel and SSID.
• adb shell cmd wifi status — the currently associated access point, including its BSSID.
• adb shell dumpsys wifi — verbose, older builds, includes the scan cache.
• Run the same command three times a minute apart and compare RSSI values. Identical numbers across all three runs means the readings are synthesised, not measured.

The consistency question

As with every other signal, what matters is agreement. Visible BSSIDs resolving to Amsterdam, a proxy exiting in Sao Paulo, and a timezone of America/New_York is three sources contradicting each other — and each pair is a single lookup to check. The failure is not that any one value is wrong; it is that no physical device could produce all three at once.

It is worth knowing which of these signals a provider actually populates before assuming they are handled. Ask directly whether the wifi scan list is real, and verify with the commands above rather than with the answer.