Hello

hello, Kai!

how can I help you today?

I thought I had another hour :D

By answering some questions about scoped storage X)

oboy

Yes

I have a docx in my app that I want to open with word, edit it, then close word and come back to the app.

how are you defining "in my app" in the phrase "I have a docx in my app"? do you mean it is packaged as an asset?

Unfortunately Word App doesn't wanna write on documents that aren't in public storage.

It's a in my private storage.

OK, so getFilesDir() or something like that?

Yes.

so, you're using FileProvider to make it available to the Word app?

What I did before Android 11 was put it in Documents, wait for MediaStore to pick it up, make it available via a FileProvider and do startActivityForResult. After coming back I'd just read it and delete it.

Now with Android 11... &=?"§%)!

but... from Word's standpoint, FileProvider for something in external storage and FileProvider for something internal storage is indistinguishable

Apparently not.

(er, "something in internal storage")

Or I get something wrong. https://github.com/cryptomator/cryptomator-andr...

"Microsoft apps have currently problems to access files shared to them with write permissions in internal storage."

Just checking if I really use FileProvider, but I think I do.

It seems to be without FileProvider. Just a "ACTION_EDIT" Intent.

where is the Uri coming from that you are putting in that Intent?

MediaScannerConnection.scanFile on the file path.

No, sorry.

So far it was assembled "by hand".

um, that's almost always the wrong answer

(and not just an Android-10-and-above wrong answer)

so... how are you assembling this Uri? what scheme does it have?

I actually don't know

There is utility functions and a Wrapper for file system access.

if you log the Uri, what does it look like?

/storage/emulated/0/Documents/com.ourcompany.android.v20/(866E3BB1-8D8B-6F3F-1DF7-66EB74173DE5)/(476AB95C-4D19-5B71-03BC-4744C34293F8).docx

that is a path, not a Uri -- a Uri has a scheme

That's not it.

OK, so that's a Uri from the MediaStore

MediaStore AFAIK on Android 10+ does not give you any more rights than you would have to the content on the filesystem

The strange thing is that I can write content via MediaStore, but later I won't be able to read it.

yeah, Downloads is weird

I mean, even using "scoped storage is perfectly normal" as a baseline, Downloads is weird

And I don't wanna use Documents as that is undocumented.

if you start with "scoped storage is weird", Downloads is something straight out of a horror film

And could go away

I tried picking a Folder in Documents via SAF to have access, but opening it later via "File" failed.

I'm not certain what "opening it... via "File"" means, exactly -- if you are trying to use filesystem APIs to work with a SAF document, though, that's not gonna work

particularly since you are not planning on keeping the file around (delete once Word is done), my inclination would be for you to download the file to a filesystem location that is yours (e.g., getCacheDir()) and use FileProvider to make it available to Word

But then Word won't write on it.

well, that depends a bit on what Word is doing

That's the whole problem pretty much. That the file has to be in public storage.

if you include both FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION on the Uri, Word should have rights to write to it

It DOES have rights to do so, it just doesn't use it

going back to the GitHub issue that you linked to, I can see two main possibilities

That's the whole reason for jumping through hoops even before Android 11, copying that file around.

the "MS engineers are idiots" possibility: they are examining the Uri, trying to extract a path from it, convert that to a filesystem path, and use that

the "the app has a bug" possibility: they did not have FLAG_GRANT_WRITE_URI_PERMISSION on the one Uri, and Word tries a benign write to the Uri to test write access

when I said that there's no difference from Word's standpoint with FileProvider of whether the file is on internal or external storage, I'm quite serious

it's akin to saying "well, Chrome can access Web pages on this partition on the Web server but not that partition" -- at most, that's a Web server problem, not a Chrome problem

I tried sharing with a file provider too, from internal storage. It doesn't work.

IMHO, there either was a bug in your test, or MS engineers are idiots

in the latter case, you're seriously screwed

I did a minimal working example with the generic FileProvider, FLAG_GRANT_* Permissions and ACTION_EDIT

I think there is a third possibility: They don't want other apps to be able to use Word "just as an editor". They wan't to get control of the files, that Word etc. own the files that are edited.

and Word read the content but treated it as read-only?

Yes

Exactly.

that third possibility does not line up with the GitHub issue that you linked to

