tree f347f089c50be9d12b08006c353a6b679d488a09
parent ffe3226069984e6c8e3f7bf08941d74c2afd3fdc
author Jeff Sharkey <jsharkey@android.com> 1533055537 -0600
committer Jeff Sharkey <jsharkey@android.com> 1540567949 -0600

Magic to keep "_data" paths working.

As part of the storage changes in Q, we're removing the ability for
apps to directly access storage devices like /sdcard/.  (Instead,
they'll need to go through ContentResolver.openFileDescriptor() to
gain access.)  However, in several places we're returning raw
filesystem paths in the "_data" column.  An initial attempt to simply
redact these with "/dev/null" shows that many popular apps are
depending on these paths, and become non-functional.

So we need to somehow return "_data" paths that apps can manually
open.  We explored tricks like /proc/self/fd/ and FUSE, but neither
of those are feasible.  Instead, we've created a cursor that returns
paths of this form:

/mnt/content/media/audio/12

And we then hook Libcore.os to intercept open() syscalls made by
Java code and redirect these to CR.openFileDescriptor() with Uris
like this:

content://media/audio/12

This appears to be enough to keep most popular apps working!  Note
that it doesn't support apps that try opening the returned paths
from native code, which we'll hopefully be solving via direct
developer outreach.

Since this feature is a bit risky, it's guarded with a feature flag
that's disabled by default; a future CL will actually enable it,
offering a simple CL to revert in the case of trouble.

Bug: 111268862, 111960973
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ied15e62b46852aef73725f63d7648da390c4e03e