If a view is suppressing layout, it is probably part of a
transition animation. In this case, we don't want to defocus
a focused view which may eventually have a size.
Bug: 78302781
Test: issue in bug is resolved. Transition CTS tests still pass
Change-Id: I983f41bcd68056d2150d4db29c781b63a2c321c2
Bug: 74831546
TransitionSet interpolator was never being used in child
transitions. This transfers the interpolator by setting the
interpolator of the children as they are added or when the
interpolator is set. It also works for other settings:
epicenter, path motion, and propagation.
Test: Ie8ce23fe15e6193fdb2909606e442bd2912a4c5a
Change-Id: Ia9e35639f025d14c6497fa30abf75252ff3b1423
Use the public API version of the same thing that the private API
access was doing. No behavior change.
Test: built
Change-Id: I4a9032cfb1d4e699f72df3b079ef363d308419e8
Bug: 73077523
When the path is perfectly horizontal, ArcMotion
was calculating a Path that had NaN values. This
corrects that problem by special casing horizontal
and vertical paths.
Test: manual with app that discovered the problem
Test: manual with test app
Test: I30d51206194e3c68ea145d3a81e05a461c4e0ca8
Change-Id: Ic1a70b79290847726fc7994d1224fd77024e0610
Bug: 65715616
There are two places where views were being removed improperly
during transitions. The first was when making a copy of a view.
Because of hardware bitmaps, views were being moved to the overlay
so that the image could be copied. This CL moves the view back
into its parent after copying the image.
The second location is where the view was being considered an
overlay. When a view is in the starting scene and the view in
the end scene cannot be used, the starting scene view was being
moved to the overlay. This is only valid when the view is alowed
to be removed. Instead, a bitmap copy of the view is moved to
the overlay.
Test: manual testing
Test: I0456d8a699525b08b044236c558b2d84b48c29a6
Change-Id: Ieb32b146cf65e3ff4ed6d7bb8325e74763dbd2d5
Bug: 67049319
TransitionUtils was returning null when the View wasn't attached,
but Visibility transitions can do that intentionally. This CL
temporarily adds detached views to the view hierarchy as part of
an overlay while creating the hardware bitmap representation.
Test: ran transition CTS tests
Change-Id: Ie335619953653dce0224514f0d5c9c8eb00ee1a9
In transition animations, in order to capture the content of a view
or a drawable in a hw bitmap, a RenderNode needs to be created. The
RenderNode was previously setup with no owning view. As a result,
in cases where RenderNode animations are triggered by the draw calls
in displaylist recording, these animations would fail for lack of a
view to animate on.
This CL ensures that when RenderNodes are created for the purpose of
populating content in a hw bitmap in transitions, there's always a
view associated with each RenderNode.
BUG: 65160121
Test: Force to repro crash by changing press state during hw bitmap
creation, which triggers a ripple animation that led to the
otherwise timing dependent and hard to repro crash.
Change-Id: I2b4ba95cad25a94d50b3904e775606f737e960e3
Bug: 64851247
Drawing to software bitmaps does not support many
features, most especially hardware bitmaps. This
changes the implementation to using hardware bitmaps
for View snapshots.
Also fixed broken TransitionTest discovered while
testing.
Test: I4ede02db67e578ea4a25069b683f1989c611e06c
Change-Id: I185bbfe1f789055c9efdba5297a74e481607afaf
Bug 35227753
ChangeClipBounds wasn't setting the final clip to null after its
transition if the end clip was supposed to be null.
Test: I9089e0c84718d219cfda266a99fd3dffdbae8512
Change-Id: If928454b30807ccc6b34ed4dfbb14857d99d43be
Bug 37156683
The animator was setting the value twice on the first run, so
the bounds was being set improperly as the top/left was being
set from a different frame than the bottom/right.
Test: I534cc4d7534cff1206ea8c2b222e0c0852fc0e9c
Change-Id: I6fb047d2fa4d0ed0db3b44107f9815a65f1f2676
Bug 35832096
When entering or exiting Views were excluded, they were still
being set to INVISIBLE during the exit transition. This made
them disappear instantly. Instead, I've reverted back to the
original implementation by not affecting excluded Views during
the transition.
This CL walks the transition and removes excluded Views from
the enter/exit from being affected.
Test: I5b1b75dd12a3914e35c1d0fb641850981a19f9c3
Change-Id: I2b00ba95575420bae690b1cd8d4894c98401da79
Upwards and downwards paths are
now curved in the same direction,
applying "gravity" to objects as they move around.
Test: CTS I40a5df051711fd719806cd88d87eeed68565d73d
Change-Id: I9e5323655dc7901393f90bb1ea2f393ca64b77ff
Bug 32472451
It is important to remove an OnPreDrawListener from the correct
ViewTreeObserver. When a View is added to the view hierarchy, the
initial ViewTreeObserver is not active. The listener must then be
removed from the current OnPreDrawListener. When a View has been
removed from the hierarchy, it is important to remove the listener
from the orignal ViewTreeObserver.
Test: cts-tradefed run singleCommand cts -d --skip-preconditions
--skip-connectivity-check -m CtsUsageStatsTestCases
Test: cts-tradefed run singleCommand cts -d --skip-preconditions
--skip-connectivity-check -m CtsFragmentTestCases
Change-Id: I735f71d2d9c84e86ef846aab0088a8651300fbe8
Bug: 29091742
This reverts commit 563df3b328.
This also fixes the problems experienced by b/29128683.
Change-Id: I8e3d485cb818ea9e03ca475cba88934f6f903f11
am: abb7488998
* commit 'abb74889982603f6070100033c8fa2b1eef3d8de':
Revert "Internal API for cross-task Activity used by assistant."
Change-Id: Id397afe9221e2562e096befc1b105233618ca7ef
am: 74babe679b
* commit '74babe679b0f8e17ed73280b18bc19153764c55e':
Internal API for cross-task Activity used by assistant.
Change-Id: I985c67a465e88f74e66600709c187c3dfc9734e9
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)
