Rearrange how we generate the transition specs, which involves
creating a thumbnail on the mainthread (about 10ms on large
devices): First, we put launching the activity onto a handler
thread (with default priority), to free up the main thread. Then,
we immediately start generating the thumbnail such that when the
future calls us we have the generated spec already handy.
For that we need to be able to supply a specs future into
ActivityOptions, to avoid race conditions. Furthermore we need to
make sure not to call into WM while creating specs, to avoid WM
lock contention.
Test: App -> Recents -> Same app, inspect app transition logs
Test: Double tap recents for quick switching
Bug: 32668632
Change-Id: Ic6ec65c2560f67cade3b5ddde9f79ee13e9ba32c
The fact whether the process is running or not is not necessarily
a reason to not show a starting window. Sometimes the process with
an activity gets killed, but later gets restarted because of some
broadcast or service without recreating the activity. In this
case, we still need a splash screen to hide the recreation delay,
which is usually as expensive as if the process is not running.
Test: Open Calendar, kill `pid calendar`, reopen it, make sure
starting window is shown.
Test: As above but with a couple of other apps - with and widhout
trampoline activities.
Test: Boot freshly and open a couple of apps from recents
Change-Id: I8c4f928fca77b5446cab55c89bc69adbaaaa8da3
Fixes: 37951698
No need to wait on the next relayout - this can only delay the
transition. Makes hot launches a lot more consistent.
However, this made it too fast! We then hit a race condition when
the app transition was already starting but no other layout was
done yet. When another layout was executed we noticed that we need
to report resized for the starting window, clearing it's drawn
state, which set startingDisplayed=false, which jumped the app
window animation to the end.
To fix this, make sure not to report another resized immediately
after the initial layout, as the client already knows the latest
(because it calls relayout at some point before it starts drawing).
Also fix "animating" async systrace for better analysis.
Test: Open/close size-mismatching task snapshot 100 times, ensure
no animation skipped.
Test: Look at app transition logs, ensure more consistent.
Test: Overall system sanity testing (open a couple of apps/dialogs
etc).
Bug: 32668632
Change-Id: Id795cd6a84f22e6a619089cb9554fc5033477ad2
Bug: 34600579
Test: manual - change device lock under synthetic password, verify
old data on disk is erased.
Change-Id: I247bd1f095dd27335e671981f9e2d77e149af84f
Merged-In: I247bd1f095dd27335e671981f9e2d77e149af84f
Wait on the lock if the queue is paused instead of
just spin-looping.
Test: Close app, make sure screenshot gets persisted.
Bug: 36631902
Change-Id: Id7940468391d6cdfc74bb9341c1639f72d469387
Bug: 34600579
Test: manual - change device lock under synthetic password, verify
old data on disk is erased.
Change-Id: I247bd1f095dd27335e671981f9e2d77e149af84f
