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
Instead of maintaining local copy of all appIds and sandboxIds,
StorageManagerService will just get required packages info
from PackageManagerService when an user starts and passes it
to vold.
Bug: 117988901
Test: manual
Change-Id: Ib7411645bd0c5e2801bc998d92fda00bceb9c258
1. There used to be double offset from the origin.
This is because we used to (in NYC) make the surface position to display
origin and draw content with a offset in the surface. However we lately
let the surface position be inherited from task surface position, so
there will be an offset from surface position and an offset from drawing
content in that surface.
To fix the bug I removed the offset in drawing content. That offset is
provided by WindowState#getBackdropFrame() so it just solved the issue
by moving frame to the origin.
2. Window quickly jumps when user starts drag resizing a window.
The reason is out of synchronization between surface insets change and
graphical buffer update. When user is drag resizing, we suppress window
shadow to save some graphical resources, which will consequently change
surface insets. Change in surface insets will cause the surface being
repositioned to reflect the new surface insets because window frame
doesn't change. However the content is still drawn at old location with
old surface insets for the first a few frames, so the content jumps to a
wrong location for a split second. This also happens when users stop
drag resizing.
I kept the old surface insets when user is resizing so there won't be
surface reposition at the beginning and end of drag resizing, but still
suppress the shadow by adjusting the elevation of DecorView.
Also fixed a synchronization issue we found in BackdropFrameRenderer,
and cleaned up code in it.
Bug: 113254346
Test: Manual tests show drag resizing for both freeform and split screen
works.
Change-Id: I42349f88f14af35fac7c65e784462b5f2e1a71c7
The original Process::readProcFile could only read files smaller than 256 bytes.
This change allows the function to read in larger files. For files smaller than
256 bytes, the added cost is only an extra read call, which returns zero.
Documentation has also been added to Process::readProcFile.
Test: Used in change 5168194
Change-Id: I82f27355276e08f96bdb5fe7da49514a87afb429
Upcoming changes will prevent apps from reading "_data" columns
directly, which is required to convert between DocumentsProvider and
MediaProvider Uris. To solve this, delegate the call() through
MediaProvider, where it can perform the "_data" lookup on behalf
of the caller.
Also add new getMediaUri() call to offer symmetry.
Bug: 111960973, 117627072, 110961701
Test: atest android.provider.cts.MediaStoreUiTest
Change-Id: I53c640704d86047d7a4bf1702aca027873395abf
This is a follow up CL to my previous CL [1] that enabled per-display
InputMethodManager (IMM) instance.
One thing I mistakenly assumed in my previous CL is that there is
always a process boundary between IMM#createRealInstance() and
IMMS#addClient(), which is not true when IMM is being instantiated in
the system server process. This means that IMMS may associate an IME
client to wrong PID/UID/DisplayID when certain conditions are met.
With this CL, IMM#createRealInstance() always clears calling identity
so chat IMMS#addClient() can work correctly even for local Binder call
scenarios.
[1]: I78ad7cccb9586474c83f7e2f90c0bcabb221c47b
4052a10f29
Bug: 115893206
Bug: 117594679
Fix: 118335706
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Test: Manually tested with manually simulating the problematic scenario
Change-Id: I318d32d8997b0acb4fb193fe46831bdc9a4dd083
This CL aims to factor out InputMethodManager#forContext() and its
related methods. This is still a mechanical refactoring hence there
should be no behavior change.
Bug: 115893206
Bug: 117594679
Bug: 118335706
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Change-Id: I457745e18bfbd3e2787c5b438eee962a1928326e
