Environment
- OSMTracker version: 2026.02.12 (versionCode 73, installed 2026-05-15)
- Android version: 16
- Device: Google Pixel 7 Pro
- OSMTracker package:
net.osmtracker (Laboratoria experimental fork)
- OSMTracker build config: compileSdk 35, targetSdk 35, minSdk 25 (Android 7)
ACCESS_MEDIA_LOCATION required since: Android 10 (API 29) — affects all modern devices
Note: the original OSMTracker app (me.guillaumin.android.osmtracker, v0.6.11) does declare ACCESS_MEDIA_LOCATION. This permission was present in the original codebase and appears to have been dropped when the Laboratoria fork was created.
Summary
Note - written by Claude Code based on lots of prompting and fine-tuning by me. Seems quite plausible, but I'm no expert. Let me know if you find any garbage here. Many thanks....
When importing a photo from the gallery, OSMTracker creates a waypoint using the current GPS position rather than the photo's actual location. Additionally, the photo copy stored in the track folder has its GPS EXIF zeroed out. Both problems share the same root cause: ACCESS_MEDIA_LOCATION is not declared in the manifest, so Android's MediaStore silently redacts GPS data from photos before OSMTracker ever sees them.
Steps to Reproduce
- Walk to a mural (or any point of interest) and photograph it with the system camera app
- Walk away to a different location
- In OSMTracker, tap the gallery import button and select the photo
- Export the GPX track
Result: The waypoint is placed at your current position (step 2), not where the photo was taken (step 1). The copy of the photo in the track folder has all GPS EXIF fields zeroed out, even though the original in DCIM has correct GPS data.
Expected: The waypoint should be placed at the photo's GPS coordinates. At minimum, the photo copy should preserve the original GPS EXIF.
Root Cause
On Android 10+, when an app accesses photos via ContentResolver/MediaStore without declaring ACCESS_MEDIA_LOCATION, the OS automatically redacts GPS EXIF data — zeroing out latitude, longitude, altitude, timestamp and direction fields — before returning the file content to the app. This is an Android privacy protection (see Android docs).
ACCESS_MEDIA_LOCATION is absent from OSMTracker's AndroidManifest.xml. The gallery import flow in TrackLogger.java uses ACTION_GET_CONTENT → getRealPathFromURI() → FileSystemUtils.copyFile(). By the time copyFile runs, MediaStore has already zeroed the GPS fields. The copy is faithful — but it's copying already-redacted data.
This was confirmed by md5sum: the original photo and the OSMTracker copy are the same file size (GPS IFD structure preserved, byte count unchanged) but different checksums (GPS values zeroed). exiftool shows GPS Version ID: 0.0.0.0 and empty lat/lon in the copy vs. correct coordinates in the original.
Because the photo copy has no GPS, GPSLogger.java's waypoint handler has no EXIF coordinates to fall back on — it calls getLastKnownLocation(GPS_PROVIDER), which is the current position, not the photo location.
Relationship to Earlier Issues
Issue #331 ("Improvement: add EXIF data to images") was closed with the comment "change the setting of your camera app to allow it to save locations in EXIF data." This misdiagnosed the problem: the camera app IS saving GPS to EXIF correctly — the data exists in the original. The issue is that OSMTracker's copy loses it due to the missing permission. The second commenter on #331 identified the right symptom but the thread was already closed.
Issue #589 ("osmtracker captured the location for Photo waypoints when you press OK not when you press the button") is a related but distinct bug: for the in-app camera, the waypoint timestamp is captured at confirmation rather than shutter time, causing drift when the user is moving. That's a timing issue in the camera flow. This issue is about gallery import losing the photo's location entirely, not timing drift.
Fix
1. Declare the permission in AndroidManifest.xml:
<uses-permission android:name="android.permission.ACCESS_MEDIA_LOCATION"/>
2. Use the unredacted URI in TrackLogger.java around the REQCODE_GALLERY_CHOSEN handler. Instead of resolving to a file path and copying, open the URI directly with MediaStore.setRequireOriginal() to get unredacted content:
Uri originalUri = MediaStore.setRequireOriginal(data.getData());
InputStream in = getContentResolver().openInputStream(originalUri);
// copy `in` to destFile, read ExifInterface from destFile for GPS coords
3. Read EXIF GPS for the waypoint. After copying, read ExifInterface.TAG_GPS_LATITUDE / TAG_GPS_LONGITUDE from the copied file and use those as the waypoint coordinates instead of lastLocation. Fall back to lastLocation only if EXIF GPS is absent.
Impact
Any user who photographs subjects and then imports from the gallery — a common workflow for murals, signs, shop fronts, building features — gets silently wrong waypoint locations. The error can be tens to hundreds of metres depending on how far the user walked between taking the photo and importing it. The GPS data exists in the original photo and is recoverable, but OSMTracker's copy is permanently degraded.
Environment
net.osmtracker(Laboratoria experimental fork)ACCESS_MEDIA_LOCATIONrequired since: Android 10 (API 29) — affects all modern devicesNote: the original OSMTracker app (
me.guillaumin.android.osmtracker, v0.6.11) does declareACCESS_MEDIA_LOCATION. This permission was present in the original codebase and appears to have been dropped when the Laboratoria fork was created.Summary
Note - written by Claude Code based on lots of prompting and fine-tuning by me. Seems quite plausible, but I'm no expert. Let me know if you find any garbage here. Many thanks....
When importing a photo from the gallery, OSMTracker creates a waypoint using the current GPS position rather than the photo's actual location. Additionally, the photo copy stored in the track folder has its GPS EXIF zeroed out. Both problems share the same root cause:
ACCESS_MEDIA_LOCATIONis not declared in the manifest, so Android's MediaStore silently redacts GPS data from photos before OSMTracker ever sees them.Steps to Reproduce
Result: The waypoint is placed at your current position (step 2), not where the photo was taken (step 1). The copy of the photo in the track folder has all GPS EXIF fields zeroed out, even though the original in DCIM has correct GPS data.
Expected: The waypoint should be placed at the photo's GPS coordinates. At minimum, the photo copy should preserve the original GPS EXIF.
Root Cause
On Android 10+, when an app accesses photos via ContentResolver/MediaStore without declaring
ACCESS_MEDIA_LOCATION, the OS automatically redacts GPS EXIF data — zeroing out latitude, longitude, altitude, timestamp and direction fields — before returning the file content to the app. This is an Android privacy protection (see Android docs).ACCESS_MEDIA_LOCATIONis absent from OSMTracker'sAndroidManifest.xml. The gallery import flow inTrackLogger.javausesACTION_GET_CONTENT→getRealPathFromURI()→FileSystemUtils.copyFile(). By the timecopyFileruns, MediaStore has already zeroed the GPS fields. The copy is faithful — but it's copying already-redacted data.This was confirmed by md5sum: the original photo and the OSMTracker copy are the same file size (GPS IFD structure preserved, byte count unchanged) but different checksums (GPS values zeroed).
exiftoolshowsGPS Version ID: 0.0.0.0and empty lat/lon in the copy vs. correct coordinates in the original.Because the photo copy has no GPS,
GPSLogger.java's waypoint handler has no EXIF coordinates to fall back on — it callsgetLastKnownLocation(GPS_PROVIDER), which is the current position, not the photo location.Relationship to Earlier Issues
Issue #331 ("Improvement: add EXIF data to images") was closed with the comment "change the setting of your camera app to allow it to save locations in EXIF data." This misdiagnosed the problem: the camera app IS saving GPS to EXIF correctly — the data exists in the original. The issue is that OSMTracker's copy loses it due to the missing permission. The second commenter on #331 identified the right symptom but the thread was already closed.
Issue #589 ("osmtracker captured the location for Photo waypoints when you press OK not when you press the button") is a related but distinct bug: for the in-app camera, the waypoint timestamp is captured at confirmation rather than shutter time, causing drift when the user is moving. That's a timing issue in the camera flow. This issue is about gallery import losing the photo's location entirely, not timing drift.
Fix
1. Declare the permission in
AndroidManifest.xml:2. Use the unredacted URI in
TrackLogger.javaaround theREQCODE_GALLERY_CHOSENhandler. Instead of resolving to a file path and copying, open the URI directly withMediaStore.setRequireOriginal()to get unredacted content:3. Read EXIF GPS for the waypoint. After copying, read
ExifInterface.TAG_GPS_LATITUDE/TAG_GPS_LONGITUDEfrom the copied file and use those as the waypoint coordinates instead oflastLocation. Fall back tolastLocationonly if EXIF GPS is absent.Impact
Any user who photographs subjects and then imports from the gallery — a common workflow for murals, signs, shop fronts, building features — gets silently wrong waypoint locations. The error can be tens to hundreds of metres depending on how far the user walked between taking the photo and importing it. The GPS data exists in the original photo and is recoverable, but OSMTracker's copy is permanently degraded.