# Network Survey: an Android app that records what the radios are doing

> Network Survey is a Kotlin Android app that logs cellular, Wi-Fi, Bluetooth and GNSS measurements to GeoPackage or CSV files, or streams them live over MQTT or gRPC, with a call detail record mode for cellular events. It suits a network engineer collecting field data or a developer building a server to receive the stream, and the two build variants differ in what telemetry they send away.

**christianrowlands/android-network-survey** — Cellular Survey Android App

- Repository: https://github.com/christianrowlands/android-network-survey
- Website: https://www.networksurvey.app
- Stars: 585 · Forks: 81
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/christianrowlands-android-network-survey

## Four radio types, one log format

The Network Survey Android App provides a basic survey capability for logging and analyzing cellular networks, Wi-Fi networks, Bluetooth devices and GNSS constellations. The documentation is unapologetic about the word basic, and the screenshots in the readme are a dashboard plus a cellular details screen, a Wi-Fi details screen and a GNSS details screen.

What it captures is described as detailed records of signal strength, network information and device data, and the records cover GSM, CDMA, UMTS, LTE, 802.11, Bluetooth and GNSS according to the streaming sections.

The output format is the part that makes the app useful to somebody who will analyse the data later rather than merely look at it. All data can be logged to GeoPackage or CSV files for offline analysis, and GeoPackage is the more interesting of the two choices because it is a spatial format, so a survey becomes a set of georeferenced rows you can load into a GIS tool rather than a list of measurements with coordinates in a column.

The alternative to files is live streaming, and there are two protocols for it. The app can live stream the data via MQTT or gRPC for real-time monitoring and integration with other systems, which turns it from a data collection tool into a sensor feeding a monitoring system.

The primary language is Kotlin, the licence is Apache-2.0, and the project is published on the Play Store, on IzzyOnDroid and on F-Droid, with a user manual at networksurvey.app/manual.

## The two build variants differ in what they send to Firebase

There are two build variants, and the difference between them is the most important thing to understand before you install anything.

The regular variant is the Google Play version, and it has Firebase Crashlytics and Analytics enabled. That means crash logs and analytics are sent off the device to Firebase. The privacy section of the project documentation spells this out and then gives three ways to opt out: install from IzzyOnDroid, install from the source in the repository specifying the CDR build variant, or install the CDR APK from the releases page.

The CDR variant does not have Crashlytics and Analytics enabled, and it has the extended CDR logging features.

So the choice is not between two feature sets alone. It is between a version that reports to a third party and one that does not, and a version that records more events and one that does not. For a tool whose entire purpose is to collect a record of what a device is doing, sending that device's own analytics to a server as a side effect is a design decision worth naming, and the project names it.

A privacy policy file sits in the repository root and covers the data sent to Firebase for the Play Store version, so the specifics are documented rather than only implied.

## Call detail records, and the three things no version can log

The newest feature is logging of Call Detail Records, and the documentation defines the term precisely: a CDR is a data record documenting specific interactions a phone has with the cellular network, and those interactions include phone calls, SMS and MMS messages, and changes in cell tower connections.

The stated use cases are monitoring network activity by recording and reviewing the phone's cellular interactions, educational insight into how cellular networks operate, and privacy monitoring, which the project frames as checking whether your phone is connecting to unexpected cell towers.

The feature limitations section is the part to read carefully, because it lists what is missing and why.

The regular version does not log SMS or MMS events in the CDR, because of Google Play's policy against apps requesting full SMS permissions. It also does not support logging the other phone number associated with call events.

And RCS chats are not logged by either version. The stated reason is structural rather than a policy decision: Android only lets the default messaging app see RCS messages, so there is no way for Network Survey to record them.

That last one is worth noting as a category of limitation. The app can read the telephony state and the radio state, and it can see the default SMS app's messages because the platform says so, but the platform does not extend RCS visibility to a survey tool, so no amount of engineering fixes it. The CDR variant exists precisely to get around the Play Store policy constraint, and it still cannot get around the platform one.

## Building and installing on a connected device

The build is a standard Gradle project and the commands are given for both variants.

For the regular version:

```shell
./gradlew assembleRegularDebug
./gradlew installRegularDebug
```

And for the CDR version:

```shell
./gradlew assembleCdrDebug
./gradlew installCdrDebug
```

There is a note for Windows, where ./gradlew becomes gradlew. The install tasks push the APK to the connected device, so the phone has to be attached before you run the install command.

If you prefer Android Studio, the readme gives the manual route: clone the repo, open the root directory of the clone in Android Studio, connect an Android phone with debugging enabled, and press the Play button.

The test suite runs on a device rather than on the JVM, and the note says it requires a connected device, either a physical phone or an Android emulator:

```shell
./gradlew connectedAndroidTest
```

That is a real constraint on the contribution loop. An instrumentation suite that needs a device or a running emulator cannot be run in a plain CI container without an emulator image, and the repository does carry a GitHub Actions workflow for the Android build, so the project does run it somewhere, but a contributor without a device needs an emulator.

