Bug: 29091742
This reverts commit 563df3b328.
This also fixes the problems experienced by b/29128683.
Change-Id: I8e3d485cb818ea9e03ca475cba88934f6f903f11
29091742
A new internal API has been created for use by assistant
to launch an Activity Transition from a non-Activity.
The ActivityOptions are also passed along when using
a spring board Activity so that the shared elements
can be properly synchronized.
This also fixes TransitionManager.endTransition so
that it forces Transitions to end the animations.
Change-Id: Id18d9765bfc0c7b438e17966455aa66d3fa3aeda
Bug 27389255
In Idf21542464a13bac7b4d4a17f6b9303f68d550c3, I had removed
a suppressLayout check from forced visibility. Unfortunately,
when the transition ends, it calls layout if there was a
requestLayout during the transition. This prevents the
suppression at the level of the individual views so that it
can be handled at the decor View level as it was before.
Change-Id: I0f016e6356fd1ceff705b122a6b4ac3f3f09600d
Bug 27577177
When ArcMotion created paths in some quadrants, the control
points were placed in the wrong place, making a non-circular
arc instead of an arc of a circle.
Change-Id: Ie842524c09385038fb1f991b877b01ee5e740f20
Bug 27545221
When the propagation delay had a minimum value of 0, no
propagation delay was happening.
Change-Id: Id28c2cac1c40d5c57f6b49fa11a60218ac1787a0
Bug 27105186
Fade previously hadn't had any values saved over those captured
by Visibility. If a Transition merged two Visibility transitions,
it could avoid calling captureStartValues for the Fade transition.
This change prevents an NPE in that case. The combined transition
won't get the intermediate alpha value, but at least it won't
crash.
Change-Id: I8e5720caafda56b017dfe1cc0b16ebdf246e90c4
Bug 22291911
Forced visibility for transitions was introduced to make
Activity Transitions force going from INVISIBLE to VISIBLE
without triggering focus changes. setTransitionVisibility
was later introduced and now allows us to use visibility
without triggering focus changes.
Change-Id: Idf21542464a13bac7b4d4a17f6b9303f68d550c3
Bug 26963113
When a Fade transition is interrupted and reversed, the
View started the animation from the beginning. This change
captures the previous transitionAlpha and starts the animation
from the previous alpha state.
Change-Id: I801fe9ade6af4cf8446838e231bdc71841668a18
(cherry picked from commit 3cf9fa3db0)
The body of {@code} must not be HTML escaped. This is one of
several changes that fix the source in conjunction with a
doclava fix.
Bug: 25757239
Change-Id: Ib38a0fa2dd2a3d68e467f78a812071e763d7e881
Bug 24993183
The bounds for the drawable weren't being set, so the
drawable was never drawn to the correct size.
Change-Id: I992951f28ee6fac2ce8752d2dc0e23f51d3cf584
Bug 22181705
The Fade Transition sets the transitionAlpha in onTransitionEnd.
I previously changed Visibility to only do it in onAnimationEnd,
so the onTransitionEnd overrides the Visibility's version. This
fixes that change.
Change-Id: I7df478897b6fcfec20999965e297925b65a1448b
Bug 22086521
Views matched by instance, or appearing/disappearing, or
named views were not limited.
Change-Id: I70fd1497c58a3cde771f4eafe11d8ebe0889ab6c
Bug 22063111
When transition.end() is run, it removes itself from
the list of running transitions and perturbs the list.
Change-Id: I4feb7ebe19717a0e2302844d4e4e0d19a55ec57c
Bug 21770464
Layout while a View is transitioning out can cause strange
behavior during the animation. This CL suppresses the
layout during the transition. It also invalidates
the parent when it has been removed rather than
requesting layout on it.
Change-Id: I471243f5beef44d3bbed9ce844e66195dbf4ae10
Bug 21400515
When a Visibility transition temporarily changes a View's
visibility, it should not cause a requestLayout or any other
action, such as focus change. This adds a hidden method to
View to allow it to tweak the visibility without causing
other side-effects.
Change-Id: I5a06149983051319080130e5b5e7cc7edda8dd3e
Bug 19290065
When a transition was interrupted, if a View was not in the start
state, but in the end state, then any animator on that View was
not canceled. This detects that situation and allows canceling
the animator on that View.
Change-Id: Ib1d0579bb6b211782c40c6327be59b0c59682731
Sometimes an animator will be interrupted before it starts
during a transition and the onAnimatorEnd will not be called.
In this case, we must set the final state in the onTransitionEnd.
Bug 20416564
Change-Id: I388895215ba2b1c500de3a5afcae8db1fea288f7
We now correctly throw an IllegalAccessException for non-public accesses,
but we were relying on the old incorrect behavior during inflation. This
CL forces constructors to be accessible so that we emulate the old
behavior and don't crash.
Where we were already doing this, the CL moves the setAccessible() call
immediately after the getConstructor() call, since there's no point in
calling it multiple times.
Bug: 20810495
Change-Id: I63dfcb857e445f688080eea05e86ef22760ed49f
Bug 19273502
When a transition runs several animators and is interrupted,
some animators may not have been started. Those animators
that haven't been started will not reset their contents
the same as if the animator was canceled. Fade modifies
transitionAlpha and if it is interrupted prior to the
animator starting, the transitionAlpha doesn't get reset.
Change-Id: I8a49b4fbb7151aadc43d7b10e6acbae9578e5cc4
