Previously, there were two distinct problems with how delayed transitions were being run: - there would be a delay between the transition being put into a preDrawListener (to be kicked off when that listener fired) and being removed from the pending list. This allowed another delayed transition to be run in parallel, which would cause conflicting/ clobbering issues with transition values on the same objects. - there would be an extra frame delay in some cases due to how/when the delayed transition would be started. Specfically, we would postOnAnimation() to call a method that would then add the onPreDraw listener. This two-step forwarding caused issues noted above. The fix is to simply add the transition to the preDrawListener immediately, removing the two-step problem, and also ensuring that the transition is only removed from the pending list when it is actually started, which prevents other transitions from starting in the meantime. Also, added more debug logging to help chase future issues with transitions. Change-Id: Ie2ff8e73d29f342512842e9641bd8d605e74544c
…
cherrypick from ics-mr1 docs: source for nw app Change-Id: If50f407a0e56fa802fe9beedaa650e3a131872b2
…
…
Description
No description provided
Languages
Java
77.3%
Kotlin
9.2%
PowerBuilder
6.6%
C++
5.5%
AIDL
1%