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
