GPSLogger: an Android GPS logging app that writes GPX, KML, CSV and NMEA

What GPSLogger is for, and who it is not for

GPSLogger is an Android application that writes GPS information to files. The README lists the formats as GPX, KML, CSV, NMEA and a custom URL, and the upload targets as SFTP, OpenStreetMap, Google Drive, Dropbox and email. That combination tells you the intended user: someone who wants a durable record of where a device went, in a format other tools already read, rather than a live tracking dashboard.

The distinction that matters here is between a logger and a tracker. A logger records positions and keeps them, usually on the device itself. A tracker reports positions to someone else in near real time. GPSLogger can push to remote endpoints, but its centre of gravity is the local file. If your requirement is a map that updates while the device moves, and someone watching it, this is the wrong shape of tool. If your requirement is a GPX file you can load into QGIS, a photo geotagger or a route editor afterwards, it fits.

The project states its goal plainly: "This app aims to be as battery efficient as possible." That single sentence explains most of the design decisions below, including the ones that will annoy you.

How the logging and upload pipeline is put together

The repository is a Gradle Android project. The top level holds build.gradle, settings.gradle, gradle.properties and the gradle wrapper, with the application code under the gpslogger/ module and per-sender classes such as gpslogger/src/main/java/com/mendhak/gpslogger/senders/osm/OpenStreetMapManager.java. That layout tells you the architecture: a core logging service plus a set of sender implementations, one per upload destination.

The README describes the app as "composed of a few main components" and then references a design diagram at assets/gpslo..., which is truncated in the text available. What can be confirmed from the file paths and the feature list is the split between recording and sending. Recording produces the file in the chosen format. Sending takes that file and hands it to a destination. Because each destination is its own class, adding a transport does not change the logging path.

The custom URL format is the escape hatch. Instead of picking a fixed provider, you can have the app send to an endpoint you control. For anyone running their own collector, that is the option worth knowing about, and it is the reason GPSLogger shows up in self-hosted home automation setups rather than only in mapping workflows.

Installing GPSLogger and taking a first recording

The README gives two installation routes. The first is F-Droid, where the package is com.mendhak.gpslogger. The second is the GitHub releases page, where you download the APK directly. There is no Play Store link in the README.

If you take the direct APK route, the README says a PGP signature, a Cosign bundle and an SHA256 checksum accompany each .apk, and it shows how to check them. The example uses gpslogger-132.apk as the filename, so substitute the version you actually downloaded.

gpg --recv-key 6989CF77490369CFFDCBCD8995E7D75C76CBE9A9
gpg --verify gpslogger-132.apk.asc

The README labels the Cosign path experimental and says the exact command should be in the release notes. The form it gives is:

cosign verify-blob gpslogger-132.apk \
--bundle gpslogger-132.apk.cosign.bundle --new-bundle-format \
--cert-oidc-issuer https://token.actions.githubusercontent.com \
--cert-identity https://github.com/mendhak/gpslogger/.github/workflows/generate-release-apk.yml@refs/head/master

For the checksum, the README shows sha256sum -c against a .SHA256 file:

sha256sum -c gpslogger-132.apk.SHA256

Once installed, the first real use is to pick an output format and start logging. The README does not walk through the in-app screens, so the honest instruction is: choose your format from the GPX, KML, CSV, NMEA or custom URL options, then start the logging service. What you should end up with is a file on the device in that format, and, if you configured a sender, a copy at the destination.

Building from source means provisioning your own API credentials

If you want to compile GPSLogger rather than install the APK, the README assumes Ubuntu with Android Studio and says other systems should be roughly similar. You clone the repository and pull the SDK packages through sdkmanager:

git clone git://github.com/mendhak/gpslogger.git
echo y | $HOME/android-sdk/tools/bin/sdkmanager 'tools'
echo y | $HOME/android-sdk/tools/bin/sdkmanager 'platform-tools'
echo y | $HOME/android-sdk/tools/bin/sdkmanager 'build-tools;26.0.2'
echo y | $HOME/android-sdk/tools/bin/sdkmanager 'platforms;android-27'

Then you point the build at your SDK with a local.properties file:

echo "sdk.dir=/home/mendhak/Programs/Android" > local.properties

