WiFiAnalyzer: an Android Wi-Fi survey tool that never touches the network

What WiFiAnalyzer solves, and who is holding the phone

The problem is mundane and recurring: you are standing in a building, the Wi-Fi is bad, and you need to know whether the fault is your access point's channel choice, a neighbour's network sitting on top of it, or something else entirely. WiFiAnalyzer answers the channel part of that question from an Android device. The README lists its purpose plainly: identify nearby access points, graph channel signal strength, graph access point signal strength over time, and analyze Wi-Fi networks to rate channels.

The audience is narrower than the search results suggest. This is an Android application, published through Google Play, F-Droid and GitHub releases. Anyone looking for a Windows 10, Windows 11 or macOS build will not find one in this repository; the README links no desktop package. The people who get value from it are network technicians, installers and home users who already carry an Android phone and want a quick read on the 2.4, 5 and 6 GHz bands without provisioning a laptop or joining the network they are diagnosing.

The README is explicit about one boundary that matters for procurement: "Please note WiFiAnalyzer is not a Wi-Fi password cracking or phishing tool." It is a measurement tool. If you need to test throughput, authenticate against a captive portal or capture frames, this is the wrong instrument.

How the scanning and channel rating actually work

WiFiAnalyzer sits on top of the Android Wi-Fi scanning APIs. It does not put the radio into monitor mode and it does not inject frames; it asks the platform for the list of visible access points and renders that list several ways. The README describes the outputs rather than the internals: an access point list in complete or compact form, a channel graph, a signal-strength-over-time graph, and a channel rating view.

The channel rating is the part with the most opinion in it. The app scores channels by how much other traffic overlaps them, which is why the README points readers at a channel list and at an explanation of the 5 GHz channel question. The estimated distance to each access point is derived from signal strength using the free-space path loss model, and the README links to that Wikipedia article as the explanation, so treat the number as an order-of-magnitude hint rather than a measurement. Walls, antenna orientation and transmit power all break the assumption.

Two features are conditional. HT/VHT detection for 40, 80, 160 and 320 MHz widths, and the 6 GHz band, both carry the same caveat in the README: they require hardware and software support. On an older phone the 6 GHz tab simply will not have data to show, and that is a device limit, not a bug in the app. The vendor/OUI lookup is a local database match against the MAC address prefix, which is why the app can work without any network access at all.

Installing WiFiAnalyzer and reading your first channel graph

There is nothing to build unless you want to. The README offers three distribution channels: Google Play, F-Droid and the GitHub releases page. F-Droid is the one to prefer when you want the build to arrive through a repository you already trust and update on its own schedule. The latest release listed in the repository is tagged V3.3.1-F-DROID, dated 2026-07-01.

If you would rather build the APK yourself, the repository is a Gradle project with a Kotlin Android app module under app/, and the README's build section points at the Android CI workflow in .github/workflows/android-ci.yml as the record of how the maintainers build it. The README does not spell out the required Android SDK level or the JDK version in the text available here, so check build.gradle.kts and gradle.properties before assuming your local toolchain matches.

Once installed, the first useful action is not the access point list but the channel graph. Open the app, grant the Wi-Fi and location permissions it asks for, and let it scan. Android will return a set of access points; the channel graph plots them as overlapping curves across the 2.4 GHz channel numbers. The visual question you are answering is simple: is there a channel where the curves are lowest across its whole width? The README's own how-to section links a guide to finding the best 5 GHz channel, and the same reading applies there, with more non-overlapping options.

If the graph looks frozen, that is expected behaviour on modern Android. The project maintains a wiki page titled "Android Wi-Fi scanning throttling" precisely because the platform limits how often an app may request a scan. The app also exposes pause and resume scanning controls, which matter when you want to hold a reading steady rather than watch it update.

Filters, exports and the permissions you cannot avoid

The filter set is where WiFiAnalyzer becomes usable on a dense site. You can narrow the access point list by Wi-Fi band, by signal strength, by security type and by SSID. On a floor with forty visible networks, filtering to 5 GHz and to a signal threshold removes most of the noise, and the remaining list is the one that actually competes with your own access point. The SSID filter is documented separately in issue 125, which suggests it is not obvious from the UI alone.

Export of access point details is the feature that turns the app into something you can hand to someone else. It is also the feature that makes the permission model worth understanding. The README states that the app collects no personal or device information, requires no internet access, and asks for just enough permission to perform the analysis. The unavoidable one is location. The project keeps a wiki page on location service permission requirements because Android ties Wi-Fi scan results to location permission, and on secondary user accounts the app has its own documented behaviour. If your organisation blocks location permission on managed devices, WiFiAnalyzer will not produce a scan list, and no amount of configuration in the app changes that.