Why not? "Only if the files are shared from public storage, they are able to open it with write access."

Oh sorry, yes.

in that issue, FileProvider *does* work, for certain files

so, if we assume that issue is accurate, and we assume that you didn't have a bug in your test, then MS engineers are idiots

I guess so

they are trying to bypass FileProvider and work directly with the underlying file

which only works if they can suss out the filesystem path based on the Uri and they have access to that file

Question is what how I can work around it, given Android 11.

as I wrote, you're seriously screwed

Is there no way to write a random document to a public place, share it and then read it again in Android 11?

not using java.io.File in both apps

I mean, that's why we have FileProvider

I'm open to using other means in my app

well, you tried the other means (FileProvider), and Word does not want to play ball

for the limited case of certain types of media (images, videos, audio), there are more options

The main problem is that I can't read the file after word is done.

right, because Downloads is basically write-only, screwy as that sounds

w

t

f

I'm actually surprised Word can use something from there

So with Android 11 our customers just won't be able to edit word documents anymore right from the app.

Good job, Google.

And Microsoft.

it's more that I don't have a for-certain solution for you

I am still trying but more and more losing hope to finding one.

There just might not be one

in principle, if you used ACTION_OPEN_DOCUMENT, let the user decide where to put the content, took persistent permissions on the Uri you get back, and work with that Uri, you should be able to use FLAG_GRANT_* with that Uri to let Word access the same content

however, I'm not 100% certain of that

That would be better than nothing.

Even though it introduces another step

and, given that this is a DOCX file, I'm not certain if whatever code you're using to manipulate it on your side will handle an InputStream as a data source

I was hoping that I could use SAF to get access to a directory somewhere and then use the File API to access that at will, as an "exchange directory". But as you said, Downloads is kinda "write only" apparently. And Documents seems to be strange too.

It does handle an InputStream as a data source.

"then use the File API to access that at will" -- nope, no more than you get a URL from a Web server then try using local files to work with stuff on the Web server

if your DOCX-capable code can read and write using InputStream and OutputStream, then ACTION_OPEN_DOCUMENT or ACTION_OPEN_DOCUMENT_TREE should be possibilities

Why not? The File API is just an abstraction of MediaStore and I was hoping it would also remember and use the same rights.

yes, but ACTION_OPEN_DOCUMENT has nothing to do with MediaStore

I was using ACTION_OPEN_DOCUMENT_TREE and took the permissions

And was hoping it would somehow use that.

use DocumentFile.fromTreeUri() to get a DocumentFile for the tree that you opened

then use createNewFile() on that tree DocumentFile to get a DocumentFile on a new document inside of that tree

So I cannot use SAF and the File API together?

if by File API you mean java.io.File, then no

however, given a DocumentFile on the new file, you can use getUri() to get the Uri for that document

and pass that to openInputStream() and openOutputStream() on a ContentResolver

that will give you the ability to read and write content in that document

you do not need java.io.File for that, which is good, since that's not an option

Ok

so, you use openOutputStream() as the target for your download operation

you use the Uri to the document with FLAG_GRANT_* and ACTION_EDIT and see if Word plays ball

my guess is: Word will not play ball

which is why I'm saying that you're all kinds of screwed

It's another thing to try before throwing the towel, I guess.

the problem isn't that you cannot provide a writable Uri to Word -- it's that Word doesn't appear to want to use those, if they have a content scheme

but, yes, it's worth a try

perhaps part of their "can we use this Uri" algorithm handles SAF Uri values better

in the end, MS needed to do a better job of supporting content Uri values

Yes.

Very much so

however, until Google started tightening the screws, there was nothing forcing MS to do that sort of thing

eventually, MS will probably "straighten up and fly right"

in the interim, trying SAF is worth a shot, but I would not be surprised if it fails for the same reason your FileProvider test fails

If I can read the file afterwards, that would be progress

And almost everything I want (besides the user having to pick a file destination).

with the SAF option, reading the content afterwards shouldn't be a problem

I'll let you know on saturday ;-)

whether Word wants to write to the Uri is the big question

OK, sounds good

and that's a wrap for today's chat -- next one is Saturday at 4pm US Eastern

Stay healthy and have a good one

And thanks

have a pleasant day, and best of luck with your SAF experiment!

:)