Meshtastic-Android: the Android client for open-source mesh radios

What Meshtastic-Android actually is, and who it is for

The repository describes itself as "a tool for using Android (and Compose Desktop) with open-source mesh radios." That sentence sets the boundary. This is a client. It talks to radio hardware; it does not replace the hardware, and it does not provide the mesh by itself. The device-side code lives in a separate repository, meshtastic/firmware, which the README points to directly.

The audience is therefore narrow and specific. You need a Meshtastic radio, a phone or a desktop machine, and a reason to prefer a radio link over cellular data. The README frames the project around open-source mesh radios, and the search questions people ask about it cluster around the same practical concerns: whether it works on Android, whether it works with no cell service, and which apps interoperate with the radios. The first two are answered by the project's own premise. The app runs on Android, and a mesh radio link does not depend on a cellular network.

What the 2.8 line adds is worth reading as a statement of intent. Mesh network discovery surfaces nodes and channels around you, and Mesh Beacon invitations let you join nearby meshes. Waypoint geofences let you draw zones on the map and get alerts when nodes cross them. Secure key backup adds encrypted backup, restore and delete for device security keys. NFC sharing writes shared contacts and channels to NFC tags. XEdDSA packet signing indicators appear in the node and messaging UI. Air-quality telemetry covers PM1.0, PM2.5, PM10 and CO2 from supported sensors. App Functions integration lets on-device assistants trigger common workflows. None of that is a toy feature list; it is the shape of a client that expects to be used in the field, by people who care which node crossed which line and whether a packet was signed.

How the client, the radio and the desktop build fit together

The architecture visible in the repository is a Kotlin multi-module Gradle project with two application entry points. The androidApp/ directory holds the Android application. The desktopApp/ directory holds the Compose Desktop build, which is what produces the macOS DMG, Windows MSI/EXE and Linux DEB/RPM/AppImage installers listed on GitHub Releases, plus a Flatpak on Flathub under the application ID org.meshtastic.MeshtasticDesktop. The shared code sits in core/ and feature/, with build-logic/ carrying the Gradle convention plugins and baselineprofile/ carrying the baseline profile used to improve startup on Android.

That layout matters for a practical reason. A fix or a feature added to a shared module reaches both the phone and the desktop client. The README's desktop section is short, but it confirms the same release page serves both, and that the desktop packaging is maintained in a separate Flathub packaging repository.

The data flow runs from the radio to the client. The app discovers nodes and channels, displays them, and carries messaging and telemetry on top. Features like XEdDSA packet signing indicators are presented in the node and messaging UI, which means the client is reading and displaying signature state rather than inventing it. Waypoint geofences are drawn on the map and the alert fires when a node crosses the boundary, so the client holds the zone definition and evaluates crossings as position updates arrive. Air-quality telemetry arrives from supported sensors and is rendered as PM1.0, PM2.5, PM10 and CO2 readings. The client is the presentation and configuration layer; the radio remains the transport.

Two flavors exist for Android. The google flavor adds Google Crashlytics and Google Maps. The fdroid flavor has no Google dependencies. That is a real fork in behaviour, not a cosmetic label, and it is the first decision a new user makes.

Installing Meshtastic-Android and getting to a first working session

The README states plainly that the easiest and fastest way to get the latest releases is the GitHub releases page, and recommends Obtainium for automatic updates. The Obtainium links are generated, and the README warns that the links, files and the status table are generated by a script under obtainium/. The channels are Latest release and Open beta, and the README notes that the open beta channel had none published at the time the table was generated.

If you prefer a store, the README lists F-Droid, the IzzyOnDroid repository, GitHub releases and the Play Store, and says the Play Store is the last to update of these options. That ordering is the practical part: the same version number can reach different providers at different times.

For a first session, install the flavor you want, then open the app and let it discover nearby nodes and channels. The 2.8 line describes mesh network discovery as the mechanism that surfaces nodes and channels around you. If you have a Mesh Beacon invitation, that is the path for joining a nearby mesh. Nothing in the README documents a required pairing step beyond the radio being present, so treat the radio as a precondition rather than something the app can substitute for.

Building from source is documented for the docs sites rather than for the app itself, but the commands show the Gradle entry points. The user and developer documentation site is generated with Jekyll:

./gradlew generateDocsBundle publishDocsSite
BUNDLE_GEMFILE=docs/Gemfile bundle exec jekyll serve \
  --source build/_site --baseurl ""

The API reference is generated with Dokka:

./gradlew dokkaGeneratePublicationHtml

