As WindowTokenClient#{onConfigurationChanged, onWindowTokenRemoved}
requires to post on mainthread, in case posting runnable accquires more
java objects to increase java heap memory, use PooledLambda to obtain
cached runnable for saving memory usage.
Also, use ActivityThread.currentActivityThread.getHandler to get the
main handler rather than creating the new object.
Fix: 215447496
Test: run MemoryOnBoot
Change-Id: Idb2c01a0da02ff669e1a3f1a55f4841f7aa258ba
This change adds two WM transit types for opening and closing dream
activities, which allows the system to define transition in and out of
dreams, that are currently being overriden by other transitions.
Set the priority to be just below keyguard transit. The keyguard
occlude/unocclude already correctly handles the dream open/close
animation.
Bug: 222507937
Bug: 220311554
Test: atest WmTests:AppTransitionControllerTest
Test: manually on device by entering and exiting dreams over keyguard,
launcher, and settings. observed animation and relevant types of WM logs.
Change-Id: Iedfa279d56cd9d4c4679cb3b697ee74a98ef727b
We currently close the IME by having the target application forward KEYCODE_BACK to the IME process through InputMethodManager#dispatchInputEvent and having the IME handle the keycode in InputMethodService#onKeyDown. When apps opt in to OnBackInvokedDispatcher API, we will not dispatch KEYCODE_BACK to apps anymore. Thus we need to migrate IME to the new API for it to close on back invocation.
This implementation forwards OnBackInvokedCallbacks from the IME process
to the app process. This is necessary because all callbacks need to
exist in the app process for them to be considered by hardware back keys. While back gestures go through WM to resolve callbacks from the focused window, hw keys are directly sent to the focused window's ViewRootImpl, bypassing server side back nav logic.
Bug: 228358882
Test: atest CtsInputMethodTestCases:KeyboardVisibilityControlTest
Test: atest CtsInputMethodTestCases:InputMethodServiceTest
Test: atest CtsInputMethodTestCases
Change-Id: Ie207b63b11a56c9b2173f26b734a27b13ebccc60
This flakiness is due to race of config updates when WindowContext attaches to
DisplyArea.
This CL fixed it by:
1. Don't dispatch config updates to the client side when registering to
DA. We have reported the value by the return value of
#attachWindowContextToDisplayArea.
2. Add lock in WindowTokenClient#onConfigurationChanged to avoid race.
During applying DA's config to WindowContext, WindowContext may get another
callback from the server side and dispatch to ComponentCallbacks
unexpectedly.
Bug: 190019118
fixes: 228911504
Bug: 230022846
Test: atest RegisterComponentCallbacksTest --iterations
Test: atest WindowContextTest WindowContextTests
Test: atest WindowMetricsWindowContextTests
Change-Id: I2d749a058c7a3828c8c8288040236f005aa00ab6
Default focus should be on primaryActivity when a placeholder is shown.
This is a short term improvement as focus navigation works from primary
to secondary but not in reverse.
Fix: 229138140
Test: atest WmTests:TaskFragmentOrganizerControllerTest
Change-Id: Ic4e2280e4b37a8fa04fc532245a5d0cfa4e5e012
When the activity exits PiP and is reparented to the original Task, the
organizer should handle it as a new launch.
Bug: 225371112
Test: atest WmTests:TaskFragmentTest
Test: atest WmTests:TaskFragmentOrganizerControllerTest
Change-Id: Ia7e32e995a35e167b0d76e701c972b269ae068cc
Bug: 228533817
Test: Try swipe back to home on Flag Flipper (with Predictive Back
Animation toggle enabled in Flipper) and make sure animation looks good.
Try in both landscape and portrait mode.
Change-Id: If2165827a0f66f8e0bd8f78483577c3ac4c9f213
When the Task contains multiple activities, activity entering PiP will
be reparented to a new PiP Task. In this case, we should notify the
organizer about the behavior, and prevent the dependents from closing as
a result of an empty TaskFragment.
Bug: 225371112
Test: atest WmTests:TaskFragmentTest
Change-Id: I6f0138c0532d2d0249de38fd84d1a4690f266c07
Adds the implementation to allow or block navigation to a
new task in the policy controller for a virtual device. Will
only change behavior if the cross navigation allow or block
list is included and the navigation does not occur from
the default display.
Bug: 223915401
Test: atest WmTests:DisplayWindowPolicyControllerHelperTests
atest CtsVirtualDevicesTestCases
atest WmTests:ActivityStarterTests
Added test in ag/17503735
Change-Id: I3dfb9dd93c0edf4634320c52a3fc40c4bf473085
Main motivation is to store a back callback's exact priority value in WM. This is required by the IME migration (ag/17076160) to compare the priority levels of IME window callback and focused window callback in BackNavigationController.
This also consolidates the WindowState#mSystemOnBackInvokedCallback and WindowState#mApplicationOnBackInvokedCallback fields into one field, as tracking two fields for one callback was error prone. We had to remember to clear the application / system field when the other field is set, and failing to do so has resulted in bugs such as b/222675481.
Bug: 224856664
Test: atest BackNavigationControllerTest
Test: atest WindowOnBackInvokedDispatcherTest
Test: m -j and test back behavior throughout the system on apps that
opted in and out.
Change-Id: Ic57113610d934f33d2c9ca4cef59f39a9b87e832
Test: m -j update-api. Build and flash and test back behavior throughout
the system.
Bug: 227500290
Change-Id: Ibdb13d02e044741d05d99f1cad96e43dc0129fe4
- Better logging
- Remove method form OnBackInvokedDispatcher interface (but not the
implementation)
- Add test for ag/17211289
Bug: 222675481
Test: BackNavigationControllerTests#testUnregisterCallbacksWithSystemCallback
Change-Id: I6a3ae30da7e29dddda116acd8fa0c9af4b9faa6e
Before, we register remote animation per organizer, and assume it only
organizes in one Task. Now, we register per organizer Task if there is a
rule that supports split in the Task width.
Bug: 207720388
Test: atest WMJetpackUnitTests
Change-Id: Iac4e10af9aa0e7846c81b036b2cf708b6cbe627e
There can reset the system bars color once the splash screen window is
going to be removed, so the real system bars color can be
controlled by app, without waiting for the reveal animation.
Also clear this effect when transfer splash screen to client, so client
can control the color on their own.
Bug: 196550450
Test: verify no status bar color changed when playing reveal animation.
Change-Id: Ibb353d350fa2921188c8c4b54f8e029ee3869c16
Adds a trigger to DisplayContent that creates
unfold transition before applying the display size
and marks it as ready when the sizes are applied.
Adds a placeholder animation for fullscreen tasks.
Bug: 204925795
Test: enable shell transitions, open an app, unfold =>
check that app surface is animated
Change-Id: Ia88178a7c7849a99c17b4d18117a05b2a0fb8b7f
This is such that they can be controlled from Flag Flipper UI.
Boolean flags introduced:
persist.wm.debug.predictive_back - Overall switch for the new back infra
persist.wm.debug.predictive_back_anim - Animation switch
persist.wm.debug.predictive_back_always_enforce - Switch to ignore per
app opt-in flag and always enforce new behavior
persist.wm.debug.predictive_back_screenshot - Screenshot switch. Not
added to Flipper yet.
Test: Flip the flags in Flipper and verify behavior is as expected.
Change-Id: Icff098035119fb83f393e20c6ac590be2f22c845
We are not gating the new back dispatch by targetSdkVersion in T. The new dispatch is controlled by the enableOnBackInvokedCallback app
manifest flag (which defaults to false).
Test: m -j update-api
Bug: 195946584
Change-Id: Iab59051ec5b6336ca4d42cc47015fe86a3f37942
Deprecate also the shadow radius for PiP in Task
Bug: 206508708
Test: Verify the PiP enter/exit/move/resize transitions
Change-Id: I8ff83dd4e626a3455373fed6c908cf131ecae8fe
When ViewRootImpl is going to draw a frame due to a blast sync request,
we call forceDrawNextFrame to ensure we get a draw this vsync, even if
RT animation rendered a frame. This will ensure that we aren't required
to reschedule a draw either in rt thread or ui thread since we'll get a
frame back as long as there's an available buffer.
We also disable rt animations if a sync set has started with Syncer and
then re-enable when the sync set is complete. This ensures we don't
continue to acquire buffers for a render thread scheduled animation
during a UI animation since we want the UI request to get the buffer.
Test: Open internet dialog from notification shade on 60hz device
Fixes: 217621394
Bug: 200284684
Change-Id: Ic1534d21b0ee2ad82f20ff34df4cbbbad87557fd
ViewRootImpl was removing the callback from the server after the
windowState was removed, which was consistently failing resulting in an
exception in the log.
Now the removal is done before the ViewRootImpl's window removal
Test: Manually check that the error is not appearing in the log
Bug: 226089354
Change-Id: Ie9cb9940791b16d6ae1b243079794583c87b1a5c
- Use the focused window instead of the topApp window
- Instead we now rely on WindowManagerService to get
the focused window.
- SystemUI does not have ActivityRecord so we can't rely
on the top window of the Task to find the correct
window on which the callback will be called.
- Introduce a Builder for BackNavigationInfo
- This reduces the number of variable needed outside the synchonized
block.
- It also reduces the number of early return of BackNavigationInfo
instances
- Adding log messages to help further debug the method.
Test: BackNavigationControllerTests
Test: Manual dismiss of SystemUi dialog in QS
Bug: 216604581
Fixes: 221458292
Change-Id: I9ba2c7f89956f34d6338824502c210b3e58dc076
Introduce builder for BackNavigationInfo
Change-Id: I14b4a4b3abc8f417998b7b32831cb3d5c4faa491
