Once Again, Uri Access Lifetime Is Shorter Than You Might Think
I first wrote about this subject nine years ago and updated the post five years ago. But, as I was pondering an entry in Jorge Castillo’s Bluesky “Android dev secret” roster, it dawned on me that this post needs yet another refresh, as this is still an ongoing source of trouble for newcomers to Android app development.
Let’s say that your app gets a Uri
from some outside source. Perhaps you used
ActivityResultContracts.GetContent
or ActivityResultContracts.OpenDocument
to get a Uri
to some
user-selected content. Or, perhaps you have an activity with an <intent-filter>
set up to respond to ACTION_VIEW
or ACTION_SEND
or something, and
you got a Uri
that way. Or, maybe you get one from another app via the clipboard,
drag-and-drop, etc.
How long can you use that Uri
to access the content that it points to?
Some developers think that you have indefinite access to it, and that
the Uri
value can be saved safely to persistent storage. Alas, that is not
the case.
For a file:
Uri
, that might almost work, though the file could always be moved
or deleted. However, the file
scheme was all but banned nearly a decade ago,
so it is unlikely that you will encounter one. Most likely, you will get
one with a content
scheme.
However, you do not have long-term access to the content
identified by a content:
Uri
. It is best to think of a content:
Uri
as being akin to an HTTPS URL to some content, where that content can
only be accessed if the session is authenticated (e.g., via a session
cookie). Just because you can download content from that URL today does
not mean that you can download content from that URL tomorrow, as the
session may well have timed out.
You might then think that you have access as long as your process is running, and that access rights lapse at that point. That’s what I originally thought… and that’s not right either.
Instead, only the component instance that received the Uri
can access the content.
And, for the Intent
actions that I listed, that means the Activity
that receives the result can access the content… but not other activity instances
within your app, nor any services, etc.
For short-term use, you might hand the Uri
off to a repository.
The repository can load the content and deliver it to various components
of your app using a reactive API. Or you can consume the content directly
in the receiving activity in other ways, such as handing a Uri
to an image
to your favorite image-loading library (e.g., Coil). So long as you are using
the Activity
that received the content as your Context
, or are using the Application
singleton as your Context
, you should be fine.
Nowadays, many apps are single-activity apps, with different screens being implemented
by fragments or composables. This reduces the impact of
short-lived content access. However, if you implemented more than one activity,
and if you need to get the Uri
to another activity in your app:
-
Attach it to the
Intent
you use to start that other activity viasetData()
-
Add
Intent.FLAG_GRANT_READ_URI_PERMISSION
orIntent.FLAG_GRANT_WRITE_URI_PERMISSION
to theIntent
based on what the other activity needs to do
This extends the permission that your first activity has to the second activity, so it
too can access the content. The same basic approach would hold true for getting the
Uri
to a Service
.
That approach can allow you to use the Uri
within all components of your running
process. It does not help you use that Uri
in future processes, though.
If you need durable access — such as being able to access the content tomorrow — you have two main options that I know of:
-
If you used
ActivityResultContracts.OpenDocument
,ActivityResultContracts.CreateDocument
, or similar Storage Access Framework actions, you can try usingtakePersistableUriPermissions()
onContentResolver
to get long-term access to the content. -
Otherwise, before your component is destroyed, make a local copy of the content in your app’s portion of internal storage (e.g.,
getCacheDir()
). This approach duplicates the content, and changes to the original edition of the content will not be reflected in the copy. Use appropriate UI terms (e.g., “import”) to help the user understand that this is what is going on.