Both sites are deployed to GitHub Pages automatically on every push to main, so you do not need to build them locally unless you are changing documentation. For the app itself, the README points to the releases page and to docs/en/developer/test-builds.md for closed-beta and per-commit snapshot channels and importable config files.

Where Meshtastic-Android is the wrong tool

The clearest limitation is stated by the project's own framing: this is a client for radios. Without a Meshtastic radio, the app has nothing to talk to. Anyone looking for a messenger that works between two phones over the internet has the wrong project.

The second limitation is distribution lag. The README says the Play Store is the last to update of the available providers. If you depend on Play Store delivery, you will run behind the GitHub releases, and behind F-Droid and IzzyOnDroid as well. The README's recommendation of Obtainium is a direct response to that gap, and it is worth taking literally: if version currency matters to you, the store is not the channel.

The third is the flavor split. Choosing the google flavor means Google Crashlytics and Google Maps are in the build. The fdroid flavor exists specifically to avoid Google dependencies. If your environment forbids Google services, the choice is already made, and you should not expect the google flavor's map behaviour in the fdroid build.

Fourth, the README does not document rollback. There is no described procedure for reverting to an earlier release after an upgrade, and no documented downgrade path in the README or the release notes. If you are deploying to a group of users, that absence is worth knowing before you push an update.

Finally, the desktop build is a Compose Desktop target in the same repository, not a separate product with its own documentation. The README gives installers and a Flathub listing, and little else. If your primary platform is desktop, expect the Android side to be the better-trodden path.

How it compares with the other ways to run a Meshtastic client

The most direct alternative is the iOS client. The search data shows people asking whether Meshtastic works on Android and also searching for an Android versus iOS comparison. The difference is platform reach rather than protocol: the mesh radios are the same hardware, and the client is the phone-side application. If your users are on iOS, the Android repository is irrelevant to them, and the feature set of the 2.8 line, including NFC sharing and App Functions integration, is described here for the Android and desktop targets.

A second alternative is not installing the app at all and using a different client that speaks to the same radios. The README's own list of providers is about distribution, not about competing software, so it does not enumerate other clients. What it does make clear is that the radio side is open source and lives in a separate firmware repository. That means the client is one layer in a stack you can replace, at least in principle.

A third comparison is between the two flavors of this same app. The google flavor bundles Crashlytics and Google Maps; the fdroid flavor has no Google dependencies. That is the real fork for most users, and it is closer to an infrastructure decision than a feature comparison. If you want crash reporting and Google Maps, take google. If you want a build with no Google dependencies, take fdroid, and accept the map and diagnostics differences that come with it.

The desktop build is a fourth option, and it is genuinely different in approach: the same repository produces Compose Desktop installers for macOS, Windows and Linux, plus a Flatpak. If you want a laptop at a base station rather than a phone in a pocket, that is the route, though the README documents it far more briefly than the Android path.

Licence, maintenance and what an upgrade actually costs

The repository is licensed GPL-3.0. For most users installing a release APK or a desktop installer, the licence governs the software's distribution terms rather than your day-to-day use. For anyone embedding this client in another product, or redistributing a modified build, the copyleft terms are the ones to read, and that is a question for your own counsel rather than something this article can settle.

The maintenance signal is straightforward. The repository is not archived, and the last push was on 2026-08-28. The most recent release in the list is a snapshot dated 2026-08-28, with v2.8.1 on 2026-08-20 and v2.8.0 on 2026-07-29. That is a project publishing tagged releases and per-commit snapshots on a regular cadence, and the README confirms that both documentation sites deploy to GitHub Pages automatically on every push to main.

The upgrade cost depends on which channel you chose. Obtainium users get automatic updates, which is convenient and also means an update can land without your involvement. F-Droid, IzzyOnDroid and GitHub releases each move on their own schedule, and the Play Store trails them. The snapshot channel exists for people who want per-commit builds, and the README points to docs/en/developer/test-builds.md for closed-beta and snapshot setup plus importable config files. Snapshots are named with a commit hash, which is a useful reminder that they are not the same thing as a tagged release.

What the README does not cover is a rollback procedure, a migration note for moving between 2.8.0 and 2.8.1, or any statement about how long a given release line is supported. If you are managing devices for other people, treat the release notes as the source and plan your own verification step before rolling a new build across a group.

Editorial conclusion

Adopt Meshtastic-Android if you already own a Meshtastic radio and want the most current client build, especially through Obtainium or the F-Droid flavor. Skip it if you have no radio hardware, since the app is a client and not a network by itself, and skip the google flavor if you want no Google dependencies. Before installing, verify which flavor and release channel you are pulling, check that your device firmware matches the 2.8 line features you expect, and read the test-builds document if you plan to use snapshot or closed-beta channels.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes