Fixed
Status Update
No update yet.
Comments
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit b55fe68edc02b253b908a1c7c2e98350ba67afe4
Author: Ian Lake <ilake@google.com>
Date: Wed Aug 12 14:21:57 2020
Ignore Animations/Animator when Transitions run
For a given Fragment, a single owner for its
transition from visible to non-visible is needed
to avoid conflicts as different systems try to
influence the same set of properties.
This has two consequences:
- Animations (which work at the parent container level)
will interfere if there are *any* Transitions run.
- Animators will interfere if there are any Transitions
run on that specific Fragment.
By tracking which Transitions were started and using
that information to selectively ignore conflicting
Animations/Animators, we can avoid visual artifacts.
Test: updated tests pass
BUG: 149569323
Change-Id: I9e5169ffd36853c3dfbd7f217837a74674a9508d
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransitionAnimTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
https://android-review.googlesource.com/1398530
Branch: androidx-master-dev
commit b55fe68edc02b253b908a1c7c2e98350ba67afe4
Author: Ian Lake <ilake@google.com>
Date: Wed Aug 12 14:21:57 2020
Ignore Animations/Animator when Transitions run
For a given Fragment, a single owner for its
transition from visible to non-visible is needed
to avoid conflicts as different systems try to
influence the same set of properties.
This has two consequences:
- Animations (which work at the parent container level)
will interfere if there are *any* Transitions run.
- Animators will interfere if there are any Transitions
run on that specific Fragment.
By tracking which Transitions were started and using
that information to selectively ignore conflicting
Animations/Animators, we can avoid visual artifacts.
Test: updated tests pass
BUG: 149569323
Change-Id: I9e5169ffd36853c3dfbd7f217837a74674a9508d
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentTransitionAnimTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com
There are two parallel systems in Android - the Animation system and the Animator system (which the Transition system is built on top of). With this change and Fragment 1.3.0-alpha08, no Animation will run if there are any Transitions kicked off at the same time and no Animator will run on Fragments that have Transitions directly associated with them (either via an enter/exit transition or as part of a shared element transition).
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit fa55358f7f2870bf05ef5cce12d2b4e2d86732aa
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 11:30:52 2020
Ignore Animations when Animators run
As a continuation of the work in
we now prioritize running Animators over running
Animations. This avoids cases where both are
running simultaneously.
As Animations and Animators are now properly
decoupled, we can use animator.cancel() when
our CancelationSignal is triggered instead of
using clearAnimation().
Test: all tests pass, updated FragmentAnimatorTest passes
BUG: 167579557
Change-Id: I7b3f5c1cc1355e02ff770838cb485d659dfb1619
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimatorTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
https://android-review.googlesource.com/1427449
Branch: androidx-master-dev
commit fa55358f7f2870bf05ef5cce12d2b4e2d86732aa
Author: Ian Lake <ilake@google.com>
Date: Mon Sep 14 11:30:52 2020
Ignore Animations when Animators run
As a continuation of the work in
we now prioritize running Animators over running
Animations. This avoids cases where both are
running simultaneously.
As Animations and Animators are now properly
decoupled, we can use animator.cancel() when
our CancelationSignal is triggered instead of
using clearAnimation().
Test: all tests pass, updated FragmentAnimatorTest passes
BUG: 167579557
Change-Id: I7b3f5c1cc1355e02ff770838cb485d659dfb1619
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimatorTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit e2e9e6ba772ac721ddd5448b456f5a49513f8128
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Mar 08 09:20:24 2021
Ignore strictmode directory in jetifier
Instead of ignoring strictmode classes individually for jetifier, ignore
the entire directory.
RelNote: N/A
Test: ./gradlew bOS
Bug: 153737341
Change-Id: I5d3ba42b5b9369e5e6291e2b21254414b5999ad9
M jetifier/jetifier/migration.config
https://android-review.googlesource.com/1622522
Branch: androidx-main
commit e2e9e6ba772ac721ddd5448b456f5a49513f8128
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Mar 08 09:20:24 2021
Ignore strictmode directory in jetifier
Instead of ignoring strictmode classes individually for jetifier, ignore
the entire directory.
RelNote: N/A
Test: ./gradlew bOS
Bug: 153737341
Change-Id: I5d3ba42b5b9369e5e6291e2b21254414b5999ad9
M jetifier/jetifier/migration.config
Description
Component used: Fragment
StrictModeWe should build the same type of infrastructure for Fragments so that developers can enable runtime checking for bad behaviors and validate that they (or libraries they depend on) aren't using deprecated APIs or known potential problematic behaviors.
Importantly, this should only be as a second line of defense behind deprecation warnings or Lint warnings to catch these issues at build time or to handle cases where third party libraries / dependencies are triggering these behaviors so that bugs can be filed against them.
We should support at least
penaltyLog(),penaltyDeath(), andpenaltyListener().Given that we should maintain behavior compatibility, we should not add any
enableDefaults()ordetectAll()methods and instead have developers opt into exactly thedetect***()methods they want. This should also remove the need forpermit***()methods since they'll all default to off.Ideally, this is something that developers can either:
Set globally via
FragmentStrictMode.setDefaultPolicy(FragmentStrictMode.Policy)Set on a specific
FragmentManager(and its childrenFragmentManagers) viafragmentManager.setStrictModePolicy(FragmentStrictMode.Policy)(this would override the default policy)This API shouldn't be made public until there is at least two
detect***()calls added. These will be filed as separate issues.