This API allows an application to cancel deferred high-level input
events already in flight. It forms one tool of several to help apps
debounce input events and prevent things like multiple startActivity
calls, FragmentTransactions, etc. from executing when only one was
desired since it's otherwise not desirable for things like click
events to fire synchronously.
Change-Id: I60b12cd5350898065f0019d616e24d779eb8cff9
Issue #10460684 KLP API Review: android.view.transition and android.animation
Issue #10570740 Transitions: inflate transition targets from xml
Change-Id: I7a3f6d3aece2fcafc5efd555d033f79e86635c98
Previously, calls to ViewGroup.bringChildToFront() or View.bringToFront()
would need to be followed by calls to requestLayout() and invalidate()
to force the container to redraw with the new child ordering. This
change calls requestLayout() and invalidate() automatically.
Issue #8667065 bringtoTop does not work
Change-Id: Id37ce7a64dead82119e49f7a1b28385cf0d1f20d
CaptioningManager is now a first-class service in Context and can
have listeners added to it to monitor changes.
BUG: 10260603, 10461210
Change-Id: I2df5b2997537bb343d902b7ace3343ad483f3717
Previously, the TextChange transition didn't handle interruption/
cancellation at all, which made it problematic to use in any real
situation where a transition might get interrupted mid-animation.
Also, the way that it side-effected the text of TextView objects caused
errors in the UI when the transition was interrupted, because it would
not clean up after itself properly as new transitions queried the
current state of the UI.
Also, the prior cancellation logic for all transitions was not quite
correct; we were pausing transitions but resuming the animations, making it
tricky to write transitions that would restore state correctly.
Change-Id: I5a9f3c915e9834ec59ce1e1c3c96a88d11e4aa1b
ViewGroup.setLayoutTransition() has logic to cancel a previously-running
transition and remove the ViewGroup's listener from that transition. However,
it is possible for the transition to be set to null on the ViewGroup on the
cancel() call, making the next call to remove the listener crash with an NPE.
The fix is to use a temporary variable to hold the old reference and
not depend on the class instance variable remaining valid/non-null across
the call to cancel().
Issue #10488932 Hangout NPE in ViewGroup.setLayoutTransition on initiating a new conversation
Issue #10509201 ViewGroup.setLayoutTransition(null) causes crash when being called in LayoutTransition.TransitionListener.endTransition()
Change-Id: I7c181b79e6601024c93a8dc246d32b751f78b216
Previously, Visibility would determine whether a given view was
worthy of a transition by checking the visibility of that view's
parent hierarchy. This is done to avoid fading every view in
a hierarchy when only the top-most node should be faded.
However, the logic was flawed because it assumed the end scene
parent was stable between scenes, which is not the case with inflated
layout scenes, in which the parent views are not the same, even though they
may represent the same parents (via ids).
The new approach is to check information on both the start and end scene
parents, and to take ids into account when checking the state of these
parents in the start/end scenes. Also, avoid this logic altogether if the
transition is targeted at specific views (don't bother checking the
parents if the transition was told to fade specific views).
Issue #10442447 Transitions: Fades don't happen correctly in some situations
Change-Id: Icea24b892f2eff2d37c6436ccfe4e288aac84178
1. Migrate transparent transitions to the new optimized
background color animations.
2. Ensure sysui animation transparent -> opaque has enough
time to run before window manager crops off the content area.
3. Lose the individual alpha on each status bar icon if the bars
are not opaque. Animate the alpha if visible, make sure they
play together.
4. Documentation typo fix found in AnimatorSet.
Bug:10344949
Change-Id: I615668ce3c552d3df15dbba5cdeeca67549a0220
Removes several stray calls to clearAccessibilityFocus() that were
preventing temporarily detached views from retaining accessibility
focus.
BUG: 10089858
Change-Id: Ieb88a6cd14fe1069ebeeb78bc0edba7a10131f5b
Previously, setting a new LayoutTransition object on a container would
not do anything to the old transition object (if it existed). This means
that the previous transition could be mid-flight, changing stuff in that
container, and would continue doing so even after it was removed.
This could cause artifacts like that in the bug below where views
that are fading out would be put in the containers "disappearing children"
list for the duration of the fade... and then would never be removed from
that list because the container was no longer connected to that transition.
This caused items to stay visible even after they were removed from
their parent containers.
Issue #10119571 LayoutTransitions sometimes does not honor view's visibility
Change-Id: I3efa4065e47fa97c4dd90410bbc1a0273c2b8079
1. If app clears transient flag w/ a gesture, the touch-outside
listener would always win, causing an unsightly hide + immediate
reshow. Instead, give the app some time to clear the flag, then
perform a smooth transition in place.
2. When the transient bars are hidden, we do not know ahead of time
which background will be used on reshow (if transient bars are
revealed, the background is semi-transparent, if transient bars
are cleared, the background is opaque). Window manager is responsible
for showing windows, but sysui is responsible for setting the view
background. Therefore, we need some level of coordination between
the two in this case. Introduce two new non-public sysui flags
that represent the window manager's request to reshow the hidden
bars, but do not reshow until sysui acknowledges (by clearing the flag).
This gives sysui whatever time is necessary to prepare itself for
reshow, avoiding unsightly blip from opaque -> transparent during
the enter animation.
3. When both system bars are hidden, any low-profile changes are
moot. Avoid unsightly low-profile animations during bar reshow
by suppressing the flag in this case.
4. Improve transient bar home -> launcher transition by cancelling
the -> opaque animation. This also fixes a bug where hitting
home from the transient bar would leave you with a semi-transparent
bar in a non-transient state.
Bug:10284800
Change-Id: I238210561d8d5f70c1a517283b986c9105a1ec75
It's possible to update the native surface pointer while the
surface is locked (via lockCanvas). This leads to a surprise when
the surface is unlocked. Avoid the surprise by tracking the
locked surface separately.
Bug 10289713
Change-Id: I84346c952be859bbd91ceae7df07b91dabe0948e
