I looked into this too and was a bit confused by this provider. Is it actually used? I could not find usage inside OIFM but I guess since it's explicitly exported it is meant for outside use. What does it do though?
Regarding the commit, I don't see anything that could go wrong with it, it's pretty straightforward as far as I can tell.
P. S. Out of curiosity, is the Read permission on the application needed? I am sure the Write one implicitly always requests it, but is it needed for the provider to be able to use it?
You received this message because you are subscribed to the Google Groups "OpenIntents" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openintents...@googlegroups.com.
To post to this group, send email to openi...@googlegroups.com.
Visit this group at http://groups.google.com/group/openintents.
For more options, visit https://groups.google.com/d/optout.
The provider is used for opening files via the intent system. So it does leak information about files intentionally.
This was our idea for a document provider :-)
I wanted to make the read permission explicit because this is the permission that the provider requires. Hence, the user understands that no permission is misused or leaked. However, I don't know whether the read permission is implicit by the write permission. Any test results ? Or insight knowledge?
Good to know regarding the provider's purpose!
As for the implicit adding of the READ_EXTERNAL_STORAGE permission, I looked into it some weeks ago and found an SO post with tests (aapt analyzer shows implicit permissions), but even without checking this test and since KitKat enforces this permission, OIFM would not be able to read files on my n4, but it most certainly has no problem reading any file on the external storage.
P. S. Another way to see that the permission is indeed added is check the play store permissions for OIFM :-)