+2
−0
+1
−1
Loading
Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more
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