The code that creates a clone of an AccessibilityNodeInfo was not cloning
the extension objects (CollectionInfo, CollectionItemInfo, and RangeInfo)
and as a result if the original accessibility node info is recycled the
extension objects of the clone are also recycled and now if one tries to
recycle the clone gets an exception that the extension objects are already
recycled. Fun!
bug:10642952
Change-Id: I84192466bff0e865de04b79079e6ceecdffb37a6
New method setUpdateListener() on ViewPropertyAnimator that will
send out update events to the provided listener.
Issue #10118113 Offer update listener on ViewPropertyAnimator
Change-Id: Ib9f8fc6dbbc3c1c58113246d9a3b01e7ac27b14c
Logic in pivotXY setters noops when the new value equals
the previous value. However, the initial value is "0" even
though we actually use a value of the view's midpoint by
default. If an app sets a new value of 0, we don't send it
down to the native layer because it's the same as the initial
value, even though we're actually using a midpoint value instead.
This causes a conflict between the matrix used for invalidations
(which use the actual values the app set) and the matrix used
for rendering (which uses the default midpoint values).
The fix is to make sure we send down the initial value, even when it
equals the default value, by checking to see whether this is the
first time we're setting the pivot.
Issue #9337635 Clipping and bad rendering of view corners when y pivot is set
Change-Id: I4aa20c4a3c9a866ca17df3e067232b832d0ef504
Currently missing support for region anchor points, robust layout
when snapping to lines, and vertical text.
BUG: 10260603
Change-Id: I3463b4aa0039442159144e66922d67f5dfee58ed
ViewOverlays can hold Drawables and Views. But none of these things
show up in hierarchyviewer, so what you see on the screen is not necessarily
what you see in hierarchyviewer.
This CL adds logic to ViewDebug to enable these views/drawables to be displayed.
Issue #8943158 plumb overlay views through into hierarchy viewer
Change-Id: I020e85530a68390b37986269fa3e9e7e43725bab
Prevent noisy falsing. Minimum timeout is currently 40ms and can be
tuned for later. Consider un-hiding the ViewConfiguration query method
later.
Bug 10476944
Change-Id: Ib470735ec929b0b358fca4597e92dc81084e675f
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
