Trail Sense: an offline sensor toolkit for hiking, built around a rule of no network
An Android app that uses your phone's sensors to assist with wilderness treks or survival situations.
At a glance
- What is it?
- An Android app that turns the barometer, magnetometer and GPS already in your pocket into maps, weather forecasts and astronomy tables, and refuses to use the internet at all.
- Who is it for?
- Trail Sense is at its best when you accept its premise, which is that a phone in the backcountry has no signal and should not need one. The barometer work, the beacon map and the astronomy tables are the parts that earn the install, and the per-permission degradation notes are unusually honest about what you lose when a permission is denied.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 14 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 24, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A design constraint stated before the feature list
The first line of the project description is a constraint rather than a benefit: the app is designed for entirely offline use. The Goals section turns that into four rules, and the first is absolute. Trail Sense must not use the internet in any way, because the author wants the whole app usable when there is no connection. The second rule is more unusual, which is that features should make use of the sensors on the phone rather than relying on stored information such as guides. The third asks that features be based on peer-reviewed science or verified against real world data.
Those three rules explain almost every design decision in the app. There is no account, no sync and no telemetry, because each would require the network. The privacy section follows the same logic: location information never leaves the device, and the app states plainly that it does not use the internet at all. What is stored is local and small. Altitude and pressure history for the last 48 hours goes into local app storage and exists only so weather forecasts can be computed. The last known location is kept in app preferences for faster startup and for when the GPS cannot get a fix. Beacons and paths keep their coordinates in a local SQLite database. Clearing app storage removes all of it.
The fourth goal links to a wiki page of use cases rather than to a feature list, which is a reasonable way to keep the scope honest. The README itself defers most detail to a user guide hosted on the author's site and also reachable from inside the app on the Tools tab, plus a technical blog categorised by project.
Maps you build yourself, including photographing a paper one
The feature list is short enough to read straight through: place beacons and navigate to them, follow paths, retrace your steps with backtrack, use a photo as a map, plan what to pack, get alerted before the sun sets, predict the weather, and use the phone as a flashlight. Every one of those is a sensor job rather than a data download job, which is the point.
The beacon and path system is the core navigation feature. You drop a marker where you parked, or where a junction is ambiguous, and the app gives you a bearing and a distance. Because the coordinates live in local SQLite, the whole system keeps working with the radio off. Backtrack records your route and replays it, which is the feature you would reach for after a walk that went badly in low visibility.
Using a photo as a map is the unusual one. Rather than requiring a downloaded tile set, the app accepts a photograph of a paper map, a trail sign, a whiteboard sketch or a page of notes, and works out the corners so it can be used as an underlay. The 8.1.1 release added automatic detection of corners on new photo maps, along with a setting for external trail map files, and 8.2.0 added an option to export trail maps plus country and state or province boundaries where the data covers them. The release notes also mention improving map tile memory usage, which suggests the map side is the part under most active engineering pressure.
The topics list on the repository matches this scope closely: altimeter, barometer, compass, gps, navigation, offline, sensors, survival, weather and wilderness. Offline maps, the map view, navigation and astronomy are the four areas named for improvement in the 2026 roadmap.
Weather forecast from a pressure history, not from a server
Predicting the weather without a network means using the barometer, and the app is specific about what it keeps: 48 hours of altitude and pressure history in local storage. With that window it can compute a pressure trend and derive a forecast, and it calibrates against sea level pressure using your location.
The permission documentation is where this feature's real limits appear. On Android 14 and later, backtrack and weather become unavailable if location permission is denied, and the reason given is an operating system constraint rather than an application choice. That is worth understanding before install, because the forecast is not an independent feature bolted onto the map tools. It depends on knowing roughly how high you are and where you are, and the modern Android permission model makes that harder to grant in the background.
There is also a built-in way to fake your position. If you deny location access you can set a mock location under Settings, Sensors, GPS, which lets you exercise the astronomy and sunset calculations from anywhere. The app accepts that trade openly instead of hiding it.
The astronomy tools are the other half of the sensor story, combining date, time and position to produce moon phase, sun and sunrise times, and event tables. Release 8.1.0 and 8.1.1 both touched this area, adding accurate icons for the moon and for eclipses.
Permission-by-permission behavior, stated plainly
Most apps bury this. Trail Sense has a Permissions section that lists each sensitive permission, what it is for, and what specifically breaks when you refuse it.
POST_NOTIFICATIONS covers backtrack, weather, sunset alerts, astronomy events and the water boil timer. Denied, alerts do not appear and some services may misbehave depending on the device manufacturer. ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION cover navigation, weather calibration and astronomy, and the Android 14 restriction above applies here. ACCESS_BACKGROUND_LOCATION exists so sunset alerts keep working when the app is not in the foreground. Without it, if you travel without opening Trail Sense, the sunset and sunrise times will likely be wrong. ACTIVITY_RECOGNITION lets the phone use its pedometer, which feeds the step counting tools.
The pattern across all four is that the degradation is described rather than hidden, which is more information than most users get before granting broad location access to a hiking app. It also tells you which permissions are actually load-bearing for the features you care about. If you only want the astronomy tables, coarse location is enough.
A separate point about updates matters for anyone running the app in the field. Every release is on F-Droid, Google Play and Obtainium, with a Weblate badge for translations, so the app is not tied to a single distribution channel.
Field Guide and Survival Guide, and why one file sits apart
Trail Sense carries two bundled reference works. The Survival Guide is long-running content that gets periodic text updates, and releases such as 8.1.1 list content updates alongside code changes. The Field Guide is the one that receives feature work: 8.2.0 added multi-image attachments to a page, colored sighting map markers by classification, scientific names, an option to hide built-in pages, and a Record Sighting quick action in 8.1.0.
The repository tree contains both `LICENSE` and `SURVIVAL_GUIDE_LICENSE.md`, which tells you the bundled guide text is not covered by the same terms as the code. That is a deliberate separation and worth reading before repackaging. The tree also shows `guides/` and `survival-guide-book/`, so the source for that text is in the repository rather than baked into binary assets.
The Field Guide also connects to the geocaching workflow, which is one of the four activities the feature list names alongside hiking, backpacking and camping. A sighting recorded with a classification and a scientific name, plotted on the map, is a field notebook that happens to be georeferenced.
The README links to a print edition of the Survival Guide as well, so the same content exists in and out of the app for people who would rather not depend on a battery.
Release rhythm and what the repository reveals about maintenance
Versions move steadily: 8.1.0 on 2026-07-23, 8.1.1 on 2026-07-28, and 8.2.0 on 2026-09-04, with the last push to the repository on 2026-09-23. That is a project with someone actively working on it, and the release notes carry per-release detail files under `release-notes/` rather than living only in the GitHub release body.
One detail is worth flagging because it will confuse anyone reading the releases page. The bodies of 8.1.0 and 8.1.1 are effectively identical, listing the same photo map corner detection, pedometer history, astronomy icons and Material 3 work. The two tags are five days apart. Read them as one change set that got split across two releases rather than as two independent feature drops.
The engineering scaffolding in the tree is more substantial than most hobby Android projects. There is a CI workflow badge for Android builds, a separate test workflow, a nightly build, a `release.py`, `fastlane/` metadata with the store listing images, and `staging-builds-helper.sh`. The repository also carries `AGENTS.md`, `CLAUDE.md` and a `.claude/` directory, which is an unusual thing to see in a mobile app tree and suggests parts of the work are driven through coding agents.
The 2,891 stars and 181 forks sit against 314 open issues. For an app of this size that ratio is not alarming on its own, since a hiking app collects device-specific bug reports about background location and notification handling that are hard to close centrally. It does mean the release notes are the thing to read before updating in the field.
Editorial conclusion
Trail Sense is at its best when you accept its premise, which is that a phone in the backcountry has no signal and should not need one. The barometer work, the beacon map and the astronomy tables are the parts that earn the install, and the per-permission degradation notes are unusually honest about what you lose when a permission is denied. Start with the Field Guide and the beacon tools, add background location only if you actually want sunset alerts while the phone is in a pocket, and treat the 314 open issues as a signal to read the release notes before upgrading rather than as a reason to avoid it.
Frequently asked questions
Does Trail Sense need an internet connection?
No, and that is a stated design rule rather than a limitation. The project's Goals section says the app must not use the internet in any way, because the author wants it fully usable with no connection. Map data, field guide content, your beacons and your recorded paths all live locally.
How does Trail Sense forecast weather without internet access?
It keeps the last 48 hours of altitude and barometric pressure history in local app storage and derives a pressure trend from it, calibrating against sea level pressure using your location. On Android 14 and later this feature stops working if location permission is denied, which the app attributes to an operating system constraint.
What happens if I deny location permission to Trail Sense?
You can mock your own position under Settings, Sensors, GPS, which keeps the astronomy and sunset calculations usable. On Android 14 and later, backtrack and weather become unavailable, and without background location the sunset and sunrise alert times will likely be inaccurate if you travel without opening the app.
Can Trail Sense work with a printed map?
Yes. One of the documented features is using a photo as a map, so you can photograph a paper map, a trail sign or a sketch and use it as an underlay. Release 8.1.1 added automatic detection of corners on new photo maps, and there is a setting for external trail map files.
Where is Trail Sense's map and field guide data stored?
On the device. Beacons and paths keep their coordinates in a local SQLite database, and all of it is cleared when you clear app storage or uninstall. The Survival Guide has its own license file in the repository, separate from the code license, because the bundled text is not covered by the same terms.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/kylecorry31-trail-sense)