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.

What the stock emulator shows

A handset carried around a city sees a changing set of neighbouring access points, and their signal strengths drift between consecutive scans because radio propagation is never static. The Android SDK emulator instead exposes a single simulated network called AndroidWifi, with a fixed BSSID. A one-entry scan list naming AndroidWifi is therefore a trait of that emulator, and one of the strings emulator-detection code looks for.

Beyond that specific case, wifi scans are a weaker signal than they look, for a plain reason: most apps cannot read them. 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. An app without location permission sees nothing, on every device, and cannot tell a denied permission from anything else. For the apps that do hold the permission, the scan is one location claim among several, compared with the others as described below.

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 a few times a minute apart and compare RSSI values; on a handset in the field they drift by a few dBm.

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 are three sources contradicting each other — and each pair is a single lookup to check. The issue is not that any one value is wrong; it is that no single location explains all three at once.

Of the three, the network exit and the timezone are the two you set yourself, and the two that every app can compare without asking for any permission. Getting those to agree is the highest-value fix on this list, and it costs nothing but attention when a device is assigned its proxy.