Fixed
Status Update
No update yet.
Comments
il...@google.com
ap...@google.com
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
ni...@ansman.se
I left a comment on the CL, but I think the handler should be reused in case postponeEnterTransition is called multiple times.
jb...@google.com
Reusing it would mean we could end up not using the host's handler when we are actually attached. Probably should just clear it and start over with the right handler.
ni...@hinge.co
Well the problem now, at least, is that if you call that twice we attempt to remove the old callbacks from the wrong handler (in some cases).
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 880c9f06b39cf910003606a5ab5e2f88f9062ccb
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Apr 11 19:26:19 2023
Ensure postponed fragments don't leak with multiple calls
We need to make sure when postponedEnterTransition is called multiple
times, we still don't cause a leak whether we are attached to a
FragmentManager or not.
So if we call postponedEnterTransition again, we remove the callback
from the previous handler and proceed as if we never made the first
call.
Test: added PostponedTransitionTest
Bug: 276375110
Change-Id: Id6d0d3bf30a109bb1020de9f66bd4d972373334d
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PostponedTransitionTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
https://android-review.googlesource.com/2531863
Branch: androidx-main
commit 880c9f06b39cf910003606a5ab5e2f88f9062ccb
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Apr 11 19:26:19 2023
Ensure postponed fragments don't leak with multiple calls
We need to make sure when postponedEnterTransition is called multiple
times, we still don't cause a leak whether we are attached to a
FragmentManager or not.
So if we call postponedEnterTransition again, we remove the callback
from the previous handler and proceed as if we never made the first
call.
Test: added PostponedTransitionTest
Bug: 276375110
Change-Id: Id6d0d3bf30a109bb1020de9f66bd4d972373334d
M fragment/fragment/src/androidTest/java/androidx/fragment/app/PostponedTransitionTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
jb...@google.com
This has been fixed internally and will be available in the Fragment 1.5.7 and 1.6.0-beta01 releases.
pr...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.fragment:fragment:1.5.7androidx.fragment:fragment:1.6.0-beta01
Description
Component used: Fragment
Version used:
1.5.6If you call
Fragment.postponeEnterTransitionwith a delay,Fragmentwill post a runnable on a Handler with the specified delay as the delay. This runnable is not removed when callingstartPostponedEnterTransitionhowever which means that if the fragment is destroyed it will be retained until the runnable finally runs.You can easily verify this with LeakCanary by having two fragments where in the first fragment you call
postponeEnterTransition(1, TimeUnit.HOURS)and then you navigate to the other fragment. When leak canary runs you can see that the initial fragment is retained.The solution should be to remove the runnable when calling
startPostponedEnterTransition. This might not be feasible in the case where you callpostponeEnterTransitionbefore the fragment is attached but it feels OK to ignore that case for now.