OSMTracker for Android: logging a GPS track and the points along it

A track is not enough on its own

OSMTracker for Android is a mobile app designed for OpenStreetMap mappers and outdoor adventurers, and it lets you log a GPS track to document your journey.

A GPS track on its own is a thin artefact. It tells you where you walked, but a survey needs more than a line on a map. A mapper walking down a high street needs to record that a shop is a pharmacy, that a bench is broken, that there is a level entrance on the side street, that a cafe takes cards. Those are points of interest, they sit at coordinates, and they need to be attached to the journey rather than kept in a separate notes application and remembered afterwards.

That is the problem this app addresses, and it does so in a way that fits how mapping actually happens. The customizable buttons let you simply add POIs as track points directly inside your GPX track. You press a button, the app records the current position as a point inside the track you are building, and the whole thing exports as one file.

The result is a GPX file that a mapper can upload directly, with the survey notes embedded at the right place in the route rather than as a list of coordinates to be matched up afterwards.

The readme also notes that the app supports voice recording, picture taking and note-taking, and describes it as the perfect app to survey a place or a path whether you are hiking, cycling or exploring new areas. The voice recording is the interesting one of those three, because speaking an observation is far faster than typing it on a phone while standing in the street, and for a mapper collecting features at walking pace that difference compounds over a survey.

Custom buttons are the actual interface

The screenshot in the readme shows the main screen with its default buttons, and the readme then tells you that you can customize these buttons to your liking, with a link to a wiki page about custom buttons layouts.

That single sentence is the most important design fact in the whole project, and it is worth pausing on why. A mapping survey is a sequence of different observations, and the right set of buttons for it depends entirely on what you are looking for. A surveyor checking accessibility wants a button for a ramp, a button for a step-free entrance, a button for a tactile paving surface. A surveyor checking addresses wants a button for a house number, a button for a building entrance, a button for a street name sign. A person auditing a path wants a button for a bollard, a barrier, a surface type.

A fixed set of buttons cannot serve all of those. The screenshot's default set is a starting point, and the wiki page on custom button layouts is where the real configuration happens.

This makes the app a natural fit for structured surveying rather than ad hoc mapping. If you are running a repeatable audit, for example checking every footpath in a district for accessibility, the button set is part of your method, and being able to change it means the method can live in the app rather than in your head.

It also explains the POI-as-track-point design. Because each button press adds a point into the same track, a survey produces one ordered sequence, and the ordering is the order you walked. That is what makes the resulting GPX usable without later processing.

Where it is distributed and who maintains it

The app is on Google Play and on F-Droid, under the package identifier net.osmtracker, and the readme links both.

The presence of F-Droid alongside Google Play is the distribution decision that says something. F-Droid is the free software channel, it builds from source, and it is the route that users who want to avoid proprietary app distribution take. For an application whose whole purpose is producing data for a public, open map, having it available through both channels is the expected arrangement rather than a bonus.

The readme points at four further resources. Documentation is in the project wiki, bug reports go to the GitHub issue tracker, contributions are welcome through a contributor guide in the repository, and translations can be done on Transifex.

Transifex is a translation management platform rather than a file-based workflow, and pairing it with a Telegram group for real-time discussion is a fairly modern arrangement for an open source app. The readme describes the Telegram group as the place to connect with users, developers, translators and contributors, for real-time discussions, guidance and support, while bug reports and feature requests continue to use GitHub Issues. The split is deliberate and sensible: chat for conversation, the issue tracker for things that need a record.

The repository is Java, licensed GPL-3.0, with the default branch named master. The build is Gradle, with build.gradle, settings.gradle, gradle.properties, a gradlew wrapper and both gradlew.bat, and there is a fastlane directory for release automation and an app directory holding the Android application itself. There is a .tx directory and a transifex.yml at the root, which is the Transifex client configuration, and the presence of both of those in the tree is the concrete trace of the translation workflow the readme describes.

Builds, branches and the release channels

The build and release setup has two details that are worth reading carefully if you plan to contribute or to follow the project.

The first is that the CI badge points at the develop branch, and so does the coveralls coverage badge. The default branch of the repository is master, but the continuous integration and the coverage reporting both run against develop. That is the standard arrangement for a project that keeps a stable branch and develops on a separate one, and it tells you that the code on master is the released line while the interesting work happens on develop.

The second is the release list, which mixes two kinds of tag. There is a nightly build, tagged nightly and dated 2026-10-16, and then there are dated version tags, v2026.02 from 2026-02-15 and v2025.09 from 2025-09-12. The naming is date-based rather than semver, which for a field application is a defensible choice: a mapper upgrading in the field does not care about semantic compatibility, they care which month the build is from.

It also means there are two upgrade paths. A user who wants the latest fixes takes the nightly, and a user who wants something stable takes the most recent dated tag. For an app that people install on a phone and then rely on during a survey, having a stable channel is important, because a broken build discovered in the field is worse than a missing feature.

The last push was on 2026-10-16, the same day as the nightly build tag, which is the expected pattern for an automated nightly pipeline rather than a hand-cut release.

The repository also carries an AUTHORS file, a COPYING file, a LICENSES directory, a CONTRIBUTING.md, a .travis.yml from the earlier CI era, and a .github directory holding the current workflows. The presence of both .travis.yml and .github means the CI configuration has moved over time and the old file is still in the tree.

What to check before you install it

There is no manual configuration to speak of in the readme, so the practical evaluation is short.

Install it from F-Droid or Google Play and try the default button layout on a short walk. The defaults are the reference point, and the wiki page on custom button layouts only makes sense once you know what the defaults do and where they are awkward for the kind of surveying you do. Since a button press and its associated metadata become a track point, the defaults also tell you what the app considers worth recording by default.

The second thing to look at is how notes are entered, since note-taking and voice recording are listed as supported and the ergonomics of that will determine whether you actually use them on a survey rather than abandoning the idea after the first hour.

The third is the export, because the whole value of the app is the GPX file that comes out the other end and whether it uploads cleanly to the OpenStreetMap tools you already use. The readme does not describe the export options in detail, so the wiki is where to look.

And the fourth, if you are thinking of contributing, is the contributor guide and the Transifex workflow. An application with a volunteer translation effort is one where a translation contribution is often a more useful contribution than a code change, and Transifex is set up to make that possible without touching the repository.

Editorial conclusion

Adopt OSMTracker for Android if you survey places on foot or on a bike and want the track and the notes about it in one GPX file, because a dedicated tracker does that better than a general fitness app that happens to record a route. Do not adopt it as a general navigation tool, since it is a data collection app rather than a routing one. Before you commit, look at the custom buttons layout documentation, because that is where the app spends most of its flexibility, and note that the nightly build is the freshest channel while the dated tags, currently v2026.02 and v2025.09, are the releases to point users at.

Frequently asked questions

Official sources

1. Issues
2. labexp/osmtracker-android on GitHub
3. License: GPL-3.0
4. README
5. Releases