Problem loading Mapsforge .map files on Android 10 (api 29)

Issue Type

[ ] Question [x] Bug [ ] Improvement [ ] Build system related [ ] Performance [ ] Documentation

Description and/or steps/code to reproduce the problem

I’m using Osmdroid in PhoneTrack-Android and everything works fine for Android <= 9.

I can’t figure out a way to load Mapsforge .map file in Osmdroid on Android 10. I guess it’s caused by the new way of managing storages in Android 10. I saw that things were fixed for tile caching (#1512 #1571).

For the “classic” online tiles providers, it seems the tiles cache is indeed written and red correctly.

So my problem is, first, that the old code sample (findMapFiles method) does not seem to explore the storages according to new Android storage management and fails to find .map files in the default place (/default-storage/osmdroid/*.map). It’s looking in /storage/emulated/0/osmdroid/ and /mnt/media_rw/1501-3B0F/osmdroid/ on my virtual device and none of that exists or is accessible.

My second problem is that I can’t find a way to “manually” add a .map file (as a workaround). Even if I create a file descriptor to a .map file using the absolute file path I can get from the adb shell, Osmdroid crashes when I try to display it :

org.mapsforge.map.reader.header.MapFileException: cannot read file: /storage/1501-3B0F/osmdroid/languedoc-roussillon.map
        at org.mapsforge.map.reader.MapFile.<init>(MapFile.java:247)
        at org.osmdroid.mapsforge.MapsForgeTileSource.<init>(MapsForgeTileSource.java:69)
        at org.osmdroid.mapsforge.MapsForgeTileSource.createFromFiles(MapsForgeTileSource.java:170)
        at net.eneiluj.nextcloud.phonetrack.android.activity.MapActivity.getMapsForgeTileProvider(MapActivity.java:391)
        at net.eneiluj.nextcloud.phonetrack.android.activity.MapActivity.setTileSource(MapActivity.java:1047)
        at net.eneiluj.nextcloud.phonetrack.android.activity.MapActivity.access$2300(MapActivity.java:110)
        at net.eneiluj.nextcloud.phonetrack.android.activity.MapActivity$13$1.onClick(MapActivity.java:1030)

while the file descriptor says the file exists.

I’m currently loosing time and energy trying to convert files Uri (obtained with ACTION_GET_CONTENT intents) to a File I could provide to Osmdroid. Probably a dead end 😁.

I’ll be glad to provide more information if necessary.

Environment

Virtual Android device (API 29) without google services installed.

If it’s a bug, version(s) of android this affects:

Android 10 (API level 29)

Version of osmdroid the issue relates to:

v6.1.6

[julien-nc]

Ok thanks a lot.

In case other people have trouble managing .map files on Android 10+, here is my feedback:

The cleanest way I found to allow users to put .map files in the app data storage is to launch an ACTION_GET_CONTENT intent to let users choose a file anywhere on the device (and beyond, like in a Nextcloud storage), then to copy it to the app storage.

• use

File[] externalStorageVolumes = ContextCompat.getExternalFilesDirs(context, null);
File primaryExternalStorage = externalStorageVolumes[0];

to get your app storage.

• use an InputStream to read the .map file from its Uri
• use a FileOutputStream to write the destination file

InputStream inputStream = context.getContentResolver().openInputStream(fileUri);
FileOutputStream outputStream = new FileOutputStream(fdest);
try {
    byte[] buffer = new byte[4 * 1024]; 
    int read;
    while ((read = inputStream.read(buffer)) != -1) {
        outputStream.write(buffer, 0, read);
    }
    outputStream.flush();
} finally {
    inputStream.close();
}

It is then easy to scan the app storage to load all .map files with the findMapFiles method provided in Osmdroid Mapsforge tile provider code sample.

I guess the issue can be closed. Thanks again.

[hgoebl]

@monsieurtanuki yes, would be a way. But DocumentFile doesn’t expose a File, only an InputStream. mapsforge needs random access (somehow it’s a database) and a stream cannot provide random access. So I stay with the solution that users have to reserve enough space so the map-files can be copied to private storage where File-based access will be supported in future releases of Android (most hopefully). It’s only a caveat for users with multiple apps and the intention to share .map-files between those apps.

TL;DR your ideas are good, but in my opinion it’s too risky regarding future Android releases.