- Welcome to Locus Map - forum.
Locus Map - forum
Recent posts
#1
Troubles & Questions / Cloud Sync not working
Last post by soknet - Today at 00:39:57Hi!
It seems that Cloud Sync has stopped working on my "adventure" phone (Android 7). But it's still working on my everyday phone (Android 17).
It says: "Whoops! It seems you are offline. Please check you internet connection. Code: 14108"
But the phone has a connection, and it even looks like it can update the maps "Routing data".
I've tried reinstalling the app and restarting the phone several times. But nothing seems to have worked.
Please help
Thanks!
It seems that Cloud Sync has stopped working on my "adventure" phone (Android 7). But it's still working on my everyday phone (Android 17).
It says: "Whoops! It seems you are offline. Please check you internet connection. Code: 14108"
But the phone has a connection, and it even looks like it can update the maps "Routing data".
I've tried reinstalling the app and restarting the phone several times. But nothing seems to have worked.
Please help
Thanks!
#2
Developers / Re: Custom router over API
Last post by TrulloF - Yesterday at 21:46:45Another bug report - RoutePlannerActivity ANR while navigating to a point during movement (external routing engine)
Environment
Locus Map 4.34.1.4 (versionCode 1214)
Android 12L (API 32), Sony Xperia XZ1 Compact (LineageOS, rooted)
Routing engine selected: an external ACTION_COMPUTE_TRACK_PROVIDER addon
Reproduced while driving (continuous GPS fixes), GPS valid throughout.
Summary
When an external routing engine is the selected router and the user starts navigation to a point (built-in "Navigate to") while the vehicle is moving, RoutePlannerActivity becomes unresponsive for ~30 s, then the route collapses to a degenerate state (start == destination) and navigation cannot start. Two on-device ANR traces were captured; both are ANRs in the route planner caused by the UI thread blocking on a lock held by the route planner's background work, and the block is re-triggered by incoming GPS location updates.
Steps to reproduce
Select an external routing engine (any ACTION_COMPUTE_TRACK_PROVIDER addon) as the router.
While moving (real GPS, or a moving mock provider delivering frequent fixes), open a saved point and tap Navigate to.
The route planner opens and the UI freezes for ~30 s (ANR). Afterwards start == destination and navigation cannot be started.
Note: the external engine answers the computeTrack request in well under 1 s (measured in the addon), so the delay is not the engine round-trip.
What the ANR traces show
ANR #1 — Subject: Input dispatching timed out (... RoutePlannerActivity (server) is not responding. Waited 5001 ms for FocusEvent)
The UI (main) thread is BLOCKED, waiting to acquire a lock that is held by a background worker thread running the route planner's compute work.
The main thread arrived at that lock from a GPS location callback: LocationListener.onLocationChanged → Locus's location handling → the route planner. So each incoming GPS fix makes the UI thread contend for the same lock the background worker is holding.
The background worker thread is Runnable (actively working) and holds the lock for the duration of a long operation, so the UI thread cannot proceed.
ANR #2 — Subject: Input dispatching timed out (... MainActivityMap (server) is not responding. Waited 5006 ms for MotionEvent)
The UI thread is BLOCKED in RoutePlannerActivity.onDestroy, waiting to acquire the route planner's route-points list, which is still held by the same background worker thread.
I.e. closing the planner also blocks the UI thread because the background compute is not finished / not cancelled and still owns the shared data.
In both cases the addon's own code is not on any thread in the trace - the external engine is idle at the time of the freeze.
Analysis
The route planner runs its compute/processing on a background thread that holds shared locks (the route-points list, and a settings/store object) across a long operation. Meanwhile the UI thread acquires those same locks - on every GPS onLocationChanged, on touch input, and in onDestroy. While driving, location fixes arrive roughly once per second, so the UI thread is repeatedly stalled behind the background worker → input dispatching times out → ANR. With a built-in router the contended window appears short enough to go unnoticed; with an external engine selected the planner stays in this state long enough to ANR, and the route ends up degenerate (start == destination).
Suggested fixes (for your consideration)
Don't hold the route-points list / settings-store lock across the long operation on the planner's background thread; snapshot under the lock, then process lock-free.
Make the planner's GPS onLocationChanged handling non-blocking — don't contend for the compute lock on the UI thread.
Cancel the planner's background work in onDestroy rather than blocking the UI thread on its lock.
The two full ANR traces (~1 MB each) are available on request.
Thank you for looking into that.
Environment
Locus Map 4.34.1.4 (versionCode 1214)
Android 12L (API 32), Sony Xperia XZ1 Compact (LineageOS, rooted)
Routing engine selected: an external ACTION_COMPUTE_TRACK_PROVIDER addon
Reproduced while driving (continuous GPS fixes), GPS valid throughout.
Summary
When an external routing engine is the selected router and the user starts navigation to a point (built-in "Navigate to") while the vehicle is moving, RoutePlannerActivity becomes unresponsive for ~30 s, then the route collapses to a degenerate state (start == destination) and navigation cannot start. Two on-device ANR traces were captured; both are ANRs in the route planner caused by the UI thread blocking on a lock held by the route planner's background work, and the block is re-triggered by incoming GPS location updates.
Steps to reproduce
Select an external routing engine (any ACTION_COMPUTE_TRACK_PROVIDER addon) as the router.
While moving (real GPS, or a moving mock provider delivering frequent fixes), open a saved point and tap Navigate to.
The route planner opens and the UI freezes for ~30 s (ANR). Afterwards start == destination and navigation cannot be started.
Note: the external engine answers the computeTrack request in well under 1 s (measured in the addon), so the delay is not the engine round-trip.
What the ANR traces show
ANR #1 — Subject: Input dispatching timed out (... RoutePlannerActivity (server) is not responding. Waited 5001 ms for FocusEvent)
The UI (main) thread is BLOCKED, waiting to acquire a lock that is held by a background worker thread running the route planner's compute work.
The main thread arrived at that lock from a GPS location callback: LocationListener.onLocationChanged → Locus's location handling → the route planner. So each incoming GPS fix makes the UI thread contend for the same lock the background worker is holding.
The background worker thread is Runnable (actively working) and holds the lock for the duration of a long operation, so the UI thread cannot proceed.
ANR #2 — Subject: Input dispatching timed out (... MainActivityMap (server) is not responding. Waited 5006 ms for MotionEvent)
The UI thread is BLOCKED in RoutePlannerActivity.onDestroy, waiting to acquire the route planner's route-points list, which is still held by the same background worker thread.
I.e. closing the planner also blocks the UI thread because the background compute is not finished / not cancelled and still owns the shared data.
In both cases the addon's own code is not on any thread in the trace - the external engine is idle at the time of the freeze.
Analysis
The route planner runs its compute/processing on a background thread that holds shared locks (the route-points list, and a settings/store object) across a long operation. Meanwhile the UI thread acquires those same locks - on every GPS onLocationChanged, on touch input, and in onDestroy. While driving, location fixes arrive roughly once per second, so the UI thread is repeatedly stalled behind the background worker → input dispatching times out → ANR. With a built-in router the contended window appears short enough to go unnoticed; with an external engine selected the planner stays in this state long enough to ANR, and the route ends up degenerate (start == destination).
Suggested fixes (for your consideration)
Don't hold the route-points list / settings-store lock across the long operation on the planner's background thread; snapshot under the lock, then process lock-free.
Make the planner's GPS onLocationChanged handling non-blocking — don't contend for the compute lock on the UI thread.
Cancel the planner's background work in onDestroy rather than blocking the UI thread on its lock.
The two full ANR traces (~1 MB each) are available on request.
Thank you for looking into that.
#3
Locus Map / Re: Re: [APP] - version 4.34.+...
Last post by Graf Geo - Yesterday at 19:56:39Quote from: Tapio on Yesterday at 16:57:10When pinch-zoomed, it shows some weird parallel track. As if it wants to highlight the zoom area, but distorted. Anyone? The orange-white line.
This marks the section that has been enlarged on the elevation profile. Generally speaking, this is fine, but on sections with sharp bends or tight curves, the orange-and-white markings occasionally overlap the route in an unsightly manner. A bit of fine-tuning might be needed here.
#4
Locus Map / Re: Re: [APP] - version 4.34.+...
Last post by Tapio - Yesterday at 17:38:37@Menion, to unify behaviour and make geotagged photos awesome, you could move the map, just like a click on the graph - if we click a geotagged photo. And if geoposition access is an issue, maybe same file time approach as the selection of photos itself: use closest track timestamp and center track there.
And picture viewer then would be started by long click.
And picture viewer then would be started by long click.
#5
Locus Map / Re: Re: [APP] - version 4.34.+...
Last post by Tapio - Yesterday at 16:57:10Quote from: Graf Geo on June 19, 2026, 23:16:05One of the best features is the option to fix and view the elevation chart separately and zoom in on it directly. At last. 🙂When pinch-zoomed, it shows some weird parallel track. As if it wants to highlight the zoom area, but distorted. Anyone? The orange-white line.
#6
Locus Map / Re: Re: [APP] - version 4.34.+...
Last post by Andrew Heard - Yesterday at 09:16:54regards the nice improvement "track-detail chart now highlights the matching section directly on the map", although not specific to this beta release, would it be worthwhile to disable map rotation and auto-centering, while showing the map based on the chart? I find it confusing when I've just saved a track, but the map preview at top is continually rotating, and when I tap the chart & the map is panned, it will revert to GPS position after auto-centering timeout.
#7
Locus Map / Re: Re: [APP] - version 4.34.+...
Last post by Graf Geo - June 19, 2026, 23:16:05Some really great improvements! 👍👍
One of the best features is the option to fix and view the elevation chart separately and zoom in on it directly. At last. 🙂
And now you can also move attachments (media) in the 'Reorder Sections' menu. Very good!
I'd also like to be able to sort the charts freely in the overview or hide individual ones, but perhaps that's still to come.
Have a lovely weekend! 🌞
One of the best features is the option to fix and view the elevation chart separately and zoom in on it directly. At last. 🙂
And now you can also move attachments (media) in the 'Reorder Sections' menu. Very good!
I'd also like to be able to sort the charts freely in the overview or hide individual ones, but perhaps that's still to come.
Have a lovely weekend! 🌞
#8
Locus Map / Re: Re: [APP] - version 4.34.+...
Last post by Menion - June 19, 2026, 21:04:42Version 4.34.1.5 (19.6.2026)
- add: (SILVER) pinch-zoom and pan the chart right on the track detail screen — no need to open the full chart first
- add: (SILVER) zooming the track-detail chart now highlights the matching section directly on the map
- add: pin the chart on the track detail screen to keep it only visible item + map
- add: (SILVER) GPS accuracy can now be shown as a track chart variable
- add: reorder the sections of the track detail screen (chart, description, waypoints and more) to your preference
- add: optionally stop guidance and navigation automatically after you stop moving, to save battery
- fix: crash when pinch-zooming a track chart at the deepest zoom level
- chg: (SILVER) Geocaching Live Map now works on the Android Auto map and updates as you move
- chg: smoother panning and zooming of track charts on long tracks
- chg: more accurate calorie estimates — terrain (uphill/downhill) now affects the estimate, and reported calories represent the total energy burned during the activity
- chg: per-activity calorie values refreshed to the 2024 Compendium of Physical Activities (walking, running, cycling, skiing and more)
- fix: more accurate calorie estimates when walking, hiking or running uphill
- fix: more accurate heart-rate-based calorie estimates for female user profiles
- fix: missing photo overview when picking coordinates on the map in "Image map calibration"
- fix: crash when entering an invalid value in a BRouter routing-profile parameter
- fix: incorrect visible URL in the track detail
- fix: points without a custom icon now show their folder or default icon in lists instead of a plain dot
- fix: (SILVER) online map overlays such as IGN now load reliably at app start instead of showing a "map is not ready" warning
- add: (SILVER) pinch-zoom and pan the chart right on the track detail screen — no need to open the full chart first
- add: (SILVER) zooming the track-detail chart now highlights the matching section directly on the map
- add: pin the chart on the track detail screen to keep it only visible item + map
- add: (SILVER) GPS accuracy can now be shown as a track chart variable
- add: reorder the sections of the track detail screen (chart, description, waypoints and more) to your preference
- add: optionally stop guidance and navigation automatically after you stop moving, to save battery
- fix: crash when pinch-zooming a track chart at the deepest zoom level
- chg: (SILVER) Geocaching Live Map now works on the Android Auto map and updates as you move
- chg: smoother panning and zooming of track charts on long tracks
- chg: more accurate calorie estimates — terrain (uphill/downhill) now affects the estimate, and reported calories represent the total energy burned during the activity
- chg: per-activity calorie values refreshed to the 2024 Compendium of Physical Activities (walking, running, cycling, skiing and more)
- fix: more accurate calorie estimates when walking, hiking or running uphill
- fix: more accurate heart-rate-based calorie estimates for female user profiles
- fix: missing photo overview when picking coordinates on the map in "Image map calibration"
- fix: crash when entering an invalid value in a BRouter routing-profile parameter
- fix: incorrect visible URL in the track detail
- fix: points without a custom icon now show their folder or default icon in lists instead of a plain dot
- fix: (SILVER) online map overlays such as IGN now load reliably at app start instead of showing a "map is not ready" warning
#9
iOS version / Re: Posssible issue with new i...
Last post by PieroA - June 19, 2026, 17:49:09Hello Petr,
unfortunatelly I experienced again the similar issue.
After pausing a track recording, when I try to resume the recording, even if the position on the map is correct, no track is recorded.
Have to force the app to close and then when re-opening a new track is recorded.
No way to continue the recording on the first track.
This is an issue that occures quite often unfortunatelly, of course only on the IOS Lite version (btw I am using always the latest beta ver).
Please note:
1- All settings are as you suggested.
2- Used Offline Maps
3- Precise position set to ON - Always
4- I kept walking for a significant distance but the app wouldn't restore the recording.
See attachments:
Thank you very much
Piero
Track Part 1 (the one with the issue):Track Part 1
Track Part 2:https://link.locusmap.app/t/nw4mor
unfortunatelly I experienced again the similar issue.
After pausing a track recording, when I try to resume the recording, even if the position on the map is correct, no track is recorded.
Have to force the app to close and then when re-opening a new track is recorded.
No way to continue the recording on the first track.
This is an issue that occures quite often unfortunatelly, of course only on the IOS Lite version (btw I am using always the latest beta ver).
Please note:
1- All settings are as you suggested.
2- Used Offline Maps
3- Precise position set to ON - Always
4- I kept walking for a significant distance but the app wouldn't restore the recording.
See attachments:
Thank you very much
Piero
Track Part 1 (the one with the issue):Track Part 1
Track Part 2:https://link.locusmap.app/t/nw4mor
#10
[DE] - deutschsprachiger Forumsbereich / Re: Problem Import GPX
Last post by 0709 - June 19, 2026, 14:16:54Okay, dann kommen wir doch noch einmal darauf zurück.
Du stellst doch eine persönliche Frage zu etwas, das nur du selbst als Problem empfindest oder meldet. Niemand sonst hat dasselbe in Bezug auf die ,,via"-Punkt-Problematik gemeldet. Du bist also ganz auf dich selbst gestellt. Wenn du dafür mal kurz eine andere App nutzt (was für einen erfahrenen Locus-Nutzer kein Problem sein dürfte), reichen doch 7 Tage aus, um dich selbst davon zu überzeugen – oder ja oder auch nicht.
Wovon soll man sich denn überzeugen? Davon, dass du Locus dan so ermutigst, dieses von Locus ermöglichte Dateisystem ebenfalls wirklich mal zu nutzen. Es wird auch für den Locus-Webplaner und die Brouters-Webseite definitiv so mehr Möglichkeiten bieten. Dazu kommt noch automatisch ein schöne, kompakte Export von die GPX (poi) wpt dateien als zusätzlicher Pluspunkt. Wenn du als Nutzer davon überzeugt bist, kannst du schon mal mithelfen, diesen ins Stocken geratenen Locus ,,Entwicklungswagen" wieder in Gang zu bringen. Nicht überzeugt? Möglich, doch ich würde das wirklich sehr stark bezweifeln. Übrigens wird sich ihre problem automatisch lösen, sobald der Bikerouter auch den versprochenen Export generiert.
Du hast selbst im Bikerouter-Forum bemerkt, dass dies fast schon fertig ist. Manchmal ist es auch gut, so (gestützt durch eigene Erfahrungen) hier kurz mit anzuschieben. Weder ich noch du noch andere können jedoch allzu anspruchsvoll sein. Der Bikerouter ist Freeware, also alles kostenlos, daher ist es sicherlich wünschenswert, brav zu bleiben ganz brav.
QuoteNur ist das für andere, die hier mitlesen und kein gerootetes Gerät haben, nicht von Nutzen.
Du stellst doch eine persönliche Frage zu etwas, das nur du selbst als Problem empfindest oder meldet. Niemand sonst hat dasselbe in Bezug auf die ,,via"-Punkt-Problematik gemeldet. Du bist also ganz auf dich selbst gestellt. Wenn du dafür mal kurz eine andere App nutzt (was für einen erfahrenen Locus-Nutzer kein Problem sein dürfte), reichen doch 7 Tage aus, um dich selbst davon zu überzeugen – oder ja oder auch nicht.
Wovon soll man sich denn überzeugen? Davon, dass du Locus dan so ermutigst, dieses von Locus ermöglichte Dateisystem ebenfalls wirklich mal zu nutzen. Es wird auch für den Locus-Webplaner und die Brouters-Webseite definitiv so mehr Möglichkeiten bieten. Dazu kommt noch automatisch ein schöne, kompakte Export von die GPX (poi) wpt dateien als zusätzlicher Pluspunkt. Wenn du als Nutzer davon überzeugt bist, kannst du schon mal mithelfen, diesen ins Stocken geratenen Locus ,,Entwicklungswagen" wieder in Gang zu bringen. Nicht überzeugt? Möglich, doch ich würde das wirklich sehr stark bezweifeln. Übrigens wird sich ihre problem automatisch lösen, sobald der Bikerouter auch den versprochenen Export generiert.
Du hast selbst im Bikerouter-Forum bemerkt, dass dies fast schon fertig ist. Manchmal ist es auch gut, so (gestützt durch eigene Erfahrungen) hier kurz mit anzuschieben. Weder ich noch du noch andere können jedoch allzu anspruchsvoll sein. Der Bikerouter ist Freeware, also alles kostenlos, daher ist es sicherlich wünschenswert, brav zu bleiben ganz brav.