Scoped Storage Stories: More on RecoverableSecurityException
Android 10 and higher are greatly restricting access to external storage via filesystem APIs. Instead, we need to use other APIs to work with content. This is the 13th post in a seemingly never-ending series, where we will explore how to work with those alternatives.
I wrote about RecoverableSecurityException
in an earlier post on
updating the content from other apps.
I thought I was done with it.
Silly me.
Specifically, this Stack Overflow question
dragged me back into it, as Stack Overflow user joakimk was not getting that
exception when trying to update the DESCRIPTION
column for an image:
ContentValues values = new ContentValues();
values.put(MediaStore.Images.Media.DESCRIPTION, "Some text");
int res = getContext().getContentResolver().update(
MediaStore.Images.Media.EXTERNAL_CONTENT_URI,
values,
MediaStore.Images.Media._ID + "= ?", new String[]{sImageId});
Here, the image ID is pointing to an image that was not created by joakimk’s app.
In theory, on Android 10+, this should trigger a RecoverableSecurityException
,
so we can ask the user for permission to work with that piece of content. In this
case, the update()
call simply returned 0
, meaning no rows were affected.
This simple snippet of code highlights a few problems and other considerations with how
RecoverableSecurityException
works.
The Uri
is the Key
The biggest problem is that RecoverableSecurityException
is on a per-Uri
basis. The exception contains an IntentSender
that can be used to get permission
to modify the content identified by that Uri
.
A side effect of that limitation is that the update()
call must use the Uri
identifying the content, not a collection Uri
plus a quasi-WHERE
clause to identify
it. After all, that WHERE
clause might identify more than one piece of content.
So, you wind up with code more like this:
ContentValues values = new ContentValues();
values.put(MediaStore.Images.Media.DESCRIPTION, "Some text");
Uri uri = ContentUris.withAppendedId(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, imageId)
int res = getContext().getContentResolver().update(uri, values, null, null);
Here, we use ContentUris.withAppendedId()
to create a Uri
pointing to the
specific image, and we pass that Uri
to update()
. This update()
call
will now throw a RecoverableSecurityException
.
The Permission is Not Enough
Unfortunately, that RecoverableSecurityException
is not going to do you a lot
of good in this case… because DESCRIPTION
cannot be modified, even if the user
grants your app permission to modify the content. For some columns, MediaStore
just refuses to apply the update.
TAGS
, however, can be modified. So, for example, this sample Kotlin code
works:
suspend fun setTags(id: Long, tags: String) =
withContext(Dispatchers.IO) {
val values = ContentValues().apply {
put(MediaStore.Video.Media.TAGS, tags)
}
val uri = ContentUris.withAppendedId(collection, id)
context.contentResolver.update(uri, values, null, null)
}
(taken from this sample project)
The Permission Grant is Durable
In my earlier post on RecoverableSecurityException
, I did not explore how long
the permission grant lasts. If I had to guess, I would have guessed that it lived
just for the lifetime of your process.
Instead, it appears that the permission grant is more durable than that. While I cannot say that it lasts “forever”, it certainly lasts for more than just one process.
Android R is Unhappy
While Android 10 handles RecoverableSecurityException
just fine, Android R DP1
does not, crashing when we
display the system dialog to allow the user to grant permission to modify the
content. That crash comes from the MediaProvider
, not the app, so it appears to be
a bug that hopefully will get fixed.
Many thanks to joakimk for the assistance in identifying the problem and its solution!
The entire series of “Scoped Storage Stories” posts includes posts on:
- The basics of using the Storage Access Framework
- Getting durable access to the selected content
- Working with
DocumentFile
for individual documents - Working with document trees
- Working with
DocumentsContract
- Problems with the SAF API
- A specific problem with
listFiles()
onDocumentFile
- Storing content using
MediaStore
- Reading content from the
MediaStore
- Modifying
MediaStore
content from other apps - Limitations of
MediaStore.Downloads
- The undocumented
Documents
option
Nervous about how the newest version of Android affects your app? Consider subscribing, then asking questions in the office hours chats!