The TODO was in a Javadoc comment so it was exposed in public docs.
It looks like the TODO was removed from master, and per SME, it's
okay to remove it from RVC too.
Test: make ds-docs-java
Exempt-from-owner-approval: Docs-only change
Bug: 169103613
Change-Id: I7694bbc8fde0e7366db57770ff1792a1d2f3e6c1
Merged-In: I129f96f6ed716e25c476bacbdb38799675919b9a
When there is an insets animation, we will stop updating insets source
frames until the animation is done. The previous logic didn't update the
frames within the requested state while the animation is done. And the
frames was relied by InsetsPolicy while playing transient bar animation.
If the frames don't match the display, the insets would be wrong, and
the animation wouldn't be played correctly.
Fix: 161134197
Test: atest InsetsControllerTest
Merged-In: Id8f3c1956fbfe3ad16f167ff76297dde6c634e81
Change-Id: Id8f3c1956fbfe3ad16f167ff76297dde6c634e81
(cherry picked from commit 23c75281ef)
The previous logic restores the system bar as long as its insets source
is visible. There can be a timing issue that if the user swipes to show
transient bars while an immersive app just becomes the control target
but the hide-bar info haven't sent to WM yet, WM will re-show the bar
incorrectly.
This CL uses the requested visibility and the behavior to decide if we
should restore the postion and the visibility.
This CL also refines and caches the arguments of showTransient. In this
way, we don't have to create the array every time while invoking that
method.
Fix: 161247175
Test: atest InsetsPolicyTest
Merged-In: Idef314dfe6625399b88b3dacb4c74c7071453497
Change-Id: Idef314dfe6625399b88b3dacb4c74c7071453497
(cherry picked from commit 533682ebb3)
When there is an insets animation, we will stop updating insets source
frames until the animation is done. The previous logic didn't update the
frames within the requested state while the animation is done. And the
frames was relied by InsetsPolicy while playing transient bar animation.
If the frames don't match the display, the insets would be wrong, and
the animation wouldn't be played correctly.
Fix: 161134197
Test: atest InsetsControllerTest
Merged-In: Id8f3c1956fbfe3ad16f167ff76297dde6c634e81
Change-Id: Id8f3c1956fbfe3ad16f167ff76297dde6c634e81
Previous logic in onStateChanged notifies insetsChanged based on the
change of mLastDispatchedState, which can make us dispatch redundant
insets changes to the app.
In this CL, we only notifies insetsChanged if mState is really changed
in onStateChanged -- we use the final mState (after updateState and
applyLocalVisibilityOverride) to compare with the one before changing.
Fix: 161924448
Test: atest InsetsControllerTest WindowInsetsControllerTests
Test: Swipe up to home while IME open and see if there is any jank
Merged-In: Ia536cdf76805caa56ca1b6eaf2b3db83b6ecd94e
Change-Id: Ia536cdf76805caa56ca1b6eaf2b3db83b6ecd94e
This was intended to fix a reparent issue when preserving
surfaces before the app was closed. That is no longer happening
so this change is no longer needed.
The reason this causes the flicker is it waits to reparent until
next frame. However, the frame can be submitted before WM gets a
chance to show the new Surface since that request is sent to WM.
Therefore, the SurfaceView can end up getting reparented to the
new SurfaceControl before the new SurfaceControl is visible,
causing it to be hidden for a few frames.
This reverts commit c1dcac9568.
Reason for revert: b/162377855
Fixes: 162377855
Test: Split screen with SurfaceView doesn't flicker
Change-Id: Ic7a209b7aa66e278b99a526d8427f140b31de0f6
When referring to a client (piece of software), it's better not to use
a personified pronoun, such as "his" or "their". Changed to "the".
Change-Id: I5d79e70a9135d6f1e8da493fcdd50921b9696e31
Test: none (docs-only change)
Bug: 160937339
Inline APIs.
* limitations with multiple locales.
* limit on max number of suggestions.
* guidance on managing the order of inline suggestions when inflating.
Fixes: 161486684
Test: atest android.autofillservice.cts.inline
Change-Id: Ia560d48f95730d79bc340ff9eb0cf4a5909bf0d3
We use same reference from TextView to set the initial
surrounding text. The actual surrounding text may be
modified before retrieval since the mSurroundingText
is mutable. Use a copy of subText should avoid this
concurrent issue.
Bug: 160390184
Test: atest FrameworksCoreTests:EditorInfoTest
Change-Id: I6082a4cae2fcdc4c529dc14e2e5e7a45ab1aae4d
(cherry picked from commit 0ebe70cb0f)
