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
With scoped storage, more apps will need to rely on
SAF to get access to non-media files. Allow more grants
by bumping up the limit to 512.
BUG: 149370983
Test: m
Change-Id: I26ae0ff660ecfb846a06fca00de7c1ad41ace2b2
System Server dex files has a special dexopt path while the
OTA service uses a PackageDexOptimizer backdoor which breaks
the assumptions.
Ignore any file loaded by system server until we update the
OTA service to use the proper PMS dexopt paths.
Test: adb shell; /system/bin/otapreopt_script 1
Bug: 160735835
Change-Id: Ic3d0a3127862c99c7e29ce552f6d89c248df1d0c
It was showing up as an unlabeled element, but can't usually
be scrolled anyway. And when it's scrolled it can still be performed
using talkback.
Fixes: 160329869
Test: enable talkback, drag down notification panel
Change-Id: Iaf4785213c58cb9efeb19aff4c164f78cdacfdab
If a requestLayout happens on a child view after the measure
pass, before the layout pass then the child view will not layout.
This can happen if a view calls requestLayout during measure
or during SurfaceView surface destroyed callback.
This fix addresses the second scenario by moving the callback
to after the layout pass.
Bug: 159183008
Test: Repro steps in bug
Test: go/wm-smoke
Change-Id: Ie2794a3751c99cabf6e07445c91159e35eeb1729
Add a Telecom command to stop the number blocking suppression that
happens after an emergency call.
Bug: 158798240
Fixes: 160667708
Test: atest CtsTelecomTestCases
Change-Id: I122de1962fb6aa48a3092c2aa323dcbdcbb8f42e
To replace usages of environment variable TREBLE_TESTING_OVERRIDE which
is problematic for some clients using setenv in a multi-threaded
environment.
Bug: 156668058
Test: hidl_test_java
Change-Id: I7f7c51b9cfb01a81941154dc406a599cc6edd151
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
As of ag/11546928, the framework emits an ACTION_CANCEL when the
proximity sensor turns off the screen, not an ACTION_UP. Previously, we
always expanded the shade in response to an ACTION_CANCEL. However,
after this change, this caused Dialer users to end up with an expanded
shade after putting the phone to their face, making it easy to
face-dial their notifications. This CL changes the behavior to put the
shade back to where it was when the gesture started -- either expanded
or closed.
Fixes: 155362798
Test: manual
Change-Id: I2d11d9f03bfe1e905028a640e2eb871d32e37248
Add null checks in both ContextWrapper and before obtaining
ContextImpl#getOuterContext.
Test: atest ContextTest#testIsUiContext_ContextWrapper
fixes: 160037462
Change-Id: Ic6a71dd9ac4b195d219d6e5431f2f2b199a400fa
