for both shell and legacy transition system.
The general sequence will be:
1. Create animation leash in core, pass to remote animation runner.
2. Remote animation finish, collect finish transaction before
transition happen. Apply finish transaction here if back event won't
trigger.
3. Check whether next transition is triggered from back gesture via
checking the open/close targets.
The 3rd step introduce another change, which to let the back transition
happen. Instead of consume next transition, we should try to find out
whether the participant was the animation target, because we cannot
assume what the opening target will do in resume stage. For example,
the opening activity could finish itself, or start another activity at
onResume, so in either case, the opening activity will become closing
activity. We can only ensure that activity will participant in next
transition.
So the more robust way should be, find out those targets which were
animated. For shell transition, and add a flag to the corresponding
change, then the transition handler can determine what to do based on
the targets. For legacy transition, ignore those targets when estimate
the transition type in AppTransitionController#getTransitCompatType.
Bug: 238474994
Bug: 131727607
Test: varify transition can be handled for some unexpected scenario:
1. launch new activity when close app.
2. launch singleInstance activity when close app.
Test: do back gesture on both shell/legacy transiton system, verify
no flicker happen whenever the back is triggered.
Change-Id: I9364be25c608f7b5797577d26b57bc7d6f2dde9c
Instead of pulling the active dream component, we push the component
when a dream is started. This ensures that the active component remains
in sync with the currently active dream.
Bug: 246091760
Test: flashed device and verified dreams are working correctly
Change-Id: Ifece2dc62486b74794f0d333d19bec2ab3bc9229
This fixes conflict between app transition and recents animation in the
following scenario.
1) App transition animation finishes after app closing animation, which
is controlled by recents, finishes.
During the app closing animation, recents makes the closing app surface
invisible, but app transition animation overrides it to visible again.
This causes a flicker.
2) App transition starts during recents animation.
When a user launches an activity, and immediately after that, swipes up
the screen to close the app. Or a user launches an ChooserActivity on
top of other activity, and swipes up to move back to home.
While recents is running, we assume animation on tasks is controlled by
recents, and visibility is commited without animation after recents
animation finishes. However starting app transition during recents
breaks this assumption, which ends up with playing one more unexpected
closing animation (so users see closing animation twice).
This change also obsolute the logic which exludes launcher activity from
app transition while recents animation is running, since app transition
is delayed until recents animation finishes.
Bug: 223499269
Bug: 231669960
Bug: 232060413
Test: atest AppTransitionTest + manual tests
Test 1
1. Launch Gmail app.
2. Click icon on the bottom tab (e.g. Chat).
3. Swipe up from the bottom (immediately after step 2).
4. Verify closing animation only plays once.
Test 2
1. Launch "Google TV".
2. Play a trailer.
3. Full screen and PIP mode switch twice.
4. Verify PIP window is shown.
Test 3
1. Change phone to portlait mode.
2. Launch Photo app.
3. Swipe up from the bottom.
4. Verify no rotation animation on the launcher.
Test 4
1. Launch photo app.
2. Take screenshot.
3. Hit share icon to share the screenshot.
4. Swipe up from the bottom.
5. Verify photo app closes.
Change-Id: I264b0daf1118b75fae481f0251ed50b556f27c5f
unless it has the privileged permission KILL_ALL_BACKGROUND_PROCESSES.
Bug: 239423414
Test: atest CtsAppTestCases:ActivityManagerTest
Change-Id: I35d20539ffac055a6d61260445620f45584bd9c5
When in 'tabletop' or 'book' mode, allow the display to rotate
even if it is frozen. Then return to the previously locked rotation when
the device is unfolded.
Bug: 240146362
Test: locally tested + ran atest on DisplayRotationTests
Change-Id: I9869f5b070fecd7df70e08323dfacef8b883f470
In previous design, it would create all necessary leashes when starting
back navigation, and they would be carried by `BackNavigationInfo` and
`BackEvent` and would finally deliver to the shell and animator side.
In this CL, we will use the adapter that wraps a back animation runner
to deliver all leashes in next surface placement after back navigation
has started.
In shell side, every animator should be registered by type, so the
adapter could deliver leashes via IRemoteAnimationRunner to the
target animator, and invoke callback when it finished.
This also eliminated all unecessary fields from `BackNavigationInfo` and
`BackEvent`.
Bug: 241808055
Test: atest BackNavigationControllerTests BackAnimationControllerTest
BackNavigationTest
Change-Id: I8bbec0d8d9631110c3d2788d958b50ae487520a7
Grant FULL_ACCESS_CELL_BROADCAST_HISTORY permissions to the shell identity for use within CellBroadcast MTS tests.
Bug: 236217191
Bug: 227422973
Test: atest com.android.cellbroadcastreceiver.compliancetests.CellBroadcastConfigTest
Change-Id: Ief5a4c168968b4dc8c9cf7cc071618d41c23d220
Ensure the new stylus buttons are not yet sent to apps.
DD: go/android-stylus-buttons
Bug: 246394583
Test: Build, Presubmit
Change-Id: I440a359ec8cffb60b9e87f2e51304c9b0320e16f
- Traditionally, we only show the current user and its profile users.
But, to support the multi-display, multi-user system, we'd like to
show the background users too.
- This CL will replace WMS.isCurrentProfile() with UMI.isUserVisible().
Bug: 239828153
Test: atest WmTests
Change-Id: Ie432e413aab256b6bac5d4537d19bdcbb0dd8956
To make sure the embedded TaskFragment surface will be updated when
Shell transition is enabled.
Bug: 207070762
Test: testApplyTransaction_collectTaskFragmentBeforeApplyChange
Change-Id: Id726b67cd30bd68e3ca4bc2665ab0a9024d76dab
Instead of having WM Core to "guess" when to request transtiion, let the
organizer to tell whether or not it needs to be applied immediately.
With the shouldApplyIndependently parameter, we can make sure the future
runtime API to change split layout won't affect other ongoing
transition.
Bug: 207070762
Test: atest WmTests:TaskFragmentOrganizerControllerTest
Change-Id: I658b0ba1ae9decc741f09cb53bfff2c45ea076a0
This moves from having a single global wakelock held by
WindowManagerService whenever any window on any display has
FLAG_KEEP_SCREEN_ON set, to having one per DisplayContent that is only
held when a window on that Display has the flag set.
Bug: 185157739
Test: atest WmTests
Change-Id: I82dcb693ad2bea0a243be4299dae836a1f53930c
Move most of the logic of the Settings' volume panel to a SystemUIDialog
to make the dialogs consistent with other system dialog.
Bug: 202262476
Test: manual build and launch the new dialog.
Change-Id: Ic27dcca77072dee2b78827e1eb58c28022b47265
1. When deferTransitionReady is called, it should un-ready the sync
group.
2. Do not call continueTransitionReady when the transition is no
longer collecting, such as transition timeout or abort.
Bug: 207070762
Test: atest WmTests:TransitionTests
Change-Id: I33a211d574da54ed220c7d0f7c12e201c5e1f681
