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:

— Mar 03, 2020