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

0 files changed, 0 insertions, 0 deletions