If an Insets animation was cancelled before it could complete,
handle it gracefully.
Fix: 154381667
Test: Run monkey runner that on any window that has edit text
atest InsetsControllerTests
Change-Id: I052a0455f536a1c839a2782e54f19143295ba6c6
This makes view root dispatch the up-to-date WindowInsets to the app.
Fix: 166619182
Test: Steps in the bug (comment#12)
Change-Id: I8c47e3be84357f65084a7d9994f7d7b68f15611e
(cherry picked from commit fd94351305)
This makes sure the write operation (NativeInputApplicationHandle
::updateInfo) is always called from window manager side once when
calling SurfaceControl.Transaction#setInputWindowInfo or
InputManagerService#setFocusedApplication. If the info of input
application handle is changed, a new instance will be created.
That avoids the race condition of reading the fields of the same
InputApplicationInfo instance from input dispatcher.
Bug: 171857140
Bug: 161334769
Bug: 174768985
Test: WindowInputTests
Merged-In: Ief84bbe6e6fa4da5309912059904932ccf775b75
Merged-In: I70de9835c7699fe6f56fc3655b0fee5c317ecc3a
Change-Id: I70de9835c7699fe6f56fc3655b0fee5c317ecc3a
Some apps like Netflix crashed while handleWindowFocusChanged but mView
somehow has became null.
It's fair to check null for mView.findFocus() since other places
in ViewRootImpl that calling this method also add null check.
Fix: 153862451
Test: atest CtsInputMethodTestCases
Change-Id: I86bd5f3193deabe28bb425a8564017f7b32b90f3
(cherry picked from commit bdaa14bf18)
Resolve SearchViewTest and InputMethodServiceTest failure when
landing CL[1] in QPR branch.
Also, CL[1] mentioned window focus behavior changes from R,
ignoring STATE_VISIBLE or STATE_ALWAYS_VISIBLE request doesn't enough
to fix unexpected keyboard visible issue when same window focused with
the above softInput flag without editor focus, since there is no
additional unspecified window focus to hide the current soft-input
as prior to R's behavior.
To fix that, we introduced new SoftInputShowHideReason to hide
soft-input when the same window focused without valid editor focus
after screen unlock, in order to align with the behavior prior to R.
[1]: I37ae6e30d1de581ba15131c2a90396b3a522a4d6
Bug: 161506356
Test: atest CtsInputMethodTestCases
Change-Id: Id51863a5b67d5d79d903adf43f19b52bd139e03f
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
Forcing client to show system bars would clear system UI flags at the
client side. SYSTEM_UI_FLAG_LOW_PROFILE would be cleared as well in
previous Android versions. This CL makes the behavior compatible.
Fix: 167892531
Test: Steps in the bug
Change-Id: I466a05120a08ac95b619eadd8291fc546d3bb450
The application may get Resources instance from Resources.getSystem()
and context.getApplicationContext().getResources(). Since fixed
rotation is introduced that allows an activity to start in a different
rotation than the current display, when using getConfiguration() and
getDisplayMetrics() of these Resources instances, the orientation
and metrics need to be the same as current display is rotated.
Otherwise the app may show unexpected UI layout.
Although it is not recommended to use global resources/config for
activity. One of the goal of fixed rotation transform is to simulate
the app is started in a rotated environment, so this CL makes the
configuration and display metrics of system resources are consistent
with application and activity for compatibility.
About WindowProcessController and ActivityStackSupervisor:
The process configuration passed to LaunchActivityItem may be
associated from activity. if the sequence number of configuration
is overridden by activity, the configuration may be ignored when
launching the activity because the sequence number isn't larger
than the previous process configuration. Although there will be a
ConfigurationChangeItem later to update correct state, the app may
get the intermediate state with old configuration and metrics.
About ResourcesManager and DisplayAdjustments:
There are 2 new fields appWidth and appHeight added to
DisplayAdjustments#FixedRotationAdjustments because the display
metrics from Resources.getSystem() is independent from activity
configuration. Only window manager knows the rotated size, so
the values need to send to client and then ResourcesManager takes
the adjustment to change the global display metrics.
About WindowToken:
When fixed rotation is applied on the token, send the
FixedRotationAdjustmentsItem first so the later configuration
change can pick the adjustment at ActivityThread. And because the
registration of activity configuration only occurs on add/remove
activity, if it is only switching to another existing activity in
different orientation, the process configuration still needs to
be updated.
About ActivityThread:
The code flow for a rotated activity (DA = display adjustments):
- Launch new activity
handleLaunchActivity: override app DA
handleConfigurationChanged: adjust global display metrics by DA
performLaunchActivity
createBaseContextForActivity: override activity DA
- Resume existing activity
handleFixedRotationAdjustments: override app and activity DA
handleConfigurationChanged: adjust global display metrics by DA
handleResumeActivity
Also some minor corrections:
- Fix wrong display metrics adjustment that xdpi and ydpi should
not be swapped because they are physical attributes.
Bug: 167564038
Test: atest DisplayAdjustmentsTests
AppConfigurationTests#testRotatedInfoWithFixedRotationTransform
WindowProcessControllerTests#testProcessLevelConfiguration
DisplayContentTests#testApplyTopFixedRotationTransform
Change-Id: I60bedc7e09f54683d5e857ccc51402d5d144cd9e
Merged-In: I60bedc7e09f54683d5e857ccc51402d5d144cd9e
Bug: 165267251
Test: manual -- ensured that the time needed to hold is 0ms if the
screenshot_keychord_delay debug value is not set, and that the
delay can still be changed using
adb shell device_config put systemui screenshot_keychord_delay <ms>
Change-Id: Iab989ecf14ef379658130adbced241e084554e63
Merged-In: Iab989ecf14ef379658130adbced241e084554e63
(cherry picked from commit bf82822698)
Bug: 166149440
Test: manual (flash automotive device with all system bars and show/hide
insets using WindowInsetsController), atest InsetsStateTest
InsetsStateControllerTest
Change-Id: I500b2fb0129739c6fc609561377d90cca6e45f7e
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 display frame is used to limit the windows boundary. The frame is
the same as the parent frame in most cases if the window is not
attched. However, if a window doesn't have any layout related
window/sysui flags and the soft input mode is not ADJUST_RESIZE, the
display frame doesn't need to be inset by IME (but the parent frame
does).
Fix: 163435784
Test: atest ViewRootImplTest DisplayPolicyLayoutTests
Merged-In: Ia61933120027642d1f0e0a490546071ca2b6c853
Change-Id: Ia61933120027642d1f0e0a490546071ca2b6c853
... of mWindowAttributes. Apps might update LayoutParams with
softInputMode unspecified on applying insets, and this can cause
infinite loop in the previous logic, because we would auto-compute
softInputMode for the unspecified one, which makes app's softInputMode
never be the same as the one in ViewRootImpl.mWindowAttributes.
Fix: 163009478
Test: Print stack trace before calling requestFitSystemWindows() and
follow the steps in the bug.
Test: Open Messages, go to attachments, reopen IME
Change-Id: I2341121b69209688c2f6fb033f51611b21422a04
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
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
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
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
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
Don't return the current view when finding the next or previous view.
Bug: 158492287
Test: atest cts/tests/tests/view/src/android/view/cts/FocusFinderTest.java
atest frameworks/base/core/tests/coretests/src/android/view/FocusFinderTest.java
Change-Id: Ib5c1854d1a13b9469ca55dfbf0be61bead47e29e
(cherry picked from commit 713af5fdd3)
