support more file managers for saving attachments (long press)

[Djfe]

K9 should support Android's document handler and maybe the fx file explorer (https://play.google.com/store/apps/details?id=nextapp.fx)

[fat-tire]

This looks like a dup of #2844. FWIW, I have been messing with this today, and the extent to which hardcoded local file paths are used in this app is insane. it's not even using the "file://" schema-- it's just passing around straight-up raw "/storage/0' type paths right out of Environment.getExternalDirectory(). Which means there's a lot to fix to get storage access framework to work right if it's still going to be backward compatible to pre-Kitkat (or really pre-Lollipop) devices and also support the current default save directories.

I'm still trying to learn the code here tho.

[Djfe]

it's not a dup of that issue.
I'm referring to the save button next to each attachments below every mail :)
not how attachments are saved by the app when downloaded with the mail.

the save button exports the file to your download folder or another file manager by long pressing.

[fat-tire]

Hmmm. You mean the target specified in Settings->Global Settings->Miscellaneous->Save attachments to... right?

If so, I guess that's where I'm saying it should, on Lollipop and above, ask you to select a folder using Android's built-in Storage Access Framework, then at that point it would have a URL like "content://something.something" which could be local storage, but could also be a folder on your Google drive, or wherever. It would also have automatic permission to access/create a file there because that's how the SAF works.

Unfortunately the current infrastructure literally uses a path (ie, "/sdcard/Downloads/") which is the result of checking Environment.getExternalDirectory(). At the very least it should start with "file://" and be a normal URI instead of a path. But the app doesn't support this yet, hence issue #2844, which I started to do before realizing how extensive a change it would be, especially if you want to still support older devices as well as newer devices that have the path "/sdcard..." format set up currently. Basically:

• older devices that don't have the SAF (< Kitkat) or Kitkat (which only has support for Intent.ACTION_OPEN_DOCUMENT-- for picking a file, not a directory as with Intent.ACTION_OPEN_DOCUMENT_TREE) you'd want to fall back to the current version.

• Lollipop or higher you want to append a "file://" to the current path if it starts with "/" so now it's using proper URIs and use the Android SAF picker from now on to choose the directory. Once the user chooses a directory to save attachments, the app should "persist" the permission so that the next time you run the app it will still have access/permission to save there. And then finally, anything that currently saves to a File needs to save via the SAF.

Doing this will let you choose anywhere on the device to save with a UI, but will also let you save via any app that provides access. Besides the FileProvider, Google drive uses it, so does Box.com, and a few others.

I started doing all of the above, but I've only been familiar with the code for about 2 days now, so i hadn't realized how many different places would be affected. After a few hours I stopped and may go back to it after we're on the newest API 26.

[Djfe]

I see.
I mostly wanted the export of files to one path to be improved, but the general way files are saved should get the new system as well.
I can relate that it's hard to improve this, if the current way is messy.
But maybe it's a good step to completely separate file storing and the rest (if it isn't already), that way you can keep the old way and add a new way, that's preferred on newer android versions
(in a way that the old way can be dropped once it's irrelevant)

[cketti]

We switched to using the Storage Access Framework exclusively.