At the end of the animation (when going from larger to smaller),
we are left with a scaled surface, that we want to seamlessly
resize to an unscaled surface of the new size. Because we have scaled
the shadow region of the surface, the position of the content
will differ before and after the resize applies. We use new
SurfaceFlinger API to cause position updates to apply after
resize. Because we have to switch into SCALING_MODE_FREEZE,
we could end up prematurely cropping the window, so we
switch to using screen space crop for the pinned stack.
Bug: 28899837
Change-Id: I9b762a237413e4fa3d432e67d30c7125bfef484c
This CL changes the target of VD specific animators to VectorDrawable,
instead of RenderNode. The benefit of doing so is that animators can
now detect whether the animation is meaningful by checking whether
their VD target is in the display list. If not, that means the VD is
not drawing for the current frame, in which case we can be smarter
and more power efficient by removing the animator from the list and
posting a delayed onFinished listener callback.
By setting VD as the animation target, when an ImageView decides to
update its drawable from one AVD to something else, we'll be able
to detect that the previous AVD is no longer in the display list,
and stop providing animation pulse to the stale AVD, which is
something we couldn't do previously. This change also
handles the case where one AVD instance could be drawn in two
different views.
Bug: 27441375
Change-Id: Iaad1ed09cfd526276b95db0dd695275c28e074e8
When calculating scroll amount, we should check whehter focus
is visible using before-scrolling position.
It's possible that the view is already scrolled, then visible
insets changes (eg. IME went away). Previous scroll position
still makes the focus visible, but it will leave the focus
in a bad position when it should be scrolled back.
bug: 29025892
Change-Id: I091f16bebc4c1e5ba831616c51ab2ac75d4c4b3c
am: 80b8e67a99
* commit '80b8e67a991c7992dfa25c0f280f5593ade3f2c5':
Fixed a few accessibility issues with notifications and groups
Change-Id: Ica5eb674e8c12a633c86c3cfb6620bed08fae117
am: ddc6de1eda
* commit 'ddc6de1eda495790e6564438994df5d49ddf248f':
Fixed a few accessibility issues with notifications and groups
Change-Id: Iaa2ddc8bedaad3623190e65116f0d8b85687eb78
am: ddc6de1eda
* commit 'ddc6de1eda495790e6564438994df5d49ddf248f':
Fixed a few accessibility issues with notifications and groups
Change-Id: Ieec9526a2c54edd2f0d3b34973cc61f610f452ae
am: 819cbb3dd3
* commit '819cbb3dd32bb0c721b4fef427f4ed84e208b15a':
Close IME when attaching dock stack
Change-Id: I31b42a8f971f74e11febe9635fa6489924914226
am: c5fc6c602c
* commit 'c5fc6c602c16f0e985d8f8ba7f94075229e52320':
Close IME when attaching dock stack
Change-Id: I40abf80fcea522c8082e622c33f3a6726f781145
am: c5fc6c602c
* commit 'c5fc6c602c16f0e985d8f8ba7f94075229e52320':
Close IME when attaching dock stack
Change-Id: I7921bf88bb49134d1fbde752d5fa963786ec1d46
am: 56d4dae9ec
* commit '56d4dae9ec7503660bdd762e2e04f267d7f2704c':
Update the light center when the root view's layout changed
Change-Id: Ifedcb88adb38eb23ad82b7836c5de5f738c80c10
am: e78ba24c17
* commit 'e78ba24c176fd6a0c54eaf7e52be545952ba1ab7':
Update the light center when the root view's layout changed
Change-Id: Ic973b9b47df6550c5170c2248c7e0f2ab25c6a57
am: e78ba24c17
* commit 'e78ba24c176fd6a0c54eaf7e52be545952ba1ab7':
Update the light center when the root view's layout changed
Change-Id: I03e6d183e2a98b4d08f1e5be74447ddf942e8337
am: 4f6ae7bbaa
* commit '4f6ae7bbaa4654e14d70e9fa503ceb713c90c342':
DO NOT MERGE Remove Pointer Capture API
Change-Id: Ieceb1c9248bfc618ed1c70821d4cf746128bc679
am: c396f0f70e
* commit 'c396f0f70ef40ea0fb42a0872a13f4c4e9a6a5f0':
DO NOT MERGE Remove Pointer Capture API
Change-Id: Iede50a709849ed27cb9723a565b946e00fb23be7
am: c396f0f70e
* commit 'c396f0f70ef40ea0fb42a0872a13f4c4e9a6a5f0':
DO NOT MERGE Remove Pointer Capture API
Change-Id: I77cb742feacdd3b8af0cf33d4e7ab246f776417f
am: 1d4f1cda2d
* commit '1d4f1cda2de08887ce7036fa8a6f76d5ff0b378f':
Force pending transactions to flush before screenshot.
Change-Id: I618c4c794e0c26ead6995a8aa1ff3d0d42cc45a0
am: 39e8022a75
* commit '39e8022a75507be06179c3de7358cebb1bb22e06':
Force pending transactions to flush before screenshot.
Change-Id: Ib8dd84af143226e2b62cdfa51066e68ba7802d28
am: 39e8022a75
* commit '39e8022a75507be06179c3de7358cebb1bb22e06':
Force pending transactions to flush before screenshot.
Change-Id: I2dc18293c1507a7f427c3ad554d3f70467dac98d
am: 8bfb5b971d
* commit '8bfb5b971d46daecf72c7c8e179279fb9206ad00':
Changes based on API council feedback for performContextClick
Change-Id: I8317e028e1bd65ddf2ceb5c36b6db2fdb763f986
am: 7c17e70f2f
* commit '7c17e70f2f795ca06006ff2560c8b8211ce1dd52':
Changes based on API council feedback for performContextClick
Change-Id: Ief8c3036b93c28b27ba2f117ec656d38a1562fcf
am: 7c17e70f2f
* commit '7c17e70f2f795ca06006ff2560c8b8211ce1dd52':
Changes based on API council feedback for performContextClick
Change-Id: Ibf53f8081db8b847d18eaa8fee983b677b62f9bc
am: ef68474698
* commit 'ef684746980061bb5950ae2505229648d9f146d6':
Make IMM more robust to spurious window focus-in
Change-Id: I77ae5953aa9afc64ef1cd3252d6d2ff936890b62
am: 50c33d1ca1
* commit '50c33d1ca1218ec00eb37f66a7c11315603c9ef7':
Make IMM more robust to spurious window focus-in
Change-Id: I1d9a138798d982f2164907b49713a7b90cec9adc
am: 50c33d1ca1
* commit '50c33d1ca1218ec00eb37f66a7c11315603c9ef7':
Make IMM more robust to spurious window focus-in
Change-Id: I3c80320a5c6711bf3aaeb3043fe54c741c127966
InputMethodManager (IMM) has a latch switch named IMM#mHasBeenInactive
to forcefully refresh IME focus state when an inactive client
(IMM#mActive == false) is gaining window focus. However, it turns out
that there is a race condition where the latch could be unexpectedly
turned off. This is probably what we have been chasing in bug 25373872.
Imagine the following scenario:
1. An app receives MSG_WINDOW_FOCUS_CHANGED w/ hasWindowFocus=false
2. IMM inside the app receives MSG_SET_ACTIVE w/ active=false
3. The app receives MSG_WINDOW_FOCUS_CHANGED w/ hasWindowFocus=true
4. The app receives MSG_WINDOW_FOCUS_CHANGED w/ hasWindowFocus=false
5. The app receives MSG_WINDOW_FOCUS_CHANGED w/ hasWindowFocus=true
Here, our current strategy has been:
A. Turn on the latch when MSG_SET_ACTIVE (w/active=false) is handled.
B. Turn off the latch and ask IMMS to start input when
MSG_WINDOW_FOCUS_CHANGED (w/ hasWindowFocus=true) is handled.
The problem is that in the step B IMMS can reject the request if
WindowManagerService (WMS) tells that the window in question no longer
has window focus. This is not surprising because the app is
just handling messages in the message queue sequentially. As a result,
the IME focus is not updated expectedly in the step 5, because the latch
is no longer enabled as we expected.
With this CL, the latch will be re-enabled if the app fails to start
input while IMM#mActive is false as a short-term solution.
In future we may want to address this issue in protocol level so that
we can address other known issues such as bug 26851566 at the same time.
Bug: 28281870
Change-Id: I60adb38013b063918b074c7b947649eada77b2c8
