* changes:
[automerger] Reapply back button alpha at end of state animation am: 5273b695c2 am: ac5a07cb59
[automerger] Reapply back button alpha at end of state animation am: 5273b695c2
Reapply back button alpha at end of state animation
* changes:
[automerger] Do not execute controller callbacks, if controller is null am: aa168d5c11 am: a4785c9a3f
[automerger] Do not execute controller callbacks, if controller is null am: aa168d5c11
Do not execute controller callbacks, if controller is null
* changes:
[automerger] Do not execute controller callbacks, if controller is null am: aa168d5c11
Do not execute controller callbacks, if controller is null
We determine the toAlpha at the start of the state change, but something
may happen (e.g. we lose window focus) during the transition. So to make
sure we don't end in a state with the wrong alpha, reapply at the end.
Bug: 109835691
Change-Id: I271a1d269f861f698efbb8e66148a924c8620e71
- Use OvershootInterpolator based on velocity (consistent with swiping up
from home)
- Scale down recents as well, to be consistent with adjacent pages scaling
up when you launch a task
Bug: 109709720
Change-Id: Ie47309058ccf673a4b86c40c843c415beb2d8dc7
* changes:
[automerger] Reset state amanger, when switching from state animation to task launch animation am: 0cd2a254b2 am: f99417f8bb
[automerger] Reset state amanger, when switching from state animation to task launch animation am: 0cd2a254b2
Reset state amanger, when switching from state animation to task launch animation
* changes:
[automerger] Reset state amanger, when switching from state animation to task launch animation am: 0cd2a254b2
Reset state amanger, when switching from state animation to task launch animation
A pending task launch animation can set some transient properties on state manager.
If the next animation is not a state animation, and reapply is not called, the
transient properties are never cleared
Bug: 79935289
Change-Id: I18398c74692960c460af537bf0c48801e69ac11e
We were setting the alpha of the target window to 0 on the UI thread, and setting it
back to 1, through ClipAnimationHelper on background thread
Bug:109701914
Change-Id: I4abb73298b5e957a66f91c5654b184cdd398724b
* changes:
[automerger] Log source component instead of current task base intent am: 3cc3df59af am: dee4137e5e
[automerger] Log source component instead of current task base intent am: 3cc3df59af
Log source component instead of current task base intent
* changes:
[automerger] Log source component instead of current task base intent am: 3cc3df59af
Log source component instead of current task base intent
* changes:
[automerger] Adding a pending invisibility flag, which is used to indicate that the launcher is not really invisible, but consider it invisible for window transitions am: 1c63c72c1a am: 7ef92daaf5
[automerger] Adding a pending invisibility flag, which is used to indicate that the launcher is not really invisible, but consider it invisible for window transitions am: 1c63c72c1a
Adding a pending invisibility flag, which is used to indicate that the launcher is not really invisible, but consider it invisible for window transitions
* changes:
[automerger] Adding a pending invisibility flag, which is used to indicate that the launcher is not really invisible, but consider it invisible for window transitions am: 1c63c72c1a
Adding a pending invisibility flag, which is used to indicate that the launcher is not really invisible, but consider it invisible for window transitions
is not really invisible, but consider it invisible for window transitions
When a recents animation is cancelled, the callback can be received before or after the
wallpaper animation. To ensure that wallpaper animaiton runs properly, we keep the launcher
forceInvisible=true, only for that particular animaiton and false everywhere
Bug: 109735443
Change-Id: I5b22cc3327c8cd53a836d10e09fc88ae103becfc