This was being ignored, but we should plumb the information
through so that the defaulthandler doesn't apply an animation
on top of the scene-transition (which expects a jumpcut).
Bug: 190806800
Test: take screenshot, then pres edit button
Change-Id: Ib1bda6220012cf3b8f85fccac4cc50e1327b9886
The shell-transition player "Transitions" only supported
playing one animation at a time. It supported limited
support for concurrent animation via `merging`, but this
is for specific/curated situations. Since support via
merge is complicated, there weren't many implementors and
instead, by default, animations would just jump-to-end
to allow the next animation to start immediately (to
minimize perceived latency).
Unfortunately, if there are TRULY independent transitions,
this mechanism is unweildy as it'd require adding support
for any incoming transition into any active animation.
This CL moves the existing queue/merge mechanism into a
"track" and then adds support for multiple tracks to play
simultaneously. This way, for transitions which aren't
independent, the mechanism doesn't change; however, for
truly independent transitions, their corresponding
animations can also run independently.
The expectation is for WMCore to assign track ids to
transitions. Then the player (Transitions.java) can
use this information to either play them in parallel
or, in the future, do some type of merging on its own.
The default is that, all transitions with the same
track-id will play in the same track and serialize
with eachother -- but otherwise the tracks are independent.
There may, however, be some situations where a transition
might conflict with more than 1 track. In this case,
we just fall-back to a global "SYNC" and basically wait/
flush all the running animations/tracks before starting.
Supporting anything fancier is not worth the effort since
this situation isn't likely to be very common.
This SYNC is actually implemented by just generalizing the
existing SLEEP failsafe mechanic. We now just treat an
incoming SLEEP the same as SYNC.
Bug: 277838915
Bug: 264536014
Test: atest ShellTransitionTests
Test: this change, alone, should be a no-op so existing tests too.
Change-Id: I97ca21e0917be884cac105a6cb2d2c656f0e4207
This change will ensure that if multiple SurfaceSyncGroups are created
for the same ViewRootImpl the SurfaceSyncGroups will maintain an order.
The scenario that could occur is the following:
1. SSG1 is created that includes the target VRI. There could be other
VRIs in SSG1
2. The target VRI draws its frame and marks its own active SSG as ready,
but SSG1 is still waiting on other things in the SSG
3. Another SSG2 is created for the target VRI. The second frame renders
and marks its own second SSG as complete. SSG2 has nothing else to
wait on, so it will apply at this point, even though SSG1 has not
finished.
4. Frame2 will get to SF first and Frame1 will later get to SF when
SSG1 completes.
The code ensures the SSGs that contains the VRI maintain an order. What
happens here is we create a new SSG that's a placeholder. Its only job
is to prevent a SSG from completing. The active SSG for VRI will add a
transaction committed callback and when that's invoked, it will mark the
placeholder SSG as ready. If a new request to create a SSG comes in and
the placeholder SSG is not null, it's added as part of the new active SSG.
A new placeholder SSG is created to correspond to the new active SSG.
This creates a chain to ensure the latter SSG always waits for the former
SSG's transaction to get to SF.
Test: SurfaceSyncGroupTests#testOverlappingSyncsEnsureOrder
Test: WmTests:com.android.server.wm.SurfaceSyncGroupTests
Bug: 272189296
Change-Id: I921d78e347ecfb9786ebe4643308b347c5436332
This method returns if the callback is an OnBackAnimationCallback.
This value can be serialized and can be used to determine whether or not to run predictive animations when you have no way to check the callback directly, for example in the BackAnimationController you only have access to the IOnBackInvokedCallback.
Why?
OnBackAnimationCallback is used by apps that want to play a custom animation when the user swipes back.
OnBackAnimationCallback exposes BackEvent every time there is a new progress value.
Ideally, we would like to expose the velocity only on the last progress value (or onBackInvoked()), but to do that we have to change the API. We are unable to do so now.
Therefore, we decided to handle the fling gesture in the system instead. As a result, we now need to determine if the app supports OnBackAnimationCallback so that we only send the fling if we have an OnBackAnimationCallback registered.
BackAnimationController can now produce more back events. This is done by producing more events when the user lifts their finger. This way, the developer does not have to handle the fling gesture. This approach was chosen because the velocity cannot be exposed in the BackEvent.
Test: atest BackNavigationControllerTests
Bug: 263402927
Change-Id: I4d85253c9ade39f35ef0d8c70c6b1c7c31b1390d
If a caller adds a Transaction to a SSG after its already complete, make
sure to immediately apply the Transaction and log a warning. It's better
for the Transaction to get applied instead of waiting around forever.
Also cleaning up some logs in SSG
Test: SurfaceSyncGroupTests
Bug: 272189296
Change-Id: I6810c5e0c20f3fd5c7d8bde16f24bc05a0495b4f
The velocity of the `BackMotionEvent` will be used to fire additional events when the user lifts their finger.
Note: Velocity is calculated for the last event only, for performance reasons (see `VelocityTracker.computeCurrentVelocity`).
`Float.NaN` will indicate that the value has not been calculated.
Test: atest BackAnimationControllerTest
Bug: 263402927
Change-Id: I301636f572eb4e59abc69f6fee11d8dba5647a16
This allows apps like the Launcher to write ViewCapture data to the
wmtrace directory so it can be shown in their UI. Normally, Launcher
doesn't have the correct file permissions. Also, Launcher's dump method
is called after the wmtrace dir is written to the bug report, so we need
to dump sooner via a callback method invoked inside WindowManager.
Bug: 224595733
Test: Latency tested this change and verified that a bugreport generated
the file properly, moved it to the wmtrace directory, and was picked up
properly by the go/web-hv tool.
Change-Id: I9dc8e61070d2470354b79c1758103f9b2b00ac36
This passes a "debug" id along with transitioninfo
so that we can correspond transitions across processes.
Also adds debug-names to remotes so that they can
be identified across processes as well.
Bug: 276349701
Test: just added logs, so no tests needed.
Change-Id: If67524f8a82de366db2f96c8821b08eaec45ecb5
This will include a CHANGE info for tasks which have
moved to top while still visible. This allows recents to
be reported when a translucent task is running and also
provides a hook for multi-window order changes.
This also recalculates back-tasks on transient-launch finish
since, otherwise, the behind activity isn't paused. This
was because it wasn't changing visibility and just re-ordering
doesn't recalculate lifecycles.
Bug: 274696524
Test: TransitionTests#testMoveToTopWhileVisible
Start a translucent task, enter recents, then restore the task.
Change-Id: If21d076eed4db88139ffc8a7c4c018c2ef5aad93
This CL adds a new source SOURCE_ARBITRARY_RECTANGLE for the caller to
specify an arbitrary rectangle as the insets source frame in
InsetsFrameProvider. WindowContainerTransaction can use it to add and
remove insets with public insets types. This is a step to remove ITYPEs.
Bug: 234093736
Test: Presubmit
Change-Id: Ia9a851fe5bd0d09e4af9d170c839da5d0f8bf605
So far it is no problem so make it default behavior.
Bug: 151908239
Test: android.view.WindowMetricsTest
Change-Id: Ia56699786c57a95aff38e78f458b2dbe6793f22f
Add supporting for Activity#overrideActivityTransition.
The CustomizeActivityAnimation will load both enter and exit animation
for the close activity transition. And it is only valid if the exit
animation has set and loaded success. If the entering animation has not
set(i.e. 0), there will load the default entering animation for it.
Also note that if both overrideActivityTransition and windowAnimations
has set, system should prior to load the animation set from
overrideActivityTransition.
Bug: 259427810
Test: atest ActivityTransitionTests BackNavigationControllerTests\
CustomizeActivityAnimationTest
Change-Id: Id182dc8f93f55a256de68c1fb6cc91fd08450e3e
A few apps in Kids Space request "reverseLandscape" orientation when
Display#getRotation returns ROTATION_270 expecting it to correspond
to the seascape display orientation while it may correspond to the
landscape one when config_reverseDefaultRotation is set to true.
This CL overrides the "reverseLandscape" orientation with "landscape"
in the context of apps running in the Kids space when
config_reverseDefaultRotation is set to true
Fixes: 265589619
Test: Run `atest WmTests:WindowManagerServiceTests`
Run `atest WMShellUnitTests:KidsModeTaskOrganizerTest`
Run `atest WmTests:LetterboxUiControllerTest`
Change-Id: I85688413571478f5acaa340624bb470f5aeb422f
The task overlay activities should be on the same layer as
other activities in the task. It is already ensured to be
on top of other activities by making it always-on-top in wm
hierarchy.
Bug: 262404281
Test: build and presubmit
Change-Id: I0f4123355d711acb3a87e91c9523468f789da154
Add a new API to WindowContainerTransaction to support updating the
container density.
This allows us to update the configuration object with a new density
value that would get applied by the WindowOrganizerController.
Allow list density changes in WindowOrganizerController as an allowed
configuration change.
Update DesktopTasksController to change the density value when moving a
task to desktop or back to fullscreen (if enabled).
Use system property persist.wm.desktop_mode_density to override the
density for desktop tasks. Allowed range for the density override is 100
to 1000.
Bug: 272529050
Test: atest DesktopTasksControllerTest
Change-Id: I96539176252fdd5b69b02e3bd1b6a4231990decb
SurfaceSyncGroup is timing out on an emulator target. Use
ro.hw_timeout_multiplier to address this and other slow
target.
Test: presubmit
Bug: 273314551
Change-Id: I83dc352a24caabba2429ecf3f76c63500fa8a44d
Each display needs its own root, so transitions that span
multiple displays will require multiple roots and correspondence
between members and their associated displays.
Bug: 261418859
Test: TransitionTests ShellTransitionTests
Change-Id: I02022fe610a43eef6c03b5729e77a7fcbc4674ca
TaskSnapshotWindow has no need to process any input events.
If it has a valid InputChannel but no InputEventReceiver,
it won't receive events sent by InputDispatcher like TouchModeEvent.
This may cause an ANR.
Test: when TaskSnapshotWindow is showing, verify that touch on
Notification shade won't trigger ANR on TaskSnapshotWindow.
Bug: 271552817
Change-Id: I9595b15fa277ebff4be375eed220cb57533a1a2c
When ActivityRecord#mLaunchTaskBehind is true, the newly-launched
task is positioned behind home. However, for compatibility reasons,
it's marked as visible, so there's no way for Shell to tell if a
newly launched task should be shown to the user or not.
This CL adds a transition change flag for this purpose.
Bug: 268178951
Bug: 268130984
Bug: 268131581
Test: atest StartActivityTests#testStartActivityTaskLaunchBehind
Change-Id: I3c5b517de5c56fe365cc9dd487e7d42dfa584513
Merged-In: I3c5b517de5c56fe365cc9dd487e7d42dfa584513
(cherry picked from commit 7c56142676)
For cross-activity animation, support seekable animation if app
has customize activity exit transition by Window#setWindowAnimations or
android:windowAnimationStyle.
Because there could fall back to default cross-activity animation when
the customized animation was not able to load, defer assigning the
mActiveCallback when received onAnimationStart.
Bug: 259427810
Test: verify customized animation can play.
Test: atest BackNavigationControllerTests BackAnimationControllerTest\
CustomizeActivityAnimationTest
Change-Id: I59dc6ef75a226c634b06f483aeed7aec03087d18
Adds wrapper class WindowInfosListenerForTest that enables using
WindowInfosListener in tests.
Bug: 263311858
Test: presubmits
Change-Id: I8a5f83b0557db26aa0d05e1ffdfcbb7d374afc38
This reverts commit c930398694.
Reason for revert: reland ag/20426257
Refine the file strcutre. The remove window process now extract as an
interface, each type of starting window can handle it based on
different scenario.
For legacy starting window:
Splash screen window and related API => SplashscreenWindowCreator
Task snapshot window related => SnapshotWindowCreator
Support windowless starting surface:
- Draw splash view to a surface => WindowlessSplashWindowCreator
A simple splash screen view with a static icon on it. It can play
default reveal animation while remove.
- Draw snapshot to a surface => WindowlessSnapshotWindowCreator
Similar to TaskSnapshotWindow just no window. It will play a fade
out animation while remove because there is no default window
animation.
Add another callback IWindowlessStartingSurfaceCallback for windowless
starting surface. Unlike starting window, there is no "addWindow"
signal to let core know the surface is create.
Also note the windowless starting surface is just a surface, it won't
support window-like features such as configuration change or resize.
Bug: 257857570
Test: atest SplashscreenTests StartingSurfaceDrawerTests
Test: verify legacy starting window work. Simulate that create splash
screen view fail won't crash SystemUI process.
Change-Id: Id95be6a4ff9472955b4f2b717748a331b1fad804
Ensure there are timeouts in case something goes wrong with each level
of the SurfaceSyncGroup. It's better to timeout and not blocking all
dependant SSGs.
The timeouts are the following:
1. VRI has a timeout when it has mPausedForSync > 0. If the timeout is
invoked, that means someone was holding the SurfaceSyncGroup for VRI
without adding it to any SurfaceSyncGroup.
2. If a SurfaceSyncGroup has been added as a child or a parent of
another SurfaceSyncGroup, it will get a timeout set. This is because
it can now affect other SSG and we don't want them blocking others.
If they are a standalone SSG, we don't care if they don't complete
since it only affects itself.
Test: SurfaceSyncGroupTest
Bug: 237804605
Change-Id: I1a7886f8d51764b82d8eb0408433f5d77d2299cc
