Initial implementation of merge-able transitions
This adds a couple things to support "merging" of transition
animations in shell.
1. Moves the finishing surface operations into a transaction that
gets sent to shell. This does a couple things: it complies with
the contract we have where during a transition, only the player
should touch relevant surfaces; and, it makes it so that the
player can merge the transaction with other ones.
2. Keeps a queue of "pending" transition animations in shell and
either merges them or runs them serially.
3. Any transition that becomes ready while another is playing will
first be sent to the playing handler to give it a chance to
"merge" the incoming transition.
There are 3 expected responses to overlapping transition animations:
1. Cancel the currently playing transition and immediately start
the incoming one. This can be achieved by having the currently
playing transition cancel itself (ie. immediately finishing) when
a merge request comes in. Then the rest of the shell transition
logic will immediately start the next transition.
2. Queue up the incoming transition to play once the current one
finishes animating. This is basically the default as long as
the current transition simply rejects/ignores merge requests
3. Merge the incoming transition. This is achieved when the
currently playing transition actually does some special logic
to handle the incoming transition. It then calls the finish
callback for the incoming transition (before it finishes its
own animation) to indicate that it has been merged (or "consumed").
Basically, any time the finish callback for a transition is
called before a pre-ceding transition, that transition is assumed
to have been merged.
Bug: 183994113
Test: atest ShellTransitionTests
Change-Id: I3cb54e221d57642306ddf15827c21d8881b014d0
14 files changed