PSA: file: Scheme Ban in N Developer Preview

If you are building an app against N Developer Preview 1, with a targetSdkVersion of 'N', it appears that you can no longer use file: Uri values in many places. In particular, based on my testing:

• You cannot use a file: Uri as the “data” of an Intent to be used with an activity, such as for an ACTION_VIEW Intent, whether to be used immediately or to be wrapped in a PendingIntent. In other words, startActivity(Intent.ACTION_VIEW, Uri.fromFile(...)) will not work.

• You cannot pass a file: Uri in an Intent extra, such as EXTRA_OUTPUT for ACTION_IMAGE_CAPTURE.

• You cannot put a file: Uri on the clipboard, using things like ClipData.newUri().

If you try to do these sorts of things, you will crash with a FileUriExposedException exception.

This is coming from an updated edition of StrictMode. StrictMode.VmPolicy.Builder has a penaltyDeathOnFileUriExposure() method that triggers the detection of file: Uri values and the resulting FileUriExposedException exceptions. And, it appears that this is pre-configured, much as how StrictMode is pre-configured to apply penaltyDeathOnNetwork() (the source of your NetworkOnMainThreadException crashes) on Android 4.0+.

It is unclear if this is a “trial balloon” and will be rescinded before Android N ships, or whether this is the expected behavior for the final shipping product. You may wish to keep track of this issue to perhaps find out more about these sorts of plans.

Assuming that it is here to stay, if you plan to use the latest targetSdkVersion once Android N ships, you need to start using content: Uri values:

• Apps that have been producing file: Uri values will need to use things like FileProvider to produce content: Uri values instead

• Apps that have been consuming file: Uri values will need to make sure that they also support content: Uri values… and do so correctly

I can understand why Google is doing this. They have been beating the drum for some time now to try to get developers to switch off of file: Uri values.

However, I worry.

Too many apps do not handle content: Uri values well. They assume that a content: Uri must be coming from MediaStore and do some unfortunate things, such as trying to query for a DATA column, in hopes of scoring a file path. FileProvider does not handle this, resulting in crashes. I had to write a LegacyCompatCursorWrapper just to help developers using FileProvider to better cope with poorly-written client apps.

This includes dealing with broken apps from the likes of Samsung, Twitter, and Google. This is not a problem that is somehow limited to inexperienced developers or small firms. In the case of Twitter and Google, I think that they have fixed their apps, but I am sure that plenty of others are out there. After all, I see countless questions from people on Stack Overflow, using older broken advice, trying to just strip the path off a Uri and use it to access the filesystem.

Now Google is trying to force developers to publish content: Uri values. That only works if a preponderance of consumers of content: Uri values do so properly. I fear that too many do not. Developers will be caught between the Scylla of Android N and the Charybdis of user complaints that the app does not work with with XYZ other app that screwed up consuming the content: Uri. Experienced developers can work around this, by keeping targetSdkVersion low or possibly cooking up some reflection-based hack to de-fang StrictMode. Newcomers to Android will wonder why all of the existing blog posts, Stack Overflow answers, and older books are broken when it comes to working with Uri.

On the engineering side, I don’t have a better answer, other than for Google to include some sort of content: Uri compatibility testing as part of evaluating apps for the Play Store.

I really hope that Google will do more to educate developers about this exception and how to correctly produce and consume content: Uri values. Since FileUriExposedException is not included in the N Developer Preview “Behavior Changes” documentation, I do not hold out much hope. Heck, at this moment, the only pages indexed on Google for the search term of FileUriExposedException are things that I wrote, since the N Developer Preview JavaDocs are only distributed in ZIP form.

Time will tell whether FileUriExposedException and the revised StrictMode are a figment of my imagination, are a fluke of the N Developer Preview 1, or are here to stay. However, let this serve as a wakeup call: use file: Uri values at your own peril going forward.