This is a mechanical refactoring like we did to split
InputMethodClient for Bug 118040692.
So-called "controlFlags" in InputMethodManager (IMM) was originally
introduced for IMM#startInput()/windowGainedFocus() [1] to carry
additional client information then reused when we unify startInput()
and windowGainedFocus() into startInputOrWindowGainedFocus() [2].
This CL mechanically moves the location where those flags are defined,
from InputMethodManager.java to a newly created file
StartInputFlags.java.
This is still just a mechanical refacotring / renaming. There should
be no user-visible behavior change.
[1]: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
7663d80f6b
[2]: I56934f18e30d90fcdf77bcbb0c35a92a5feb1b82
05c25f8a3a
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod.InputMethodDebugTest
Change-Id: If5a4810dece852edcff0d1119463711249bb7ef2
To support teamfooding of the new storage privacy features coming
in Q, we need apps to request new AUDIO/VIDEO/IMAGES permissions, but
most of those apps are prebuilts that won't land updates until
several months in the future.
So add system properties so teamfooders can "force" apps to request
these permissions, making them work on Q builds. Only takes effect
when isolated feature is enabled, and guarded with STOPSHIP to ensure
we remove it.
Here's a typical set of commands to use with this CL:
adb shell setprop persist.fw.force_legacy 1
- or -
adb shell setprop persist.fw.force_audio com.google.android.music
adb shell setprop persist.fw.force_video com.google.android.apps.photos
adb shell setprop persist.fw.force_images com.google.android.apps.photos,com.google.android.apps.messaging
- then -
adb shell setprop persist.sys.isolated_storage 1
adb reboot
Bug: 118504670
Test: manual
Change-Id: I631819648334994255256b6046bb4c8aec07ce3a
Removes obsolete KeyguardSliceView title area and adds doze callbacks
necessary to support new lock screen design.
Bug: 111405682
Test: manual
Test: atest KeyguardSliceViewTest
Change-Id: I07e96dbde68d4e5e38e1371526bedf59fc925b86
Process start time is recorded to detect whether two memory samples
come from the same process and how long the process was alive.
Bug: 118249210
Test: atest MemoryStatUtilTest and manually verified that data is in
statsd report
Change-Id: I7f49cd8bfc81c5e7e70e4f8b49729632eeec5798
* changes:
Removed references to ATMS.getLockTaskController() from AMS (34/n)
Removed references to ATMS.mHomeProcess and mPreviousProcess from AMS (33/n)
This is another follow up CL to my previous CL [1] that enabled
per-display InputMethodManager (IMM) instance (Bug 115893206).
What we learned in Bug 118341760 is that for some apps
view.getContext() may return a ContextWrapper subclass whose
Context.getDisplayId() and Context.getSystemService() are not
consistent with each other. Although this is considered to be a bug
of such a ContextWrapper subclass, application developers may not be
aware of the issue when such a problematic ContextWrapper came from
libraries that app developers happened to, or had to, depend on.
The key idea of this CL is that
view.getViewRootImpl().getDisplayId()
would be a more robust source of display ID than
view.getContext().getDisplayId()
for most of cases, because to which ViewRootImpl a given View belongs
is already a strong signal about to which display the View belongs.
As far as I've tested locally, this approach seems to be more
promising and is expected to give us better app compatibility in
multi-display scenarios.
[1]: I78ad7cccb9586474c83f7e2f90c0bcabb221c47b
4052a10f29
Bug: 118252837
Fix: 118341760
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Change-Id: If47e48bc8176657bf4bb882146d2affdfe457c90
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
Bug: 116349402
Test: Manual (settings_network_and_internet_v2 flag should should up in
Settings -> System -> Developer options -> Feature flags)
Change-Id: I9715b6b33478d992857538756d2515a560396e8b
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
- Can be enabled/disabled at channel and channel group levels
- An activity to launch can be added to notification
Test: atest, cts
Bug: 111236845
Change-Id: I9a4832211676cca4649d1f28e6e3e3157954d268
