Recent versions of osmin crashes?

[Framstag]

I have a Pixel 7 using Android 14
Recent version of osmin crash (somehow)

• I can start osmin
• I can see the "download maps" dialog (white window with single option in the center) on start for 1-2 seconds
• Windows closes
• I can still see osmin running in the background via pull-down android menu (active apps). I assume this is a Qt location background process?
• I can bring osmin to the foreground (or is it an implicit restart?) via the android app/window overview, showing me the map download option
• Choosing the option makes the windows disspear after a possible dialog switch (<1 second, "Loading maps...")
• Selection the app via app overview gets back to about "Download maps" overview

I had older version of osmin with older maps. Problems started with the version which switched to newer map format. Deinstalled osmin and reinstalled it. Did not change anything. All requested android access right have been assigned to the app.

After multiple tries I'm now able to enter the download menu and download one map. osmin however closes on finish. Starting osmin now shows map on location, but close again after <1 second.

Looks like something in the background runs into errors?

I cannot see Android/data/io.github.janbar.osmin via USB, so it looks like I even cannot look for logs...

[janbar]

I never tested the app on Android 14. I guess it could be the root cause. To be tested with the emulator ...

[janbar]

Well, on this OS (Android 14) the system process named "vold" kills the app !!!

2023-10-28 21:14:43.589 9204-9252/io.github.janbar.osmin D/EGL_emulation: app_time_stats: avg=220.94ms min=7.23ms max=963.89ms count=5
2023-10-28 21:14:44.590 144-187/? W/vold: Found symlink /proc/9204/fd/132 referencing /storage/emulated/0/Android/data/io.github.janbar.osmin/files/resources/world/water.idx
2023-10-28 21:14:44.591 144-187/? W/vold: Found symlink /proc/9204/fd/133 referencing /storage/emulated/0/Android/data/io.github.janbar.osmin/files/Maps/europe-france-ile-de-france-20230923-092549/water.idx
2023-10-28 21:14:44.594 144-187/? W/vold: Sending Interrupt to pid 9204 (ub.janbar.osmin, /system/bin/app_process64)
2023-10-28 21:14:44.617 577-1117/? I/ImeTracker: io.github.janbar.osmin:7fa5b6f4: onRequestHide at ORIGIN_SERVER_HIDE_INPUT reason HIDE_REMOVE_CLIENT
2023-10-28 21:14:44.617 577-1117/? I/ImeTracker: io.github.janbar.osmin:7fa5b6f4: onCancelled at PHASE_SERVER_SHOULD_HIDE
2023-10-28 21:14:44.617 577-1901/? I/ActivityManager: Process io.github.janbar.osmin (pid 9204) has died: fg  TOP 

That is a new JOKE from google. Seems the reason is the app has few opened files on the storage !!!

[janbar]

For instance the app works perfectly on Android 12.
Some changes in the new OS Android 14 breaks the app. The root cause can be a new required permissions or something google want to restrict. Some investigations need to be completed to point the issue and finally to find a fix.
@Framstag, is it a new device or have you upgraded it for the fun ?

[Framstag]

The Pixel 7 was bought last year. It was delivered with either Android 12 (with quick update to 13) or 13. This is the normal major OS update to 14 as part of the warranty and security update cycle. The update happened a few week ago.

[Framstag]

Do you have more detailed information? It this a problem in libosmscout or something that has to be fixed in the app? How? I'm of course wiilling to test,,,

[Framstag]

I just took a look at OSMAnd an Organic Maps. Both still seem to store their data in "User data". Since they likely have a different data layout, it may be possible that they actually open and close on each access (the less files and the simpler our file structure is, the easier this likely is). I question what linux will do if I open and close a file permanently on each access. This like does not make things faster (but how much slower?).

We would have to add some kind of central interface to "hibernate" and "wakeup" the individual database files, to make at least sure that multiple accesses can be batched at least.

There is no other way?

[Framstag]

I did not found anything by searching about this. Possible the app is doing file access in a special app-lifecyle where it is not allowed (Android 14 still improved power management).

I'm no Android developer, though...

[janbar]

Requires refactoring of the storage location...

• App files (gpx, favorites, tracker log, config json) can stay in place as those file handles aren't hold.
• libosmscout requires to hold database files during the life of the instance. So all map databases and resources will be stored in the internal storage of the app, which has no restriction for now.

Also I will review the storage management for others platforms and probably all files will be located in one place i.e $HOME/osmin/.

[janbar]

@Framstag , I released the new version 1.11.0. It should resolve this.
Testing android 14 with the emulator, I found the DPI smaller than before. Can you confirm that ?

[Framstag]

Application still does not correctly start. Same effects as before. Deinstalled old installation before.

How can I help?

[janbar]

aahh, it is a mistake from me. I uploaded the old apk (1.10.6).

I uploaded the right apk, just now.

[Framstag]

Ok. It works again. Thank you!

I do not see an obvious DPI change in the map rendering.

Menu text might be a little bit bigger than before. I'm unsure. It is definitely not too big.

[eleius]

So all map databases and resources will be stored in the internal storage of the app, which has no restriction for now.

Is this a requirement for new versions of osmin or does it only affect Android 14 users?

[janbar]

@eleius , this affect all Android users using the new version from 1.11.0. That doesn't impact a "normal" user.
But if you build your own maps using the "Import" tool of osmscout, you cannot upload them into the internal storage.

[Framstag]

I assume though that custom maps could be re-supported by implementing an explicit upload feature in the app?

Note, that the libosmscout importer currently is a command line application but the design should allow wrapping it in a desktop application (the importer is a library, the command line interface is just a small wrapper). This way it is possible to write a desktop Qt application, start an import via the app and make the app "return" a zip archive containing the database. This zip then could be uploaded via the application, unziped and moved to its final place?

Such a desktop application could be part of upstream, to support other libosmscout-based applications, too.

[janbar]

Yep, that the solution. An other simple way may be a "local" repo where user can upload custom maps. I will try that adding a "local" provider in the json file.