Add offline map layers without having to put files in Collect directory

This is also a problem for me, so good to hear that it could be addressed.

Is there a way to use a more user friendly folder on Android? I am having trouble with enumerators not being able to find the right place - even before multiple project support (which is great by the way!)

Can ODK Collect access more generic spaces on a device e.g. ODK/layers

I know there are technical reasons for having migrated away from a main ODK folder for instances (not sure I really understand them!), butt drilling down to Android/data/ is more difficult than my folk using ODK Collect are comfortable with.

Personally having multiple places for the mbtiles file to reside would not be great (it sounds like you plan to have a general folder and project specific folder) - because I know that if it can go wrong, it will. And the non-human-readable format of the project names on the device complicates things further (as highlighted by @Florian_May above)... Finding yourself out in the field in the wrong project space needing to move mbtiles on the device is stressful enough, but getting someone to do that while they are on the phone to you asking why they can't see the map (when they've finally got signal) is a nightmare. Speaking from experience!

The other useful thing would be the possibility of downloading mbtiles directly from a Central server (maybe this is a different feature request) - if there were a function to upload mbtile as 'media' with a form definition, and for ODK Collect to download and transfer that to the appropriate folder, that would be a great step forward too. And would solve my hassles above...

Many thanks for your ongoing support and development.


Not the primary topic of this discussion but

This would really be very useful in order to propagate forms on lot of phones, belonging to non informatics friendly users :slight_smile: , without having to manually put the layers at the right place on each phone. Layers could by downloaded from anywhere, not only from central.

1 Like

Ah yes! I knew someone else would have already have had a similar thought. And a better one, if it's not just 'tied' to Central.

I love the term 'non informatics friendly users' - that seems to be everyone I end up working with :slight_smile:

1 Like

Android doesn't allow us to write to arbitrary places on the device. We can only write to /sdcard/Android/data/ More at

We agree that project UUIDs are not friendly. We now write the project name inside the project directory so you list find all project names (find /sdcard/Android/data/ -type f -maxdepth 2) and grab the UUID from the path.

Yes, we'll eventually let you download mbtiles from Central automatically.


Hi @yanokwa
Thanks for the information on this.

My confusion is probably around why ODK can't write to a device when other Apps seem to do so - for example Viewranger (other navigation apps are available!) appears to be able to read / write data in an arbitrary folder named 'viewranger', so that is the naive assumption I was working on - ODK is the only I use that requires me to delve into the /Android/data.... folder. Apologies if that sounds 'challenging', I'm just revealing my level of stupidity rather than questioning anyone's competence!

My new-best-friend navigation app called Orux Maps allows me to use mbtiles, so if I could point to the folder that ODK used for Layers it would save needing two copies of the file on my device, and then I could navigate efficiently between recording stations...

I understand that putting instances in the /Android/data/... folder means that other apps can't access anything, which is great from a confidentiality or Data Protection perspective, so if that's the main constraint preventing use of other locations on the device for other functions, then that's a compromise worth living with. As always I live in hope of having cake and eating it...

Thanks for the ongoing improvements - they're much appreciated, and don't take our 'impatience' for perfection as negative :slight_smile:

As @yanokwa states, we can't access arbitrary files automatically (from a top level ODK directory for instance), but we could potentially have a feature that lets the user choose a reference layer that sits somewhere on their device (like in their Downloads directory) and that layer could be copied into Collect's own storage.

The important difference is that it involves the user going through a UI to that the OS provides to grant permission to the app to access that one file. I'm assuming that's the kind of thing you're seeing with this other app. If not, it's likely they won't support the feature you're talking about much longer because directly writing/reading from your app's designated directories is a not something Android supports any longer. You can read some more details on that in the Android docs if you're interested.

As a point of interest: this is why the Android team removed the ability to just read and write from anywhere on the device. It was incredibly easy to just build an app that looked like a cute face swapper or game that could just grab files from another app's well known directory and upload them somewhere.


Hi @seadowg
Thanks for the clarity of your answer here (a reminder with examples is always helpful!) adding to that provided by @yanokwa. Yes, the other apps I use have settings for 'default' locations for different files - so I guess they use that as a means of gaining permission from the user, but it is always possible that these apps haven't caught up with ODK yet in terms of Android best practice (or functionality).

I'm happy to contribute to the thought processes from a user perspective on different options you might have for storing layers - I have some very stubborn enumerators (usually in a good way), so can vouch for the need for it to be foolproof...

Making use of a common UI method of locating a file or folder would be good, for example, as an alternative to requiring the files to be placed in an ODK folder? Any process that is familiar helps, in my experience.

If we can find a way of getting the files onto a device (maybe Google Drive?) and then point to that from within ODK (possibly whilst using a map widget) then it cuts down the need for 'expert' intervention - possibly also allows reuse of existing tools / functions on Android rather than coming up with a new circular transportational device.