AlpineQuest & OfflineMaps

Psyberia-Support wrote:That would be "nice" to have, but not my priority right now. Rooted devices are still an exception, for system tool apps like backuping or file managing, it make sense, but for an hiking application that's just a plus.

I have so many (common) features already planned that I just don't want to spend time on studying how to work with rooted devices, documentation is poor and unofficial, and there is no guarantee that working stuffs and hacks will work in the following Android versions (they usually try to fix those kind of breaches)...

Moreover I consider owners of rooted device "experienced" users, and they are still able to change themselves the android permissions file like you explain in your post just above.

Sorry about that.

OK, I give up... it seemed like such a simple request, to be able to write to the AlpineQuest folder at the root of an external SD in Android 6, just like we used to be able to do in ALL previous versions of Android.

So we are all forced to switch to using the default Google Marketplace path which will wipe out all of the data if AQ is uninstalled, an especially worrying risk for anyone who has invested many hours/days creating off-line map sets. Please correct me if this is NOT the case, as this is my primary concern about using the default path.

Anyway, someone is bound to write a rooted app/script for managing Android 6, per application, permissions (as applied to the packages.xml file), so I'll keep searching. After all, what we are talking about here is a one line edit in a text file, hardly rocket science, but such a PITA to do on a phone. If I find one, I'll report back...

Just to be more precise, the application doesn't use "/Android/data/..." path by default, which is, as you said, deleted by the system when you un-install the application. It uses however the "/alpinequest/" folder on the internal device memory as it always did. Most modern devices have very large internal storage (much more than SD cards used to be not so far ago), which is sufficient for any common use of the application, and some don't even have an SD card slot. Internal storages are also faster than SD cards.

Psyberia-Support wrote:Just to be more precise, the application doesn't use "/Android/data/..." path by default, which is, as you said, deleted by the system when you un-install the application. It uses however the "/alpinequest/" folder on the internal device memory as it always did. Most modern devices have very large internal storage (much more than SD cards used to be not so far ago), which is sufficient for any common use of the application, and some don't even have an SD card slot. Internal storages are also faster than SD cards.

Show me a phone that has 128Gb of available storage... that's what I require to store my AQ maps and my MP3 collection. The free internal storage on my S3 phone is around 2Gb. I have no choice, AQ must reside on the external SD, which is why I would like to avoid the /Android/data/... path on the external SD. This was the entire point of my post.

But I completely understand you, I didn't say it's useless to use the SD card, I just said that most recent device have a (sufficiently) large internal memory to be used by default (we're talking about limitations in recent versions of Android, so most importantly recent devices). But I know it's not the case for everyone, that's why users can store data on the external storage too (even if you aren't able to choose any location).

Don't you think I wouldn't have preferred that no limitations had been put on writing SD cards? Do you know how much work and time I spent on both development and support due to that? It started with Android 4.4, and I'm still spending lot of time on it...

Show me a phone that has 128Gb of available storage...

The Galaxy S6 (the S3 has been released in 2012).

Foud this which relates to Lollipop (not sure about Marshmallow): http://www.knowreviewtip.com/fix-errors ... op-kitkat/

Not sure if it is relevant, or not, but there was no entry in the platform.xml file on my phone (CM13) for the WRITE_EXTERNAL_STORAGE permission. There was an entry for WRITE_MEDIA_STORAGE. I have added the "missing" XML code for WRITE_EXTERNAL_STORAGE and rebooted, but have no idea whether, or not, it has made any difference since I have already re-modified my pakages.xml as explained previously.

Psyberia-Support wrote:But I completely understand you, I didn't say it's useless to use the SD card, I just said that most recent device have a (sufficiently) large internal memory to be used by default (we're talking about limitations in recent versions of Android, so most importantly recent devices). But I know it's not the case for everyone, that's why users can store data on the external storage too (even if you aren't able to choose any location).

Don't you think I wouldn't have preferred that no limitations had been put on writing SD cards? Do you know how much work and time I spent on both development and support due to that? It started with Android 4.4, and I'm still spending lot of time on it...

Show me a phone that has 128Gb of available storage...

The Galaxy S6 (the S3 has been released in 2012).

The S6 was never an option because there is no removable media (or battery) - a poor phone design IMHO. The S7 is better since Samsung have acknowledged the error of their ways and re-introduced micro-SD, but still no replaceable battery. However it is way, way too expensive! My S3 does the job as a navigation device, which is what I bought it for.

As I said before, we have all been stitched up by Google, although there were permenent work-arounds for Kit-Kat and Lollipop on rooted devices. I have not given up looking for a similar "fix" on Marshmallow

This thread sheds some light on the matter: http://forum.xda-developers.com/galaxy- ... s-t3275394 but it is still only describing a temporary work-around.

The "official" way on 6.0 to write anywhere on your SD card is to adopt it.
But it means you first need to empty all contents if you want to re-use your existing SD card, because you'll need to format it...

Psyberia-Support wrote:The "official" way on 6.0 to write anywhere on your SD card is to adopt it.
But it means you first need to empty all contents if you want to re-use your existing SD card, because you'll need to format it...

Nope, I'm not prepared to give my external SD over to Android OS, I'd need my brain examining first! I do most of my data transfers too and from the microSD via a card reader in my PC. This is the only viable option for this quantity of data. USB2 is hopeless!

I've just remembered my experience with Titanium Backup when I first upgraded to Marshmallow. Like AQ, it was configured to write to a root folder of the external SD and like AQ, this folder became read-only (and unusable) after the MM upgrade.

The fix in TB was to change the Backup Folder Location / Storage Provider, from Filesystem to DocumentProvider. It is this change that throws up the internal Android dialog that allows you to to set permanent write permissions to any folder of the external SD, including the root. This is what I was trying to explain at the start of this thread, but I don't think I explained it well enough. I think that some other apps are also using the DocumentProvider interface and it is this that allows the user to grant write permissions to the external SD.

I do not believe that the DocumentProvider interface requires a rooted phone (but don't quote me on that) and it does appear to be an official Google method from Lollipop onwards.

Is this in any way helpful?

There is a reference to this about half way down this thread: http://forum.xda-developers.com/htc-one ... st63771064

I did talk about that in my first answer...
"DocumentProvider" is part of the Storage Access Framework (SAF) component (not new to Android 6.0), and as I did explain in this first post, it cannot be used by the application.
DocumentProvider only allows very simple operations, like read or write a file. This is not enough for map storage. The application stores the map data in 2GB files, it needs to quickly seek in it, read or update parts of it, etc., requiring low level calls... DocumentProvider is good if you want to save a PDF or picture, but that's it.

OK, sorry I have only just remembered the TB "solution" and had not connected it to the reference in your post. I also did not realise that the file operations were limited, which is a shame

So it looks like I'm stuck with my workaround for the time being, which is:

1) Edit the /data/system/packages.xml file to include WRITE_MEDIA_STORAGE permission for AQ
2) Save a copy of this file in a backup folder
3) Set AQ not not auto-update in Google Marketplace
4) When an AQ update appears on the Marketplace, apply all updates except AQ
5) Take a copy of the /data/system/packages.xml file to the backup folder
6) Apply the AQ update from the Marketplace
7) Restore the copy of the /data/system/packages.xml file from the backup folder
8) Reboot the phone

No problem...