| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I8789f8499d4dca08580672e9e45ed9a7026dd686
|
| |
|
|
|
|
|
|
| |
This is used by androidx.transitions only for the API levels less than 18, so it is safe to restrict it after P.
Bug: 123769438
Test: none
Change-Id: Iaff4d5741c7cf952cbff61c3b580ef1ec0618009
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For packages:
android.animation
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: If0667154031b254fd632e1332fb65e9b08955755
|
| |
|
|
|
|
|
| |
and DISAPPEARING animation timelines cannot overlap
Bug: 16808571
Change-Id: I8cbac11da4f866f2d3bcde45996b039e9bdfb801
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, an OnPreDrawListener was added to clean things up, including
removing the listener, after animations are started.
But if the view is detached before that listener is called, the
listener will remain on that ViewTreeObserver.
This change adds an OnAttachStateChangeListener to perform that cleanup
step when the view is detached, just in case.
Issue #20824645 Leak in LayoutTransition
Change-Id: I264812f8e02dda673789712ba83d208e87cdc5a4
|
| |
|
|
|
|
| |
Bug 17005728
Change-Id: I2e109ed1a3e768e1e0286fc3950516f16509e591
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, you could set a new interpolator on a LayoutTransition object,
but it wouldn't have any effect, since the value was only used at construction
time. This change makes the intended behavior work, byt assigning that
new interpolator to the appropriate animations when they are run.
Issue #11163487 LayoutTransition.setInterpolator() has no effect
Change-Id: I1b390a30c008ac2bf26491dc352e28f276357388
|
| |
|
|
|
|
|
|
| |
This is required, otherwise the listener cannot remove it-self from the
list of listeners during the notification.
Bug: 6692355
Change-Id: I07762feb4f9b97ec4b6148d2f604d53e266b84d7
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
LayoutTransition runs changing animations on all objects that change between
now and the next layout. This works in most normal situations, but when a container
is becoming visible, or being added to its container, or other first-time situations,
then some of the views and parent hierarchy may be of size (0,0). The user really
shouldn't need to see an animation up from these nonsense values, so we just
skip running the animation on these objects and simply place the objects where they
need to go.
Issue #6597648 view should not animate up from size (0,0)
Change-Id: I2c355a68bf1ce3b41fbec01ad95c78d83562ba32
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LayoutTransition causes artifacts in some situations where a window is just
becoming visible or a container is just being added to the view tree when animations
are kicked off in LayoutTransition due to the normal automatic mechanism of running
animations when views are added/removed/etc. The problem is that containers in these
situations may have children with positions and sizes of (0, 0), causing the animation to
animate from this default/nonsense value to whatever is appropriate for the views when
they are first laid out and drawn. The end result is correct, but the animation is
superfluous and silly.
The fix is to avoid running any kind of transition animation on windows that are not
currently visible or containers that are not currently atached to the view hierarchy.
This should avoid the situation by only allowing the animations to run after the containers
and windows are visible and set up correctly.
Issue #6544410 issue with layout transition when first showing the activity
Change-Id: I737b2598887ef806dec3b02a483a8e8ff2c3d4e2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The callbacks for animators in some corner cases were not being
called correctly. For example, startDelayed animators that were
started and then ended didn't send out the proper events.
This CL fixes that logic. Specifically:
- An animator that is end()'d will implicitly start() itself and then
assign an end value. This was already the case, but listeners were not
getting notified. Now this situation causes callbacks to listeners for
both the start and end events.
- startDelayed animators that are end()'d or cancel()'d prior to finishing
the startDelay phase will send out events (start and cancel/end, as appropriate)
to listeners.
Change-Id: I40a0f2fdb19d9ec7c3726a91363686c6ecb7d915
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LayoutTransition used to depend on child views being added/removed or
shown/hidden in the transition container. These evens would trigger animations
to fade the child view as well as those to animate the side-affected changes
to sibling views. This CL enables a new feature in LayoutTransition that
enables animating any changes to the layout of the children in the container
whenever a layout occurs. For example, you can change the LayoutParams of a
child view and call requestLayout() to automatically animate those changes.
This capability is not enabled by default. To enable, call the new
LayoutTransition.enableTransitionType(LayoutTransition.CHANGING) method.
Change-Id: I4d07a3b36245353b2151f0dca4f75080ab6a4592
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LayoutTransition side-effects the alpha property on View to fade views
in and out. This works fine if the layout transition is always used on
those views' container. But if you fade out a disappearing view and then
set the transition to null on the container and set that view to VISIBLE,
there is no transition logic to restore the alpha value to 1 (opaque).
The fix is to always restore alpha to its pre-animation value when fading
the view out.
Also, added extra info to alpha and the various View transform properties
to help hierarchyviewer debugging.
Issue #5958434: LayoutTransition temporary disablement may leave some views invisible
Change-Id: I3c21b0e7334dc29c10c5e372b589f0e2b59c2883
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a view is becoming VISIBLE or INVISIBLE in a container with a
LayoutTransition, animations run to fade the view in and out and also
to run 'changing' animations on the view's other siblings. This logic
also cancels any running 'changin' animations to account for new ones
running.
However, in the specific case of INVISIBLE changes, there will be no
layout changes in the container - layout has already accounted for that
view (unlike in the case of GONE views); the visibility is just a matter of
drawing the view (or not). Therefore, we're canceling 'changing' animations
that should continue running and not replacing them with any other animations,
since new animations would only be started on layout chnages which are not
forthcoming.
One artifact seen from this bug is that the navigation bar buttons sometimes
disappear when changing orientation. This is because the menu button may
toggle between VISIBLE and INVISIBLE, causing animations on the other
buttons to get canceled, which leaves those views in a completely wrong
state.
The right thing to do is to avoid canceling in-process 'changing' animations
and to skip the logic of setting up new 'changing' animations which won't fire
anyway.
There is some minor API work in here because we did not previously have the
necessary information in LayoutTransition to know whether a view was being
hidden or shown to/from the INVISIBLE state.
Issue #5911213: LayoutTransitions ending in an odd state
Change-Id: I5c60c8583c8ea08965727b4ef17b550c40a3882c
|
| |
|
|
|
|
|
|
| |
transitionType)
Bug Id : 5813366
Change-Id: Icc482ad820a91a1896c61db67bb6b95cc2ae4c5b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LayoutTransition was making an incorrect assumption that there could
only be one transition animation on a child of a transitioning container.
But if multiple children are added/removed to/from that container, there would
be multiple calls to set up changing animations for each existing child
of that container. This meant that the child would have multiple, new
OnLayoutChangeListeners added to it as part of the setup process.
Meanwhile, we would cache only the latest listener in a hashmap that used
the child as a key for the listener. Then when we cleaned up the hashmap later,
we would remove only the latest listener from the child, leaving the rest there
for eternity.
The fix is to skip the setup entirely for children that already have listeners
set on them; they must, if that's the case, already have been set up and are
already listening for layout changes. Setting up the animation is redundant,
and adding another listener is a leak.
issue #5588509: memory leak in systemui
Change-Id: I2c9f312cc2bcf4f2d08ac6b5d8f8e495aa4f3597
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When a transition occurs, layout change listeners are added to the container
being transitioned as well as every container up the view hierarchy. The
parent views were not having those listeners removed, so every time a transition
ran, more listeners would be added. Adding to that, the use of an ArrayList
as the collection to hold the listeners meant that adding duplicate items
would just increase the size of the list. There's now a sanity-check on the add
call to make sure that the listener does not exist already, but more importantly
we remove all listeners added when the transition ends.
Change-Id: I4ea05adf30765db091124065539b0ffd32729b3b
|
| |
|
|
|
|
|
| |
This new hidden API is called by ViewRootImpl when there is a pending
transition but the parent window is not visible.
Change-Id: Idd6a0959b391fae542e675e8740b6a16f8963678
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, setting custom animations on a LayoutTransition would cause
those animations to be run not only for changing views in the container, but
for the parent hierarchy of those views as well. This can lead to unexpected
behavior, as seen in the ApiDemos LayoutAnimations and LayoutAnimationsHideShow.
This change changes the behavior so that the parent hierarchy is animated by
the default animations (which change the bounds and scrollX/Y fields) instead
of custom animations.
Change-Id: I9a04d97fabbc34dc0d5809eb3fd8ac08e0801d7c
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This bug caused an artifact in Recent Apps where you might see things
pop to their end location before popping back and then animating correctly
into place.
Change-Id: Ia7313ec76cc42162528c3c167b8bc562284b14bc
|
| |/
|
|
|
|
|
|
|
|
|
| |
Static objects were referencing the first LayoutTransition object,
which referenced its target container, which eventually referenced the
Activity. That reference chain never went away.
The fix is to create animators that do not reference any target
object (they are just templates which are loaded with real target
objects when they are started).
Change-Id: Ie29f53bf3b886b8052b6ee3a56647a312d9adeaa
|
| |
|
|
|
|
|
|
|
| |
This change compensates for changes in the parent hierarchy of
transitioning views. It automatically animates parents with the same
animations as those used for the CHANGING animations run on the container
children.
Change-Id: I86471d16a9070b024cc09c8f6e0f504a881fa99f
|
| |
|
|
| |
Change-Id: Ic24bb0e1e669989f0cae3a9b8fa064b38c8e7948
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A recent change to LayoutTransition caused new layout transitions to
cancel any previously-running animations. This was to handle situations
where a transition adding an item needed transitions removing items to
finish their job first (and vice versa). But canceling *all* running
animations from transitions caused some artifacts, like making the status
bar icons blink or fade in, depending on which one was started last.
The new approach is to cancel just the ones we care about: adding animations
cancel removing animations, and vice versa. Either one cancels 'changing'
animations, which prevents objects from being animated to the old end
locations, since the new transition will animate them to the correct new
end locations.
Change-Id: I68ac351b05365cace6639b6618422395c35c83fd
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There were some subtle timing issues in animators with ending animations that
were not completely initialized (possibly because a startDelay'd animator
was ended before the delay elapsed).
Also, LayoutTransition had bugs around running a transition on a container
while a previously-started transition was still in progress. This could result
in some minor artifacts or crash bugs, depending on the durations and delays set
on the transition animations.
Change-Id: Ic6a69601f1ce9a55db15fff6b8ed25950b354491
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that there can be >1 animation spawned for each
view in a container, if there are multiple events that trigger
a transition. These animations would potentially clobber object
layout values, causing problems as successive animations tried to use those
clobbered values to set up their own animation values.
The fix is to track the created animations and cancel them as future
animations on those same objects get created. This mechanism used to
be in the code (the bug came about when that mechanism went away), but
was removed because of memory leaks of never removing animations that
were set up but never started. The new approach also caches pending
animations, but runs a second aniamtor to delete the entries in that
collection just in case.
Change-Id: If60c7d188712334dea69d0794dc6b4ce29ca6c09
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, display lists were used only if hardware acceleration
was enabled for an application (hardwareAccelerated=true) *and* if
setDrawingCacheEnabled(true) was called. This change makes the framework
use display lists for all views in an application if hardware acceleration
is enabled.
In addition, display list renderering has been optimized so that
any view's recreation of its own display list (which is necessary whenever
the visuals of that view change) will not cause any other display list
in its parent hierarchy to change. Instead, when there are any visual
changes in the hierarchy, only those views which need to have new
display list content will recreate their display lists.
This optimization works by caching display list references in each
parent display list (so the container of some child will refer to its
child's display list by a reference to the child's display list). Then when
a view needs to recreate its display list, it will do so inside the same
display list object. This will cause the content to get refreshed, but not
the reference to that content. Then when the view hierarchy is redrawn,
it will automatically pick up the new content from the old reference.
This optimization will not necessarily improve performance when applications
need to update the entire view hierarchy or redraw the entire screen, but it does
show significant improvements when redrawing only a portion of the screen,
especially when the regions that are not refreshed are complex and time-
consuming to redraw.
Change-Id: I68d21cac6a224a05703070ec85253220cb001eb4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LayoutTransition works by animating layout-related properties
(left, right, top, and bottom). This works great when that animation
is the only thing affecting the layout of the UI. But if there are other things
happening in the application that cause layout to run on that
container or in its parent hierarchy, this can cause the layout properties
on its children to get mis-set during the middle of the transition.
This results in artifacts like animating objects jumping to locations where
they would be were there no animation running.
The fix is to supress layout requests on that container (and its children)
until the transition is complete (then issue a layout request on the container
to make sure that the container has the correct layout data)
Change-Id: I15bf0423a11409f854076f86099233db7fe4edc0
|
| |
|
|
|
|
|
|
|
| |
There was already a mechanism for sending out events for LayoutTransition
when animations started or ended, but the implementation only sent out events
for the appearing/disappearing animations. This fix provides callbacks to
listeners for the CHANGE_APPEARING and CHANGE_DISAPPEARING transitions, too.
Change-Id: Icfb8cc1c20d2df3e4a817255e96c9d0e94c1d8c4
|
| |
|
|
|
|
|
|
| |
Objects are invalidated and reset instead of being nulled out
and recreated. This avoids creating small amounts of garbage for
the display list and canvas objects.
Change-Id: I464fac7ea8944c19ad6d03f13a95d9017e3f4262
|
| |
|
|
| |
Change-Id: I0384a437089d11dda03d0657235404ea96e8b19d
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There was a bug with LayoutTransitions where if the animations
were of different duration (such as in the current status bar clock),
it was possible to end up in a bad situation because the previous animation
might outlast the new animation, causing the opposite end result
from what was expected. The fix was to keep track of the current
add/remove animations and to cancel any running ones prior to starting
new ones.
Change-Id: I884ce33ce0671f6ba6153ee3951c8d14c5ed5714
|
| |
|
|
|
|
|
|
|
| |
Change the manner of constructing Animator-related objects from constructors
via generics to factory methods with type-specific method names. Should
improve the proliferation of warnings due to generics issues and make the
code more readable (less irrelevant angle brackets Floating around).
Change-Id: Ib59a7dd72a95d438022e409ddeac48853082b943
|
| |
|
|
| |
This reverts commit 41f041d9986f8a5d45b6cb0b86e881c81a412168.
|
| |
|
|
|
|
|
|
|
| |
Change the manner of constructing Animator-related objects from constructors
via generics to factory methods with type-specific method names. Should
improve the proliferation of warnings due to generics issues and make the
code more readable (less irrelevant angle brackets Floating around).
Change-Id: I7c1776b15f3c9f245c09fb7de6dc005fdba58fe2
|
| |
|
|
|
|
|
|
|
|
|
| |
The new animation package's reliance on the old Interpolator interface (in
android.view.animation) was an eyesore. Adding TimeInterpolator, and having the
old Interpolator interface extend it, allows the new Animator classes to break
the tie to the older animation package completely. However, developers can still
use the older Interpolator-based classes, such as AccelerateInterpolator,
because they all implicitly extend the new TimeInterpolator class.
Change-Id: I41132fa56167ba564f4839113289114d0ea31a92
|
| |
|
|
| |
Change-Id: Ic4d67135a273ea816c3d15bce05da611bd6bae53
|
| |
|
|
| |
Change-Id: Id6ff92c8fd06c3f5fb30c41b020b4de4f567154f
|
| |
|
|
| |
Change-Id: Ia7061d8ec138f8f7aea822596f46b3549a996700
|
| |
|
|
| |
Change-Id: I6a4544875090db485163c8d56de8718f56d267c7
|
|
|
Change-Id: Ibefcca5692450188fbcec608f3f7e36be1213b21
|