This is where the real cost sits. The optional senders are not preconfigured. For Dropbox you create your own app on the Dropbox developers page, then place the credentials in ~/.gradle/gradle.properties as GPSLOGGER_DROPBOX_APPKEY and GPSLOGGER_DROPBOX_APPSECRET, and change the manifest scheme to db- followed by your app key. For OpenStreetMap you register an OAuth2 application, uncheck the Confidential Application box because it is a mobile app, and paste the resulting Client ID into OpenStreetMapManager#getOpenStreetMapClientID(). For Google Drive you create a Google Cloud project, enable the Drive API, add the https://www.googleapis.com/auth/drive.file scope, and create Android OAuth credentials under the package name com.mendhak.gpslogger with a SHA-1 fingerprint from keytool -keystore ~/.android/debug.keystore -list -v.

Three providers, three separate credential registrations, before you can test a single upload. That is the honest price of building this yourself instead of installing the APK.

Where GPSLogger stops being the right tool

The clearest limitation is platform. The repository is an Android application written in Java, the README calls it an Android app, and the topics list is android, android-sdk, java. There is no iOS target described anywhere in the README or the repository layout. If your fleet mixes iPhones and Android devices, GPSLogger covers only half of it, and you will need a second tool for the other half.

The second limitation is delivery guarantees. The README presents uploads to SFTP, OpenStreetMap, Google Drive, Dropbox and email as options, and lists them alongside the file formats without describing retry behaviour, offline queuing or conflict handling. The README does not document what happens to a pending upload when the device loses connectivity for hours. If your workflow requires that every recorded point arrives at the server, verify that behaviour on your own device before you depend on it.

The third is that recording accuracy and battery life trade against each other. The stated aim of being as battery efficient as possible implies the app will not sample aggressively by default. A project that needs dense, high-frequency traces for vehicle telemetry should expect to tune settings and accept the battery cost, and should check whether the resulting drain is acceptable on the hardware in question.

GPSLogger versus OwnTracks: file on the device versus message to a broker

OwnTracks is the comparison people reach for, and the difference is architectural rather than a matter of feature lists. OwnTracks is built around publishing location as messages to an MQTT broker, which makes the server the centre of the system: the broker holds state, and a subscriber decides what to do with each position. GPSLogger is built around writing a file in a mapping format and optionally shipping that file somewhere.

That changes what you have to operate. An OwnTracks deployment means running and securing a broker, and the value you get is live position plus history reconstructed from messages. A GPSLogger deployment means no server at all unless you want one, and the value you get is a GPX or KML file that existing desktop and web tools already import. If your downstream work is geotagging photos, drawing routes or loading traces into a GIS project, the file is the deliverable and a broker is an extra component you would have to maintain for no benefit.

The reverse also holds. If you want a map that updates as the device moves, and you want that without polling a file store, GPSLogger's file-first model is working against you. The custom URL sender narrows the gap by letting you POST to your own endpoint, but it is still the app pushing records out, not a broker holding a session.

Licence, verification and the cost of staying current

GPSLogger is licensed under GPL v2, per the README's licence line, with third party licences listed in assets/text/opensource.md and a privacy policy in assets/text/privacypolicy.md. The repository metadata reports the licence as NOASSERTION, which is GitHub's way of saying it could not classify the licence file automatically; the README itself is explicit that it is GPL v2. For anyone redistributing a modified build, GPL v2 is a copyleft licence and the obligations attach to distribution. That is a factual statement about the licence text, not legal advice, and a fork intended for internal use raises different questions from one published to a store.

On maintenance, the last push to the default branch was on 2026-09-20, and the most recent release listed is v138-rc2 from the same day, following v138-rc1 on 2026-08-28 and v137 on 2026-08-14. The repository is not archived. The cadence visible in the release list is a steady stream of release candidates rather than long silences, which is what you would expect from a project that keeps its Android build current against a moving SDK.

Upgrade cost is mostly the Android toolchain, not the app. The README's setup instructions pin build-tools;26.0.2 and platforms;android-27 and android-25, which are old API levels; a contributor working from those instructions on a current Android Studio will be reconciling an outdated toolchain with whatever the current build.gradle actually requires. That gap between the README's documented setup and the build files is the first thing to check if a fresh clone fails to configure.

Editorial conclusion

Adopt GPSLogger if you need an Android device to write its own location trail to GPX, KML, CSV or NMEA and you accept that uploads are best-effort. Do not adopt it if you need iOS support, a server-side dashboard, or guaranteed delivery of every point. Before installing, check which release asset you are downloading and verify it with the published PGP signature, Cosign bundle or SHA256 checksum, because the README points at F-Droid and the releases page but does not document a rollback path between versions.

Frequently asked questions

Official sources

1. Issues
2. mendhak/gpslogger on GitHub
3. Project website
4. README
5. Releases