Fixed
Status Update
Comments
il...@google.com <il...@google.com>
to...@yahoo.com <to...@yahoo.com> #2
Project: platform/frameworks/support
Branch: androidx-main
commit 57ca221882695bd6a52549f4d9ea3b812e6fe87c
Author: Simon Schiller <simonschiller@users.noreply.github.com>
Date: Mon Mar 22 16:09:30 2021
[GH] [FragmentStrictMode] Detect <fragment> tag usage
## Proposed Changes
- Detect `<fragment>` tag usage inside XML layouts
## Testing
Test: See `FragmentStrictModeTest#detectFragmentTagUsage`
## Issues Fixed
Fixes: 153738235
This is an imported pull request fromhttps://github.com/androidx/androidx/pull/141 .
Resolves #141
Github-Pr-Head-Sha: 4ea052596e4341b9f11bcf335e2bc38045a91f19
GitOrigin-RevId: 62e7487aa4874eef6bb556490e193717cf937251
Change-Id: Iae48578e85e4e4897f806d7ade2e2a660adf9479
M fragment/fragment/api/public_plus_experimental_current.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/strictmode/FragmentStrictModeTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLayoutInflaterFactory.java
M fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentStrictMode.java
A fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentTagUsageViolation.java
https://android-review.googlesource.com/1649748
Branch: androidx-main
commit 57ca221882695bd6a52549f4d9ea3b812e6fe87c
Author: Simon Schiller <simonschiller@users.noreply.github.com>
Date: Mon Mar 22 16:09:30 2021
[GH] [FragmentStrictMode] Detect <fragment> tag usage
## Proposed Changes
- Detect `<fragment>` tag usage inside XML layouts
## Testing
Test: See `FragmentStrictModeTest#detectFragmentTagUsage`
## Issues Fixed
Fixes: 153738235
This is an imported pull request from
Resolves #141
Github-Pr-Head-Sha: 4ea052596e4341b9f11bcf335e2bc38045a91f19
GitOrigin-RevId: 62e7487aa4874eef6bb556490e193717cf937251
Change-Id: Iae48578e85e4e4897f806d7ade2e2a660adf9479
M fragment/fragment/api/public_plus_experimental_current.txt
M fragment/fragment/api/restricted_current.txt
M fragment/fragment/src/androidTest/java/androidx/fragment/app/strictmode/FragmentStrictModeTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentLayoutInflaterFactory.java
M fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentStrictMode.java
A fragment/fragment/src/main/java/androidx/fragment/app/strictmode/FragmentTagUsageViolation.java
ap...@google.com <ap...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 93f6434aed220f37acf3969ccb1299df18088424
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Nov 18 12:05:40 2020
Cancel animators by using animator.end()
When handling animators, DefaultSpecialEffectsController currently uses
animator.cancel() to cancel Animators. The animator.cancel calls leaves
the target view in whatever state it is in during the cancel call and
for entering fragments this means they are left with an alpha of 0,
which means they do not show up.
The original reason for using animator.cancel() was that in the case
where a running animator was interrupted, it could begin the new
animator from whatever state the view was in at the moment it was
canceled, but in practice it start state of the new animator takes over
and it looks as if the animator too the view to the end state anyway.
Switching to use animator.end() when canceling fixes the above problem
by changing the state of the view to the final state which means the
alpha is properly set to 1.0 for entering fragments and this
behavior also aligns Animators with Animations.
RelNote: "Fixed an issue with the new state manager where the view would not reach its final state if you interrupt a fragment transition that was using an `Animator` or one of the `TRANSIT_FRAGMENT_` options."
Test: FragmentAnimatorTest
Bug: 169874632
Change-Id: I92426d8572f9ca71c053945ecc2afd839efbc058
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/1503500
Branch: androidx-master-dev
commit 93f6434aed220f37acf3969ccb1299df18088424
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Nov 18 12:05:40 2020
Cancel animators by using animator.end()
When handling animators, DefaultSpecialEffectsController currently uses
animator.cancel() to cancel Animators. The animator.cancel calls leaves
the target view in whatever state it is in during the cancel call and
for entering fragments this means they are left with an alpha of 0,
which means they do not show up.
The original reason for using animator.cancel() was that in the case
where a running animator was interrupted, it could begin the new
animator from whatever state the view was in at the moment it was
canceled, but in practice it start state of the new animator takes over
and it looks as if the animator too the view to the end state anyway.
Switching to use animator.end() when canceling fixes the above problem
by changing the state of the view to the final state which means the
alpha is properly set to 1.0 for entering fragments and this
behavior also aligns Animators with Animations.
RelNote: "Fixed an issue with the new state manager where the view would not reach its final state if you interrupt a fragment transition that was using an `Animator` or one of the `TRANSIT_FRAGMENT_` options."
Test: FragmentAnimatorTest
Bug: 169874632
Change-Id: I92426d8572f9ca71c053945ecc2afd839efbc058
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentAnimatorTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/DefaultSpecialEffectsController.java
jb...@google.com <jb...@google.com> #4
This has been fixed internally and will be available in the Fragment 1.3.0-beta02
release.
You can verify this by following the 6982024
and switching your fragment dependency to 1.3.0-SNAPSHOT
.
Description
Component used: Fragment
Version used: 1.3.0-beta01
Devices/Android versions reproduced on: Pixel 2 API 29 emulator
Muzei's
main
module usesTRANSIT_FADE
to swap between fragments based on whether Muzei is your current wallpaper. This listener is set on aFlow
that runs when the fragment is at leastSTARTED
, meaning that callbacks end up normally being triggered as part of the move toSTARTED
.Reproduction steps:
FragmentManager.enableNewStateManager(false)
inMuzeiApplication
in themain
moduleExpected behavior: Next screen (
TutorialFragment
) appearsActual behavior: New fragment does not appear, despite going to
RESUMED
stateAdditional information: If I attach the layout inspector, the fragment magically appears!
Removing the
TRANSIT_FADE
or using the old state manager causes everything to work as expected as well.