| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
DO NOT MERGE Revert submission 20674641-revert-20610032-cherrypick-AnimatorLeak fixes-4lh72bu61o-BQALTBEXMY
Reason for revert: Temporary revert deemed unnecessary - this revert will re-submit the original changes.
Reverted changes: /q/submissionid:20674641-revert-20610032-cherrypick-AnimatorLeak+fixes-4lh72bu61o-BQALTBEXMY
Bug: 261518932
Bug: 258616235
Change-Id: I539c771a6897a9d635613a17138343a7a9feddb9
Test: Presubmit tests. Also, forrest runs with these changes showed no regression
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert "Fix test cleanup issue in AnimatorLeakTest"
Revert submission 20610032-cherrypick-AnimatorLeak fixes-4lh72bu61o
Reason for revert: Startup regression found in post-submit
Reverted Changes:
Icdd6023f6:Fix activity leak bug
Ieac851550:Fix test cleanup issue in AnimatorLeakTest
This is a tentative revert to see whether it addresses the regression while I continue chasing the underlying problem
Bug: 261518932
Test: presubmit
Change-Id: Ica9a75b94c8c260cceb6719f8f6b95ba67d4e356
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a cherry-pick from main branch:
ID: I7dfebac90aa43f89433f49e0ed60b3ff57bcc497
It is possible for ViewRootImpl.doDie() to be called prior to one of the
other calls which tells the system that the window is going to the
foreground. This race condition can cause an activity leak since the
ViewRootImpl in question is stored in a collection of "requestors" which
determine when to pause/resume animators for background/foreground apps.
The fix is two-fold:
- Only cause an item to be added to the "requestor" list in
AnimationHandler when doDie() has not yet been called (marked by
the mReoved" flag)
- Store the requestor objects as WeakReferences, rather than the objects
themselves. Thus if the requestor list is the only referent to the
object, it can be collected anyway, removing the leak potential.
Bug: 258616235, 258616235
Test: AnimatorLeakTest passes
Change-Id: Icdd6023f6530e3cc4b474f33dc34f6eb7400788e
Merged-in: I7dfebac90aa43f89433f49e0ed60b3ff57bcc497
|
| |
|
|
|
|
|
|
| |
this is a hot fix for the regression caused by ag/20171590, may need more investigation to properly handle it.
Bug: 255723033
Test: Failing Tests
Change-Id: I129f69d2979405b33c8b46430c7b1ec8559105aa
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows core libraries (such as predictive back progress animation)
to use spring animation.
Files in androidx/dynamicanimation/animation that are not copied over:
FlingAnimation.java - Unused atm
AnimationHandler.java - Replaced with the framework AnimationHandler
FloatPropertyCompat.java - Replaced with FloatProperty
FrameCallbackScheduler.java - Unused in framework AnimationHandler
Test: m -j
Bug: 238475284
Change-Id: Ifdf847da0aa2a6cf57e18f9ac7c91bb0fe3b12c2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change sets the default behavior of animator pausing by checking if
a system property is set and useing that value if present else it
defaults to true. This should allow the use of build properties to be
able to toggle the behavior.
Bug: 233391022
Test: Manual, adding logging to verify the values being set by the call
to the sysprop library.
Ignore-AOSP-First: Testing internal change, will cherry pick to AOSP.
Change-Id: Ib1b34585c564bf4f310441c6856412a798022900
|
| |
|
|
|
|
|
|
|
|
| |
LOCAL_LOGV should be set to false
Bug: 232914479
Bug: 233391022
Test: Manually tested to ensure logging is not happening
Change-Id: Ie14cf3c0bacb50dd1e7422dc378d5195e4d9bec5
Merged-In: Ie14cf3c0bacb50dd1e7422dc378d5195e4d9bec5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds a static method which can be called to disable the
default behavior of pausing infinite animators when an app's windows
are all in the background. This could potentially be used for
global behavior of a system property to disable this behavior system
wide.
Bug: 232937493
Bug: 233391022
Test: Added new cts test to AnimatorLeakTest to verify behavior
Change-Id: Idf4957e3968253228096671fde89f820311883e3
Merged-In: Idf4957e3968253228096671fde89f820311883e3
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because animators are not tied to the lifecycle of any UI
elements, it is possible for an app to go into the background
and for the animators to continue running. Ideally, the app would
track the lifecycle of the activity/etc and pause or disable the
animators, but it is common for this to not happen, causing the
animators to continue spinning when the app does not need them.
The animators are not causing as much work as for a foreground
activity (since they do not cause any re-rendering), but they cause
work nonetheless by keeping Choreographer awake to continue pulsing
frames.
The ideal fix would be to introduce new API for animators that
tied them to lifecycle concepts (View, Activity, etc). But that kind
of fix would only be available for future versions of the platform,
and does not address existing app code. A workaround for the current
situation is to address the most egregious problems; infinite animators
running on backgrounded apps.
The fix here is exactly that: when an app's visible surface (either an
activity or, for Wallpapers, a WallpaperService) is backgrounded,
a request is sent to pause animators for that surface. When that surface
comes to the foreground, a request is sent to resume those animators.
Since all animators are handled on the same thread for the same process,
in AnimationHandler, we should only ever pause animators when *all*
surfaces for a process are not visible (and resume them when *any*
surface becomes visible). Also, to mitigate any issues with thrashing
animator state for apps which become only transiently backgrounded,
we delay pausing for some time.
Bug: 228598053
Bug: 233391022
Test: new AnimatorLeak CTS test, plus manual testing for activities
and wallpapers
Change-Id: I8b9f841cc80babb972244c724968a5c085a06b69
Merged-In: I8b9f841cc80babb972244c724968a5c085a06b69
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
AnimationHandler.doAnimationFrame() iterates on a list that may be changed
during the course of the lopp, especially when Battery Saver is enabled, or
animators have zero duration, coupled with user code launching new animators
when old ones end.
The fix is to iterate through the old size of the list, and avoid processing
new animators in the current frame.
Bug: 37376806 Keyboard doesn't come up when battery saver is turned on on Android O
Test: manual
Change-Id: I40ca1d849e6f337779c23edbab22d80760c22f9b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL adds reverse and seek to AnimatorSet's capabilities.
Structural changes:
1) Child animators are now being pulsed by AnimatorSet in a more
timeline manner, as opposed to the old listener based style.
This timeline based approach avoids the time offset in between
sequential animations, and therefore produces a more accurate
overall duration.
2) Timeline is done by representing start and end of each child animator
in two separate events. All the events are then sorted based on the
time they happen, such that it's clear what should happen in between
last frame and the new frame (i.e. which animations should start
or end).
Test: CTS (in the same topic branch)
Bug: 30993532
Change-Id: If1dc6e8dbc93a4bf5ade8c5b0dcf43d3ee6ba7b5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug 18122022
Previously, each animator would wait a frame after it was
started the animation was actually started. This is fine
for the first frame of an animation, but when it is within
an AnimatorSet, each animator will add a frame of delay.
This skews the animations so that they can no longer be
synchronized.
This CL refrains from waiting for an animation frame when it
is started during the animator callback and just start
the animation immediately on that frame.
Change-Id: I007dad9aef7596f0e954377a36a17afd4801b7fe
|
| |
|
|
| |
Change-Id: Ib454858f0fe3eb9171297c2c1ccece33729c487b
|
|
|
This CL includes the following changes:
1) Remove redundant field mPlayingState in ValueAnimator.
2) Refactor AnimationHandler so that all of its interaction with Choreographer
is through an interface. A custom provider that implements this interface can
be plugged in and provide timing pulse that are independent of Choreographer.
3) Better encapsulate AnimationHandler and ValueAnimator. Interaction between
the two is done through register/unregister frame callbacks as well as
AnimationFrameCallback interface.
4) Change how animation delay is handled.
Change-Id: Icd49f727321c362dab49b5b33815333c9ea559e0
|