Where WiFiAnalyzer stops being the right tool

The first limitation is the platform. There is no Windows, macOS or Linux build in this repository. Every search phrase asking for a PC version points at a product this project does not ship. If your survey workflow lives on a laptop, you will be running two tools, not one.

The second is the scanning throttle. Android limits scan frequency, and the project treats this as a known constraint significant enough to document in its wiki. A channel graph built from throttled scans updates in steps, not continuously. For locating a moving source of interference or watching a roaming client, that granularity is too coarse.

The third is the measurement model. WiFiAnalyzer reports what the Android radio reports. It sees Wi-Fi access points, not the RF environment. A microwave, a DECT handset or a poorly shielded cable will degrade your network without appearing anywhere in the app. The README's own how-to links an IEEE Spectrum piece titled "Why Wi-Fi stinks and how to fix it," which is a fair hint that the tool shows you one layer of a multi-layer problem.

Finally, the estimated distance figure invites over-trust. It comes from free-space path loss, which assumes an unobstructed line between transmitter and receiver. In a real building that assumption fails immediately. Use it to rank access points by rough proximity, never to state a distance.

WiFiAnalyzer against a laptop survey suite

The obvious alternative for anyone who needs more than a phone is a desktop survey application, and the difference is architectural rather than cosmetic. A desktop suite running on a laptop with a supported adapter can drive the radio directly, which is what makes continuous capture, spectrum overlays and heat-map surveys possible. WiFiAnalyzer cannot do any of that because it is bound to the Android scanning API and to whatever the phone's chipset exposes.

The trade is convenience against depth. WiFiAnalyzer installs from F-Droid in under a minute, needs no adapter, no licence and no laptop, and its export gives you a snapshot of access point details you can email from the phone. A desktop suite needs a supported adapter, a licence in most cases, and a survey walk to produce a heat map. For a quick channel decision in a client's office, the phone wins. For a documented site survey with floor plans, it does not.

There is also a simpler comparison inside the same category: a Wi-Fi analyzer is not a spectrum analyzer. A spectrum analyzer sees energy across frequencies, including non-Wi-Fi sources. WiFiAnalyzer sees networks. The project's own search-adjacent framing puts these side by side, and the distinction is worth holding onto when someone asks why the app shows a clean channel while users still report dropouts.

Licence, build cost and what upgrading involves

WiFiAnalyzer is licensed under GPLv3. The README summarises the obligations as disclose source, keep the licence and copyright notice, use the same licence, and state changes. In practice this matters if you intend to fork the app, ship a modified build inside a company, or bundle it into a product. The copyleft applies to the distributed work, so a private internal build that never leaves the organisation is a different situation from an APK handed to customers. That is a question for your own counsel, not for this article.

For ordinary users the licence is invisible. You install from F-Droid or Google Play and receive updates through that channel. The repository's release cadence is visible in the tags: V3.2.1-F-DROID in June 2025, V3.2.2-F-DROID in January 2026, V3.3.1-F-DROID in July 2026. The last push to the repository was on 2026-09-20, so the project is being worked on between releases rather than abandoned after each tag.

If you build from source, the maintenance cost is the Android toolchain, not the app. Gradle, the Android SDK and the Kotlin version all move, and a project that is a year old may need dependency bumps before it compiles cleanly on your machine. The repository ships an Android CI workflow and a CodeQL analysis workflow, which is where the maintainers' supported build configuration lives. Contributions go through CONTRIBUTING.md, and translations run through Weblate, so a localisation change does not require touching Kotlin at all.

Editorial conclusion

Adopt WiFiAnalyzer if you carry an Android phone into a site and need channel occupancy, signal-over-time graphs and an export of access point details without installing anything on the network. Do not adopt it if you need a Windows or macOS survey tool, a continuous packet capture, or a spectrum view of non-Wi-Fi interference; the README names no desktop build and the app is an Android application. Before you rely on it, verify three things on the target device: that the Wi-Fi and location permissions are granted, that the 6 GHz band and HT/VHT widths actually appear (the README ties those to hardware and software support), and how often scans are returned on that Android version, because the throttling wiki page is the real limit on how fast the channel graph moves.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. VREMSoftwareDevelopment/WiFiAnalyzer on GitHub