Bug 14990153
Stops two potential animators working against the background
drawable. Forces the entering views to become visible onResume.
Change-Id: I2da66b54a16c6c69533eebbeff6db7f5a7794a89
Bug 14597573
In a Transition, when a View is removed from a Scene
and that View has an ID in common with another View
in the end Scene, it will be matched, even if the
View in the start Scene already had a matching View
by instance. This CL prevents a match by ID when an
instance match is available.
Future: disable matching when two views have the
same ID.
Change-Id: I0e51d1f2d0a2d05d09e8e135f090d0e1b2a67efc
Bug 14497858
Probably more than 50% of shared elements will be ImageViews and
sharing the scale type and matrix between the two Activities will
simplify shared element transitions.
Also fixed MoveImage, which had a bug when the scale type was FIX_XY.
Change-Id: Ic5548b4d1420ced12507c18edf76c9e50e27a929
Bug 14443184
Also gave the propagation speed a tweak to make it more
obvious that there is a propagation.
Change-Id: If9dc3172ae6ce7e6a712ccd1b83ebec9bf880bfa
Bug 14289299
Added ability to target a specific class similarly to the
mechanism for excluding a specific class in Transitions.
Also changed XML tag from excludeTargetId to excludeId to
make it symmetric with excludeClass.
Change-Id: Ib371820ec75761243e75b659565b905b1b19c9a2
Made MoveImage use an overlay view. Drawables
cover all Views in the overlay and there may
be a desire to order the overlays.
Change-Id: Ic7b81f0d26d8cce3f475c2eebbce01538bc55d46
Slide: transition in and out of the edge of the scene.
Explode: transition to the scene borders
Moved capability from Fade to Visibility.
Change-Id: Ibeb0d8f751c990edc467570d9665fbe251af2703
Bug 13347005
Because Windows can share a UI thread, pausing/resuming
Animators in transitions can affect other Windows. This
isolates the pause/resume to the Window being operated
on.
Change-Id: Iac84a0a2c838f30c309eea4931467ba758c6ba78
This reverts commit 206e30cd93
along with removing the additional startActivity* methods
and replaces them with ActivityOptions makeSceneTransitionAnimation
methods.
Change-Id: I52bec31ae3c4cea6d549810ae5a7acd8aea176d8
Shared element transitions are enabled by default
when the Window has a TransitionManager.
Shared element location and size are captured and
transferred to the target Activity.
ActionBar is treated as a shared element.
Change-Id: I0f22ea4e5cbe80254e848444e3f235cb742684f4
First pass at API for cross-Activity Scene transitions.
Remaining work:
Transition back
Automatically capture hero element info
Transfer of surface texture to synchronize between Activities
Possibly use scene names to indicate preferred transition
Change-Id: I59d07de1fae694a46b92b1c82525daa301ec1377
* Add theme attributes for specifying a top-level TransitionManager
for an activity window.
* Add window feature for automatic content transitions. This
automatically assigns/creates a Scene for setContentView calls.
* Add named transitions. This allows apps to define APIs for
handshake-agreements about which exit/entrance transitions to play.
* Add new transition type for ActivityOptions. This lets the system
use ActivityOptions to communicate transition specifics and
arguments to the called activity.
* Have ActivityManager pass appropriate ActivityOptions through to the
called Activity. Have the called activity call back into the caller
to let it know which transition of a possible requested set was
chosen.
Still to do:
* Define and pass arguments for transitions. This will require
defining a Parcelable version of TransitionValues and deciding how
much leeway apps should have for these things.
* Determine how to appropriately filter the ActivityOptions bundle so
that only appropriate data reaches the target.
* Determine if generalizing the auto-Scenes functionality to
ViewGroups is appropriate.
Change-Id: I10684b926129ab2fbc1adec9ef31767237acae79
Add a window feature for content transitions. This implicitly creates
a Scene for each setContentView operation and runs the appropriate
transition. Applications can specify a TransitionManager XML in their
theme that will apply the appropriate transitions when these implicit
scene changes occur. Apps can specify a "to" with no "from" in a
transition to request an entrance transition for the given
content. This lays the groundwork for further full content
change/activity to activity transitions.
Change-Id: Ic815d9e0b9ce958152d70bf6ee01be075aa9fe88
A static map in TransitionInflater keyed off of Context instances,
which could cause contexts/activities to leak over time. This
fix removes that map and simply creates a new inflater each time.
The savings of the cached inflater was minimal an unnecessary, and the
intended sharing is in the context embedded in the inflater anyway.
Issue #11436919 leak in TransitionInflator
Change-Id: Ic05ca47f57723bd572bb6143df4035d66eedf5ad
The current tracking of scene objects in a static ThreadLocal is
problematic as it leaks the Context associated with the SceneRoot and
returns the wrong Scene object if the same layout ID is used across
different scene roots.
Track Scene objects on the scene root view instead to avoid these
issues.
Change-Id: I891986897f757f2666897c937b5ebb0ed1d531c1
Transitions, when started, add an OnPreDrawListener to the current
ViewTreeObserver (which is global to the view hierarchy). This listener
is removed when the listener is called.
It is possible to add this listener and then remove the view from
the hierarchy before the listener is called. This could result in
either the listener not getting called at all (since there was no
drawing event) or (in the case of this bug) the listener getting called
when the sceneRoot had no AttachInfo (which is the case when that
root has been removed from the hierarchy). This results in the listener
trying to remove itself from a *different* ViewTreeObserver than the one
it added itself to, leaving the actual listener still sitting on a list
of listeners in that original VTO. This can result in a growing list of
listeners and a growing amount of work that gets done on every frame.
It can also lead to a serious memory leak, since the objects referred to
by the transition may be non-trivial (as in the case of this bug).
The fix is to add another mechanism for the listener to get removed.
Specifically, we now listen for detach events on the sceneRoot. If that
view gets detached before the listener is called, then we have a chance to
remove it from the correct VTO before the AttachInfo becomes null.
Issue #11307391 keyguard is slow after updating to krt16c and playing music
Change-Id: I108413ea2f18f5351df0a11d4ae56fec0b4aa154
The inflation code in TransitionInflater was using the wrong
tag ("set") for TransitionSet. This fix corrects that problem
(changing it to "transitionSet") and documents the correct
tag in the TransitionSet javadocs.
Issue #11085279 Transitions: transition sets loaded from resources don't work
Change-Id: I8aaea9f31bbe368cffcca63d4eb6a5ec06c3ce7b
Media controller now fades between different states. The code for
doing this was already there, but this CL enables them and changes
the behavior of transition's OnPreDrawListener to do the right thing.
Also, this CL fixes a bug in ChangeText found while testing this change.
Issue #11083563 ChangeText transition crashes when KEEP transition type used
Change-Id: I5e04c28e1b5faac017b0a4e49734d9faa7fe79cd
Previously, a Fade transition would only affect a view if its
parent hierarchy was not also affected between the start/end states.
This caused problems for views which were removed from their parents
between scenes when their parents' visibility also changed between those
scenes. The effect would be that the transition would fade the parent...
but the child would no longer be in that parent, so the user would just see the
child view blink out.
This fix ensure that views are faded appropriately by fading them
regardless the parent hierarchy; if a view is removed from its
parent, fade it out.
Additionally, if that view has not been removed from its parent, but
its parent is no longer parented *and* scene being
transitioned from is based on a layout resource file (and thus
the views are considered temporary after transitioning), then it is
removed from its parent to be faded out in the overlay.
Also, renamed TextChange to ChangeText to be more consistent with
other transition class names.
Change-Id: I4e0e7dfc9e9d95c7a4ca586534b6d204c4f3bae0
Various artifacts across apps were coming from ActionBar's use of
the new transitions framework. Disabling transitions for now to get
things back to a more stable state.
Also, fixed some related bugs in transitions themselves, including
a change in TextChange to account for text selection, which was causing
errors in Keep's SearchView.
Issue #10860557 TextChange animator may old stale value
Issue #10819685 sometimes icons are lighter
Issue #10750525 Share and Settings icons overlap when stopping slideshow
Issue #10839551 Sometimes the search text box is right-aligned in Keep
Issue #10727484 Cursor incorrectly positioned after entering first letter during search action in keep app
Change-Id: Iad7cbf3297e18018308b8148b3519b032e63dace
ActionBar uses a transition to animate text changes. This transition
depends on testing the equality of start/end text values in CharSequence
objects. Without equals(), SpannableString will return false for objects
whose references are different, but whose text is exactly the same.
This CL adds the equals() method, and the accompanying hashcode method,
to ensure that two Spanned implementations will always be equal
if their text and span data are equal.
Issue #10760075 Wrong unread count in actionbar
Change-Id: I5e77d40dd302eca035e8c56d40f3cd0aef8e6424
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 Fade transition sets an initial alpha value of 0 when items are
appearing. This makes items invisible to start with, and then they
eventually fade in as part of the transition when the transition's
animation runs.
But if that animation/transition gets interrupted, or not started, then
the alpha value would not be restored, and the value would stay 0,
making the items invisible indefinitely. This is what was happening in
the action bar of the People app when performing a search.
The fix is to handle Transition and animation events to restore the alpha
to its true value when the transition completes, whether that
transition is canceled or not.
Issue #10726905 ActionBar weirdness in People app
Change-Id: Idb65fd8d471d2ac0a1ddc243fee00ae99f7e72d8
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 problem with transitions is causing various ActionBar icons to go
missing occasionally. This CL disables these transitions for now
to allow ActionBar to work as expected.
Issue #10726905 ActionBar weirdness in People app
Change-Id: I0cb774840ae84cbb733d65865f8c1b4c6d7490fa
Some of the code in the TextChange transition assumed that the
start values for a transition were for a TextView object. This may
not be the case, and we should return early (without creating an
animator) when it is not.
Issue #10725388 Frequent Framework crashes across apps
Change-Id: I6999eb2288f107f4b93ddb5b77cd068069d831ed
It would be useful for a transition to declare not just which
targets it wants to be run on, but also which targets it wants
to avoid. For example, you may not want to animate the items of
a ListView, or some other specific target in the view hierarchy.
This change adds various exclude*() methods which make it
possible to alter a transition to automatically ignore specific
views, ids, or classes in the hierarchy.
Issue #10692794 Transitions: Need API for excluding targets
Change-Id: If38025cdbee537a545e5a4268cbbd763af4622c5
The ChangeBounds transition causes its target view parents to suppress
layout for the duration of the transition. This is done to avoid artifacts
caused by running layout while layout bounds are being animated between
different scene values.
In order to react correctly to new transition/scene information (such as
running a new transition while another is already running), the transition
system calls pause() on all running transitions to allow layout (among other
things) to work correctly, then resume() after this is finished. This works
in general, but pause/resume do not take account of child transitions that
have already played and ended. ChangeBounds, uses pause/resume to
restore normal layout and re-enable layout suppression. This means that
when resume() is called on a ChangeBounds transition that has already
ended, that transition will leave the parent in a suppressed-layout
state, basically forever. This can cause artifacts like we're seeing in
recent ActionBar changes where the account spinner is never repopulated because
layout is never allowed to run.
The fix is to note when a transition ends and noop future calls to pause/resume.
Issue #10648936 Transitions don't work with new ActionBar functionality
Change-Id: Id9d41c0352b2270d46cfd5ad4dba130767bbf303
