The original bug is fixed already, but showed up some problems in
the underlying fade-transition implementation. This fix addresses
those and other issues. The biggest part of the change should help
transition robustness in general, as it removes the dependency on the
public 'alpha' property of views and uses, instead, a new hidden property
on views called 'transitionAlpha'. This is a value which is normally
opaque (1), but which can be used by transitions (only) to animate the
translucency of views without disturbing the actual 'alpha' value which
might be manipulated outside of transitions. This should make transitions
much more robust in general.
In implementing and testing this overall fix, I noticed a couple of things
about transitions that were simply wrong (such as starting fades from the
wrong start value, and incorrectly avoiding transitions on some views
that didn't happen to have ids), and those are fixed in this CL as well.
Issue #10726905 ActionBar weirdness in People app
Issue #10727937 Menu items in gallery appear in faded color after selecting an image/album by long press
Change-Id: If1618446db10c1bfcff4761449241de4f559afc1
The leak fix of the CopyOnWriteArray in ViewTreeObserver was
too aggressive, always clearing the shadow copy when it should only
have cleared it when needed. The way it works now, we will always
clear the listeners for ViewTreeObserver after the listeners
are processed.
Issue #10815924 ViewTreeObserver leak fix too aggressive
Change-Id: Iff0095d73beb38e52b0a5ae6b6378afec4458fd3
Transitions were leaking views due to TransitionsValues holding references
to views/parents. The references were fine, but the retention of the transition
objects themselves were not. There were a few different places that needed to
be plugged:
- clones were not making new copies of some fields, leading to caching references
in the original object (which was then cloned later to other clones)
- Visibility was using a persistent field to cache temporary values. This transition,
when cloned, would retain these instances, keeping references to views
- ViewTreeObserver had a bug that would leak listeners
Issue #10749071 Activity instance leak between TransitionManager and InputMethodManager
Change-Id: I1d5d457dc5e020c7b9e8392a95e3b2c488461119
A recent change to ViewPropertyAnimator.withLayer() builds the layer
immediately after creating it. This works in general, but if the view
is not attached, buildLayer() throws an exception.
The fix is to ensure that the view is attached before calling buildLayer().
Issue #10750925 Dialer crashed and phone dropped while on call
Change-Id: I801c835a0f5cb81e159fe90c157c122cf2d0da01
Alters the content change API to contain a bit mask of types of
changes represented by the event. Live regions send CONTENT_CHANGED
events immediately. Removes unused APIs for EXPANDABLE/EXPANDED.
BUG: 10527284
Change-Id: I21523e85e47df23706976dc0a8bf615f83072c04
1. Removed unneeded code in Resolution that was storing its
label as resource and package name. We do not have predefined
resolutions, therefore we always persist the label.
2. Renamed the print attribute margins to minMargins to reflect
that these are the minimal margins the printer support. Updated
the docs as well.
3. Renamed the create method of all builder to build.
bug:10727487
Change-Id: Ie72ab8aaa5215b8bd2853885011b3b4efa4deb2e
If the IME is repeatedly changing the text in its
onUpdateSelection handler, this will crash it with a
stack overflow exception. It's better than the old behavior,
which would result in a busyloop likely to make the
device completely unresponsive.
Bug: 10301239
Change-Id: I170cfb8ef20fc056d4725931890a987aefcaea8b
Previously, withLayer() would simply set the layer type in the runnable
called in onAnimationStart(). Now we also call buildLayer(), to get it
out of the way prior to the view drawing for the first time after the
animation begins.
Issue #9422420 ViewPropertyAnimator.withLayer() should build layer immediately
Change-Id: I99923a234f7ca1ec0b6f1b0bf28b62a71ab7eb4d
Make it a little easier to diagnose input dispatch timeouts by
providing the detailed reason as the ANR annotation in the log.
Bug: 10689184
Change-Id: Ie18fd9ad066b0673d1f57c030e027ad0085f4650
- Deprecates SurfaceTexture.OutOfResourcesException, it wasn't used
- Make all JNI code throw only Surface.OutOfResourcesException
- Get rid of redundant SurfaceControl.OutOfResourcesException
Bug: 10566539
Change-Id: I58126260771b9ccff6a69c672ce7719b9f98138d
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