The repository layout is a conventional Android project: the app module in networksurvey/, a root build.gradle, settings.gradle, gradle.properties, the gradle wrapper, a fastlane/ directory for release automation, a docs/ directory, and the usual GitHub and security files.

## Streaming to a server, and what the project expects you to build

The streaming half of the project is where it stops being an app and becomes a data pipeline, and the documentation is helpful about who does what.

For gRPC, the app supports streaming GSM, CDMA, UMTS, LTE and 802.11 survey records to a gRPC server. The companion piece is the Network Survey Messaging library, which can be used to stand up a gRPC server, and from there the documentation says it is up to the implementation to handle the incoming survey messages.

There is also a Go example. If you want to see how to use the generated Go code to create a gRPC server, the documentation points at a separate repository with that code, and it is candid that the server does not do anything useful but serves as an example of how one might be created in GoLang.

The MQTT route is described separately, and the set of record types is stated as GSM, CDMA, UMTS, LTE, NR, 802.11, Bluetooth and GNSS survey records, which is a wider list than the gRPC section gives. The two protocols are therefore not symmetric in coverage, and that asymmetry is worth checking against your own instrumentation needs before you commit to one.

The design boundary is clear and reasonable: the app produces records, the protocols carry them, and the server side is explicitly left to you. The Messaging library and the Go example exist so that the wire format is not something you have to reverse engineer from the app.

## Where Network Survey is the wrong tool

The first limit is that this is an instrument for one device, not a network monitoring platform. You install it on a phone, it records what that phone's radios see, and it stops. A team that wants continuous visibility of a cell site, a Wi-Fi deployment or a fleet of devices is looking for something that collects centrally, and this app does not do that.

The second is the telemetry asymmetry between builds, which is a real operational decision rather than a technical limitation. If your organisation has a policy about sending crash data and analytics to a third party, the Play Store build is off the table and you are on the F-Droid route or on building the CDR variant from source. That is manageable, but it means the easiest install path is the one you may not be allowed to use.

The third is the permission ceiling. SMS and MMS recording needs full SMS permissions, which Google Play restricts, and RCS is out of reach because of how Android exposes those messages. The CDR variant moves the first limit but not the second, and a project whose value proposition is the CDR log will find that the log has a hole in it whichever build you install.

The fourth is the data volume and the analysis burden. Long runs produce a lot of rows across four radio types, and the app writes files rather than answering questions. The formats are good, GeoPackage especially, but the interpretation, the filtering and the charts are all work you do afterwards, and nothing in the project presents the collected data for you.

The fifth is the build requirement for a device-connected test suite, which slows down contribution and makes the project less pleasant to work on than a pure JVM library. And the last point is timing: the recent tags are v1.57 from 2026-08-04, v1.58 from 2026-09-02 and v1.59 from 2026-09-21, with the last push to the repository on 2026-10-22, so the app is moving regularly, but the releases are for the Play Store variant and the CDR APK is a separate artefact in the same releases list that you have to know to look for.

## Conclusion

Network Survey is worth installing if you need real radio measurements from a real handset, because it captures signal strength, network information and device data across four radio types in one run and writes them to files you own, and because the CDR build variant gives you call, cell tower and message events that the Play Store version cannot record. It is the wrong tool if you want a managed telemetry platform, and the wrong tool if you need SMS or RCS visibility, which the project states is not possible. Before you install it, check the three things the documentation is explicit about: that the Play Store build sends crash logs and analytics to Firebase, and the IzzyOnDroid, source build and CDR APK routes do not; that the regular version cannot log SMS or MMS events or the other number on a call, because of Google Play's policy on full SMS permissions, while the CDR variant can; and that RCS chats are recorded by neither version, because Android only exposes them to the default messaging app.

## FAQ

### What does the Network Survey Android app record?

It provides survey logging and analysis for cellular networks, Wi-Fi networks, Bluetooth devices and GNSS constellations, capturing records of signal strength, network information and device data. Everything can be written to GeoPackage or CSV files for offline analysis, or streamed live over MQTT or gRPC for real-time monitoring.

### How do I build the CDR version of Network Survey?

Use the CDR build variant with the Gradle wrapper, running ./gradlew assembleCdrDebug followed by ./gradlew installCdrDebug with the phone connected. The CDR variant has no Firebase Crashlytics or Analytics and adds SMS and MMS event logging, which the regular Google Play build cannot record because of Play's policy on full SMS permissions.

### Can Network Survey record RCS messages?

No, and neither build can. The project documentation states that RCS chats are not logged by either version, because Android only lets the default messaging app see RCS messages, so there is no way for the app to record them.

## Sources

- [christianrowlands/android-network-survey on GitHub](https://github.com/christianrowlands/android-network-survey)
- [License: Apache-2.0](https://github.com/christianrowlands/android-network-survey/blob/develop/LICENSE)
- [Project website](https://www.networksurvey.app)
- [README](https://github.com/christianrowlands/android-network-survey/blob/develop/README.md)
- [Releases](https://github.com/christianrowlands/android-network-survey/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/christianrowlands-android-network-survey