Fixes a flicker that occurs during transitions between windows.
This happens for two reasons:
1.) Control is immediately transferred to the new window, and the
previous window didn't get a chance to play the animation.
This is addressed by adding logic to keep control on the
exiting window for the duration of the transition - similar to
what we do with the target for z-ordering purposes.
2.) Upon the input connection being severed, the InputMethodService
immediately hides its window, preventing any animations whenever
the input connection changes
This is addressed by moving hiding of the surface into the
controlling windows - where upon receiving control, we now
trigger removal of the IME surface if we don't show it.
Additionally:
- Now ensures that any requests from the ImeInsetsSourceConsumer
ensure that they come from the window that is currently served
by IMM.
- Removes the transparancy clause from isImeTargetFromDisplayContentAndImeSame
to match the updated IME target computation in DisplayContent in [1].
[1]: Iedd5f7407926167f4891ce9b7e9a79e22751e668
Fixes: 153145997
Fixes: 150902448
Test: atest WindowInsetsAnimationControllerTests
Test: atest DisplayContentTests InsetsSourceConsumerTest
Test: Open app with IME, press HOME button, verify IME smoothly animates away
Test: Open Messages, open a thread, open IME. Click search icon, verify IME opens in the search activity
Change-Id: I4910c2a06cc67b0470477b245fc1de54b75f10f9
This information will be used for attribution of CPU
usage to work source UIDs.
Bug: 158232997
Test: atest FrameworksCoreTests:com.android.internal.os.BinderCallsStatsTest
Change-Id: Ic9fcc1d62515dd11a1fbade80264412615014919
The current implementation has a problem where:
In the autofill side, there can be multiple autofill sessions existed
at the same time. But in the IME side, there is always only one
InlineSuggestionSession at any given time. It will cause the previous
autofill session to fail communication with IME.
It would better change to drop down UI when the autofill inline
suggestions don't be shown in IME.
How to reproduce this issue:
To add an input field with autofillable into the authentication activity
of InlineFillService. To tap on the input field of the authentication
activity during the authentication flow. After completing the
authentication, the inline suggestions won't be shown in IME.
BTW, if the input field is marked as non-autofillable, this issue won't
occur.
Manual verification:
1.Tested this patch with InlineFillService and it worked well.
2.Feng also helped to test this patch with the webview
(sort of randomly), and didn't find any broken case
Bug: 158877106
Test: atest CtsInputMethodTestCases
Test: atest CtsAutoFillServiceTestCases
Test: new CTS test Ie1d9055b0eabfcaa00861869467be8dcee25833e
Test: manual verification with InlineFillService
Test: Feng also helped to test this patch with the webview
Change-Id: Ib06edd823fa4478f34362164f3f7dd3544e51705
Removes the necessity for LMS to call back into client code to inform
the client that a location listener has been removed. This is replaced
with weak references instead, which allows the garbage collector to
handle cleanup instead. This simplifies LMS implementation and makes it
less buggy.
Also includes some rewrites of getCurrentLocation to use a dedicated
AIDL interface now that the onRemoved channel is no longer available,
as well as various other minor refactors.
Test: manual + presubmits
Change-Id: Ic61ce278c44e23bc5da5b703f89f6e656e89dea2
After selecting a suspended app, the package monitor would be
unregistered even though the app would never be launched. This would
cause an IllegalStateException on the next selection of any target,
and crash the sharesheet. Check for a suspended target before
unregistering.
Fixes: 160015744
Test: manual, follow BR steps and pause an app
Change-Id: I1b0c79bad0fa75aea6a543b6f8a4848720faa0c8
For sharesheet, assume that the reordering of elements will make the
last assigned ViewHolder invalid for async icon loading. If we already
have an async task for the particular ResolveInfo, update the
ViewHolder target when it's complete.
Fixes: 158172791
Test: atest ChooserActivityTest ResolverActivityTest
Change-Id: I0ea9f443512f91e8fa4c5d6b72a35e9231e69e51
Make estimation on incoming binder calls. If there are too many
binder transactions from certain caller with certain transaction
code, log it. The threshold is configurable via device_config.
The estimation here is based on the heavy hitter detection on
steams. It's less accurate than the actual stats, but also less
usage with the memory.
Currently there are two sets of watcher configurations:
the default one with a higher threshold and an "auto" one with
a lower threshold. The former one overrides the later one;
while the later one will be activated to run for a while in case
there are consecutive ANRs, but it's throttled to run only
up to once an hour. For now both of them are turned ON by default.
Example of the output:
06-19 22:31:49.695 1000 1523 1609 W ActivityManager: Excessive incoming binder calls(>33.3%,2000,1744ms): [1041,com.android.server.appop.AppOpsService,checkAudioOperation,8,34.2%]
06-19 22:32:32.744 1000 1523 1609 W ActivityManager: Excessive incoming binder calls(>33.3%,2000,4938ms): [10160,com.android.server.am.ActivityManagerService,refContentProvider,25,50.7%]
Bug: 155522521
Test: Pick up a service & code and loop "adb shell service call ..."
Test: atest HeavyHitterSketchTest
Test: atest FrameworksCoreTests:BinderHeavyHitterTest
Change-Id: I4cdcce5d02797ef71190172e40a09b543478760f
