Messages

In the latest beta version the back button in the theme selector doesn't work for me. I have a rather small screen on my XZ1 Compact (LineageOS 19.1, Android 12). Maybe that's the problem? Tapping the arrow on the upper left doesn't do anything.

Am besten mal den Zwischenspeicher löschen. Manchmal werden aber auch Features entfernt zwischen Kartenversionen. Vor einiger Zeit hatten die LoMaps eine ganze Reihe Sportarten integriert. Die gibt es inzwischen nicht mehr. Einer der Gründe, warum ich mir die Vectormaps inzwischen selbst baue. Damit kann ich das Beste aus beiden Welten (LoMaps, OAM) in einer Karte nutzen.

If it helps, I second the idea to include beergarden in the poiv2.db 😊. There's no trace of an icon anywhere in the app assets yet, so it's a completely new addition. I don't know how hard it is to implement it into the poi system of Locus.

Just download the "Code" as zip (desktop browser mode) and copy the file, where the other themes are located. Depending on your setup the "_themes" folder is a sub-folder of  /Android/media/menion.android.locus/mapsVector or /Android/data/menion.android.locus/mapsVector, either in your internal or external memory.

If you use a theme with poi icons, beergardens are shown on the map. Try Voluntary for instance. That way they are least showing.

Why don't you create a dashboard in Locus, which has a solid black background? The internal dashboard editor should be able to that. It takes some time to understand it, but then you have lots of possibilities to play around with.

Same here.

Externe BRouter App installieren? Dann hast Du eventuell eine neuere Version anstatt die built-in und die sollte mit dem Parameter was anfangen können.

Ok, "your" AI was right. Problem was full heap on my testing device (Xperia XZ1 Compact). On a Xperia 10III the problem isn't present. I'll report back after more thorough testing, but looks like my "fix" needs to be a new phone.

[@TrulloF]

Problem seems to be related to my device's lack of RAM. Tested briefly on another phone with more RAM and the lockup is gone. Time for a new phone 😉.

@TrulloF
oki, let's discuss it in a separate topic. It is starting to be quite complicated. Mainly because I'm unable to simulate any problem ...

Let me try to answer without AI 😁. To reproduce the bug you'd need to be driving, while starting a new navigation from the point menu with an external routing provider activated.
It's also happening right after a fresh start of Locus, doesn't matter.
I created a workaround by starting navigation via the addon button in the point menu (non-AIDL path). Works instant and without lockup. As you have access to my github you could download the latest version, install and test for yourself. I'll test with a different phone these days, but I'm quite sure it's not a memory problem.

Hi Menion,

Thanks for the lockup fixes in 4.35.0 (v1215). Unfortunately I hit the navigate-while-moving freeze again on a drive yesterday (2026-06-26). The signature is different from the earlier blocking-I/O ANRs, so I think one path remains.

Setup: Locus Map 4.35.0 (v1215), external routing addon active (my own ACTION_COMPUTE_TRACK_PROVIDER engine). Started navigation, Locus locked up and never recovered; I had to force-stop.

What the ANR shows (anr_locus_..._2159_navigate-while-moving.txt):

Main thread is Runnable and spinning (not blocked on I/O) — ~33 s of CPU on tid=1, process at 145% user CPU.
It's driven by a GPS update on the UI thread, holding two internal locks:
LocationListener.onLocationChanged
  → r20.d.onLocationChanged → f10.j.c
  → v20.a.f  (locked <0x...> v20.e)
  → ... → zt.c1.onEvent  (event bus)
  → ... → i70.d.j  (locked <0x...> i70.d)
  → com.google.android.gms.internal.ads.ec1.I/L/J → lp0.a0.b
Heap at the time: 4% free, 398MB/417MB, 12.08M objects, with heavy concurrent-copying GC (MarkingPhase sum ~9 s over 34 iterations) — so memory pressure may be feeding the spin.
This is distinct from the 2026-06-21 freezes (those were UI-thread blocking I/O in SQLite NativeDB.prepare / FilterInputStream.read). Here it's a compute/allocation spin in the per-location event handler — every GPS fix re-enters it, which fits "freezes while moving."

I've confirmed the routing addon is not involved: it returned the track in 698 ms and its name appears in no frame of either ANR, and the return leg of the same drive navigated for 24 minutes on the same engine without issue.

A second ANR from the same day (anr_locus_..._0025.txt, UI button press stalling in Resources.getInteger/AssetManager) is attached in case it's related.

Both files are the Locus process section only, with the device build fingerprint and APK install hashes redacted.

Thanks!

Attachments:
anr_locus_2026-06-26_2159_navigate-while-moving.txt
anr_locus_2026-06-26_0025.txt


This report was prepared with the help of Claude Code, which pulled and analyzed the ANR traces and the addon log, and redacted the attachments.

Unfortunately the bug with external routing addons and starting navigation while moving isn't fixed. Locus still locks up while waiting for GPS, even though the signal is already there. Starting navigation via the POI addon button while driving works though as a workaround. I posted the bug in the developer forum.

interesting how deeply you were able to trace the problem and almost correctly  .

How he even sounded like AI output - impressive😬

Of course it's AI output, but if it helps to make the app better, fixing bugs in the process, then I'm gladly guilty of Ai slop. The addon I'm working on is the last missing link for me, to make Locus my only all-in-one navigation solution by providing traffic aware routing with the help of the free TomTom API. Works surprisingly well and is free.

Another 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.