hardcoding it to 16ms
> Creating a utility class for caching display property changes
Bug: 128940249
Change-Id: I6f9a214548de65bd1c8530508d665ee88312da4a
When window animation is cancelled, we skip running the animation. But since we
initialize the UI before the animation started, the UI is never reset.
Bug: 79657221
Change-Id: Ic420d1d99f5242541e6809f3207355ea9876ca9c
I'm not sure how/when this case occurs (perhaps during some transition/state
change), but manually removing the floating view matches the symptoms in the
bug.
Bug: 72996404
Change-Id: I1e7c1a338fcd16c8e07b3c49fb9c9b2097eb2708
> If launcher already started, creating the state transition only after threshold crossed, so that previous animations are not cancelled
> Not posting animaiton callbacks at the front of the queue, as that sometimes causes it get executed before onNewIntent
> Farking the activity as forceInvisible while launching an opaque app, so that quickly pressing home/back runs the reverse animation
> Not running state animations when force-invisible is true
Bug: 77830325
Bug: 77898806
Change-Id: I50a7e915ca35fd6aeb284c8f321ecca74396fe98
so that the animation is reset when we start a state animation from
launcher
Bug: 74975768
Bug: 75290288
Change-Id: If7f71f087d7bb64fb25c085c476a6fcbc86518e2
Intead of finishing the entire animation (launcher animation and
window animation), we finish just the launcher animation.
Bug: 73071035
Change-Id: Ied84cb641f3cedc367433ad99d21ab1b258ae7f8
