R Raw Paths, DP4 Style
A couple of months ago, I wrote about raw paths and “all files access” on Android R, using R DP2. And… what I had there on raw paths is not completely accurate for R DP4. I am not certain how much of that represents changes in Android R and how much of that represents screwups in my original testing.
What I am seeing in R DP4 is:
-
With no permissions, your app can create files of any type in the
Documents/
andDownloads/
directories. Your app can then manipulate those files afterwards. -
With
READ_EXTERNAL_STORAGE
permission, your app can read “media files” in any directory other thanAndroid/
. The precise definition of “media files” is indeterminate. More on this later. -
Whether files can be read will depend on whether they are indexed by the
MediaStore
. So, for example, files that you push up usingadb push
will not be visible until sometime afterMediaStore
indexes them (e.g., after a device reboot). -
No additional abilities appear to be gained by holding
WRITE_EXTERNAL_STORAGE
(as expected) or having atargetSdkVersion
ofR
.
The second bullet lines up with the minimalist documentation on raw paths, which states:
Android 11 allows apps that have the
READ_EXTERNAL_STORAGE
permission to read a device’s media files using direct file paths and native libraries.
(emphasis added)
The definition of “media files” is murky. It appears to be tied to MediaStore
indexing, not just file extensions. So, with READ_EXTERNAL_STORAGE
:
-
We can read PNG files
-
We cannot read text files
-
We cannot read text files with a
.png
extension -
We cannot read text files created by an app in
Documents/
orDownloads/
, even though those apps were able to create the files directly in those directories -
We cannot read PNG files that were put on the device that
MediaStore
does not know about yet (e.g., theadb push
scenario)
So, media file formats that MediaStore
does not know about might not be accessible
this way, even if you and your users think of those formats as being “media”.
If your app is mostly focused on media, this situation may be an improvement over what we have for Android 10. But, given the undocumented definition of “media files”, I would be somewhat hesitant to rely upon it.