Android "files" manager opens for a "save" when opening

Get ready for "more than you ever wanted to know about Android and files"... :)

Some cloud apps actually link to a local *cached* copy of the file for viewing only-- for example, when you click on an attachment of a .fountain or .fdx file from Gmail, the address of the file sent to Dubscript to open is to a pre-downloaded, cached copy of the attachment somewhere in Gmail's own private storage area. In this case, it wouldn't be smart to save back to that location-- besides being hidden in a /cache/ folder deep in gmail's directory tree (meaning you wouldn't be able to easily reach it from other apps), it's a cached, temporary file so gmail could delete it-- and all your work-- at its discretion any time.

For that reason, when you open a fountain file originating from another 3rd party app, you may be first prompted to "save" a new working copy in a new location of your choice. This new working copy can be saved locally or in the cloud (via another app like Gdrive)-- that part doesn't matter to DubScript. That way you know where it is and can access it easily from other apps and know it won't be deleted by that 3rd party app. And if you ever need to get it a fresh version from the email, you can just go back to gmail and make a newer working copy as it appeared in the email.

A second reason you may be asked to save files when you open them directly from an external 3rd-party app has to do with file access permissions rules that are continually changing in Android. In fact, Android has gotten more and more restrictive on allowing one app to access the files of another-- which may be the issue you're encountering. To overcome these new security restrictions, you are asked to say "yes, it's okay for this app to write to the file." This can be done with the Android file picker started from DubScript to either open /create a new file for writing. In Android Q the rules get even more restrictive, and Google has promised they're going to get VERY tight in the next version -- to the point that people offering file picker apps are freaking out.

To help track down your issue here, could you try 2 things?

1. Go to Android's settings and ensure that DubScript has the storage access permission enabled, just in case. This can overcome some access issues (and it usually asks for this permission at run-time if it is needed), but just in case, it's good to eliminate that as an issue.

2. Could you also check if opening the file directly from DubScript with the "open script" icon works? The distinction between opening from DubScript vs. opening from the cloud app is technical, but huge-- essentially they are treated differently by Android-- the manual selection of a file via the Android file-picker is assumed "safe" and well-supported (and will be the only way to go soon) whereas a passed cloud file location/link via selection in a remote app has to be handled differently and can run into these security issues I mentioned. Be sure to swipe the side-drawer on that "file picker" screen to see all the cloud apps that are supported. Google Drive should be there, for example. Hopefully, your cloud app will be as well, as these storage access standards were put in place back in Android 4.4 and going forward are the way cloud services are supposed to make their files available to other apps.

> Any other file I open with my cloud browser be it .txt or .pdf goes right to the relevant app and handles it WITHOUT popping up the Android files manager looking for a save.

This may (?) be because those files are read-only, so the write-back-to-that-file permission consideration doesnt' come into play. The trick is to be able to write back to the source location without running into Android's security rules. And the way Google decided to ensure 100% that you DO want to write back to a file is to explicitly ask the user, which is what it does with the "open script" file picker.

One last thought -- Google Drive does work correctly in Pie (and in the upcoming Q). I haven't tried OwnCloud, but hopefully it shows up in the File Picker. If not, I can maybe download that app and see if there is some particular strangeness with that service. Please let me know.

>I have two Dubscript subscriptions

Thanks for your support!

> is their a support email instead of this forum for this kind of stuff? ;-) Cuz I gots me a few feature requests that i'd like to throw your way. Thanks!

That's awesome! I like to keep these discussions public so that others who may be running into similar issues can chime in and/or find or offer solutions. There are hundreds of Android devices and some behave oh-so-slightly-but-critically-differently, so this is useful.

I'd love to hear any feature requests- been working on a beta for some time, so if you're not signed up for the beta version, I recommend you give it a try too if the above 2 ideas don't work and/or if you feel adventurous. There should be some nice improvements coming in the next one including support for new Android Q features, improvements to fdx export, more fonts, and other fun things. I believe the current beta also features character reports if you want a list of all the dialogue from a single character.

Thanks again for writing, your support, and sorry for offering maybe too much info here! But sometimes putting in the boring details might help diagnose the issue from your end, so it can't hurt, right?

Hope this is helpful,
R

PS-- one final thought-- if you go to the "Help & Info" screen, it should tell you the location of the script that you've opened. It looks like content://com.androidexternalstorage.documents/document/primary/filename.fountain or perhaps content://com.google.android.apps.docs.storage/document/somecrazynumber -- this is just more info about what the "source" of the opened file is. For your security and privacy, don't post the name of the whole file itself, but the first com.whatever.whatever part should be safe. It will give an idea about where it's trying to load the file from and maybe help track down the issue. :)