This reverts commit 975dd2c513.
Reason for revert: This is too risky for tm-qpr1
Bug: 161810301
Bug: 175861564
Change-Id: If906b4d538885fca407ce0bd7039c9d35b507032
Sometimes, views may not be visible for the user immediately after
laid out, so add flag for do the evaluation once the view is visible.
Bug: 234429643
Test: Manual, check the fill dialog is appeared
Change-Id: I6b96b68ffc4a4b1ee5f5056848c5c4996d21ae73
The existing Keyguard Occlude Animation Runner doesn't match the spec
for Dream in. It animates activity expanding from the center of the
screen. For Dream in, we have:
- Dream fading in
- DreamOverlay complications fading in slightly delayed, with each part
starting at different times.
This CL adds dedicated AppTransitionType and remote animation runner,
which animates Dream fading in. It doesn't implement the separate
animation for DreamOverlay complications.
Bug: 222507937
Bug: 240477956
Bug: 242864189
Fix: 240477956
Test: on device, wait for Keyguard to time out to Dream.
Change-Id: I5517ded2eea77ea962ca1551ed51dd997ff09993
Merged-In: I5517ded2eea77ea962ca1551ed51dd997ff09993
The client needs to call relayout to get the valid surface if
- mFirst,
- mViewVisibility != viewVisibility,
- mNewSurfaceNeeded, or
- mAppVisibilityChanged.
We didn't cover mNewSurfaceNeeded or mAppVisibilityChanged previously.
All of them are covered by FLAG_WINDOW_VISIBILITY_CHANGED.
Bug: 244521023
Bug: 161810301
Test: 1. Enable LOCAL_LAYOUT
2. Open Camera and double press the power button.
See if the preview screen of Camera become blank.
Change-Id: I37fb8ffc9063b72bf3abba5d29fc2f750e7fc64f
This stores the computed decor insets and frame excluding insets.
So it can save 99% time of recomputing the insets every time during
starting an activity. E.g. dozen times of "prepare display info/frame,
compute window layout of insets source windows, calculate insets"
becomes "get result from array".
The saved decor insets will be updated when:
- Display metrics is changed (DC#updateBaseDisplayMetrics).
- Insets provider is added/removed/changed.
Also
- Use DisplayCutout rather than WmDisplayCutout to simplify
passing the cutout between methods.
- Optimize getSourceProvider to avoid unnecessary object allocation.
This also fixes an issue that the display doesn't compute the latest
configuration when navigation mode is changed. Now it is fixed by
checking if the insets provider has layout changes and then recompute
screen configuration.
Bug: 238399969
Bug: 159103089
Test: atest DisplayPolicyInsetsTests DisplayPolicyLayoutTests
DisplayPolicyTests#testUpdateDisplayConfigurationByDecor
Test: Change navigation mode or display size (density) in Settings.
And then swipe-up or press home key, there won't be a
frozen effect (display configuration change).
Change-Id: If6c28a89939372e6362b92f469ef7d793e8ec215
The original patch reverted as commit
bc0d5539e6.
This patch only includes the part of refactors to make the calculation
of configuration around insets easier. The actual change of making extra
navigation bar treated as navigation bar and the fix of the UiDevice in
ui automator is in a separate patch to avoid being blocked and blocking
other changes for long.
Test: PlatformScenarioTests
Test: TaplTestsQuickstep, ThemeIconsTest, TaplTestsLauncher3
Bug: 238981445
Bug: 238985243
Bug: 238581838
Bug: 233945217
Change-Id: If966bcc8125300d47d5cd631f7db17ff027e5261
This passive window inset animation control listener
is used to for logging purpose when hide, show
method is called.
Test: atest InsetsControllerTest
Bug: 240192346
Change-Id: I399268ead9d04b356f10cc3e9ac1da9e31306e86
This fixes issues with Views that have their own custom
ViewTranslationCallback.
Bug: 236678324
Test: atest CtsTranslationTestCases
Test: manual - Verified on chat app that uses their own custom
ViewTranslationCallback; old and new messages are translated
Test: manual - Spot-checked translation on a few other chat apps
Change-Id: If4194bc8cde73a9cebb7b56594f6982855374410
IWindowSession#relayoutAsync is similar to IWindowSession#relayout, but
the former is an oneway method which just sends the layout attributes to
the server. Since the client can compute its own window frame, it just
needs to send attributes to the server without getting blocked for
receving the window frame.
In somes cases, the client still needs to obtain things from the server.
Such as:
- When view visibility is changed. The client maybe not be able to
receive the latest insets state while it is INVISIBLE or GONE. In this
case, the client needs to obtain the frame and the insets state. Also,
the client need to obtain the surface control when it becomes VISIBLE.
- When the insets state is stale but the config is up-to-date. This can
happen when WindowProcessController sends the new config to the client
before WindowState does. In this case, the client needs to obtain the
window frame from the server.
- When the position and the size of the frame are both changed. This
will trigger a BLAST sync, and the client needs to obtain the sync seq
ID.
For cases above, the client needs to call the original relayout method.
Bug: 161810301
Bug: 175861051
Test: Seamless rotation, fixed rotation, and regular rotation.
Merged-In: Ifb365789fa08103773fd3180e486ba1d92042fc5
Change-Id: Ifb365789fa08103773fd3180e486ba1d92042fc5
Ensure that all uses of TRANSITION_ANIMATION_SCALE setting are bounded
between 0 and 20.
Bug: 238178261
Test: adb shell dumpsys window windows | grep "Animation setting"
Change-Id: I01aeeeddcbcdce0824d61db6b8f4a8946595131d
There are 2 cases that will seeing IME jumpcut when IME insets animation
is controlled by the app during IME prcocess being killed & restarted:
1) When IME process been killed for some reasons
(e.g. force-stop package ), during IME restarting,
DC#computeImeTarget will select the remote insets target as the control
target and deliver IME leash to WM shell. If the focused window is
not in multi-windowing mode, it may have a timing that IME surface
may unexpectedly shown when starting insets animation from the remote.
2) Previously CL[1] fixed an IME surface visiblity issue when enabling
shell-transition that related to somehow IME insets source visibility
out of sync with the actual IME surface visiblity. The CL fix is
setting IME surface alpha value according to the requested visiblity in
InsetsSourceConsumer#setControl as a workaround. However, this may
cause a side-effect that after IME restarted and leash updated,
when the app requests showing IME animation, system calls setControl to
the client to set the same leash after IME onPostLayout, then
applyRequestedVisibilityToControl will be called before the
insets controller calls setInsetsAndAlpha for the animation, if the
IME requested visibility has visible, IME jumpcut will happen.
To fix this issue:
For 1), returning null control target in DC#computeImeTarget for
the above special case.
For 2), with CL[2] can fully fixed IME visiblity issue by letting the
client know the initial visibility of an InsetsSourceControl and
correctly animate insets when delivering the new leash or the
visibility change of the InsetsSourceControl. for delivering same
leash to request animation case, adding a check to call
applyRequestedVisibilityToControl only when there is no running
animation.
[1]: Iaacdf5f57e68b928e2a19036cbd8a137cf320497
[2]: I2c02e97e191ebd83238c0c54908e861d200d4c8d
Fix: 239808087
Bug: 209064170
Test: atest DisplayContentTests InsetsSourceConsumerTest
Test: manual test steps in b/239808087#comment2
Test: manual test as steps in b/209064170
0) Enabling shell-transition
1) Launching camera app
2) Swiping camera app to launcher
3) Verify status bar appear animation works
Change-Id: I242517a9214b36049d94e89d1ee63ffe505b91ac
(cherry picked from commit 8945b5bcfc)
This reverts commit 9e3cd0533f
and commit 74c760394a.
Initially we made a change to address a performance issue
in SurfaceView caused by holding the mSurfaceLock whenever
we went though the updateSurfaces loop. This had a side
effects of causing an ANR since the locking order changed.
The followup fix removed the lock but broke some API
contracts around lock and unlock canvas.
Subsequent fixes, which never went into QPR, introduced
new issues. Changing the locking order is too risky
QPR so lets revert and try to rework the locking
mechanism in U.
Test: app in b/234006724 does not ANR
Test: app in b/235188096 does not crash
Test: app in b/239895124 does not ANR
Test: app in b/239142077 does not crash
Test: atest SurfaceViewTest
Bug: 235188096
Change-Id: I99c5bb707ecad7c8d3c1fbd8b4105a77d58c145d
The toolbar should set the theme to the app's theme. Because the
service cannot get the application context, we should pass this
information from application to service.
Bug: 218833400
Test: manual. Use light/dark theme for app, the toolbar shows with
the same theme
Test: atest TextViewIntegrationTest
Test: atest android.widget.TextViewActivityTest
Change-Id: I6d4e4e117c680ce57e760a87987059eded09b2bc
CL[1] changed toggleSoftInput behavior with checking the last IME
requested visibility by using
ImeInsetsSourceConsumer#mRequestedVisible to toggle IME.
However, ImeInsetsSourceConsumer#mRequestedVisible will be updated only
when:
1) The IME insets is controllable for the app.
2) The caller uses WindowsInsetsController#{show, hide}
Since by design when the app is in multi-window mode, SystemUI will
take over the insets control for synchronizing task resizing / IME
animation concern, so it ends up making the app unable to receive IME
insets control then affects toggling IME visiblity.
Even though toggleSoftInput has been deprecated since Android S, we
still requires to support its functionality for old apps run in some
platforms by default in multi-window mode (e.g. ARC++ in freeform
windowing mode).
To fix the issue, replace the check logic with
getRootWindowInests().isVisible(ime()) to check the last IME visiblity
from the root window the served view.
[1]: I390dc029e7bcc30c200926a9bfbbbd0268a1f714
Bug: 240886131
Test: atest KeyboardVisibilityControlTest#testToggleSoftInput in ARC++
Change-Id: Iaf7ccc17a7c02711000983db0d65ad095fe9f8fa
The getSfInstance usage on ViewRootImpl is target to reduce jank
when moving split divider, but legacy split is going to be depracated
and it didn't used on new split too so we can remove whole related
codes safely.
Bug: 222696368
Test: build pass
Change-Id: Id492c738942c2e01fce85c231350d16ef88242f5
Naming of SoftInputShowHideReason#{SHOW,HIDE}_MY_SOFT_INPUT
constants may not clear enough to indicate its semantics.
Improve show/hide reasons of InputMethodService by:
-. Update constants naming to {SHOW,HIDE}_SOFT_INPUT_FROM_IME.
-. Introduce respective reasons to indicate different hide request
cases within IME process.
Bug: 224565148
Bug: 241890033
Test: presubmit
Test: atest CtsInputMethodTestCases and observe logs
Change-Id: I8b148e9b5ab05ff7b827c6b8fe23008ca30a8c4b
Merged-In: I8b148e9b5ab05ff7b827c6b8fe23008ca30a8c4b
Test: atest CtsContentCaptureServiceTestCases, observed events reported only once on scroll and stop as well as on fling
Bug: 211899037
Change-Id: Id67fcc360bf63fcab1d9f345c31d2bf7b9a173d6
In particular, these are to try and narrow down why the app window isn't
drawing in b/235463625 where the draw state for launcher is stuck in
DRAW_PENDING.
- mLastReportNextDrawReason: the reason the last draw was requested,
maybe useful in telling if wm is not requesting a draw if not set
- mLastPerformTraversalsSkipDrawReason: the reason perform traversals
returned without drawing (includes wm/predraw cancel reasons)
- mLastPerformDrawSkippedReason: the reason perform draw returned
without drawing
- mLocalSyncState: extra logging to confirm that the last sync actually
completes
Bug: 235463625
Test: dumpsys -T 60000 activity -v all
Test: dumpsys activity activities
Change-Id: I10118470fe62075920e9ce29fe449b0cfc8570c9
Merged-In: I10118470fe62075920e9ce29fe449b0cfc8570c9
WindowManager.LayoutParams doesn't override equals(). It returns
false if the instances are different. So after writing/reading
from parcel, even if the fields are identical, the comparison
of Arrays.equals(paramsForRotation, o.paramsForRotation) always
returns false.
This is the first step as a signal to decide whether the screen
configuration needs to be recomputed according to if there is a
layout change from decor windows.
Bug: 238399969
Test: atest FrameworksCoreTests:android.view.WindowParamsTest
Change-Id: I82582ff48064bbf009403d2c0980a69157860f90
System properties under persist.debug namespace can't be modified by
SystemUI. aosp/I5808bf92dbba37e9e6da5559f8e0a5fdac016bf3 introduced a
new namespace, persist.wm.debug that can be used for system properties
that can be overridden from SystemUI.
Move captions_on_shell to this namespace so we can update this flag from
SystemUI to simplify enabling it on devices.
Bug: 241464028
Test: build succeeds
Change-Id: Ifcf54b6dfa70ca52dfb51fb2f7f2e67d0568566a
This CL does the following:
* Remove caption insets when releasing the window decor
* Update caption insets in InsetsController when the caption is in WM
shell
* Dump LocalInsetsSourceProviders to help debug related issues
Bug: 241029178
Test: The caption type of insets provider is removed when window decor
is released.
Test: atest WindowDecorationTests
Change-Id: Ia20e1958588de3a7d965b3ac3d3e4333c67dff36
It used to notify if the window focus is gained or lost, mark it as
oneway to prevent it block the system server when outgoing.
Bug: 238050065
Test: Trigger back gesture and see the logs
Change-Id: I17b79a361edadf03d2b2887cce7ec29c3968e3e5
Currently the session id is genrated from a static random number
generator created with new Random(), all has the same seed value
in the given Context, so the sequence it generates is identical
across processes
Ideally the id should be generated from a center controller to
avoid collision, the content capture met the same problem before.
Follow the same solution used in content capture, we use SecureRandom
which produces non-deterministic output. But it still good to come out
a more stable solution in the future release.
Bug: 239385816
Test: manual
Test: atest CtsTranslationTestCases
Change-Id: Ie75acfa6a55a58e0c0a709f2a5ae1c6e5d6dc339
