Obsolete
Status Update
No update yet.
Comments
il...@google.com
I should add, I never explicitly set setReorderingAllowed to true. The documentation states
The default is false for applications targeting version versions prior to O and true for applications targeting O and later.
I'm not sure how pertinent this is with the support library fragments.Compile SDK and Target SDK versions are both 27.
The default is false for applications targeting version versions prior to O and true for applications targeting O and later.
I'm not sure how pertinent this is with the support library fragments.Compile SDK and Target SDK versions are both 27.
[Deleted User] <[Deleted User]>
I can confirm that 27.1.0 has this bug. Downgrading to 27.0.2 worked for us (we came from 27.0.2).
It seems to be related to the fade transition, since setting the transition through the setTransition method of the FragmentTransaction results in the same behaviour.
It seems to be related to the fade transition, since setting the transition through the setTransition method of the FragmentTransaction results in the same behaviour.
il...@google.com
jb...@google.com
I can confirm this too for 27.1.0. Any workaround for this?
mc...@gmail.com
Seeing the same issue here with '.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE)' on Google Pixel 8.1.0. Attached a video comparing before and after.
My current workaround is to use a different transition such as TRANSIT_FRAGMENT_OPEN. It looks similar enough for me.
My current workaround is to use a different transition such as TRANSIT_FRAGMENT_OPEN. It looks similar enough for me.
jo...@gmail.com
I also confirm this. Helps only return on 27.0.2
jb...@google.com
I can confirm this bug. Reverting to 27.0.2 helped.
Description
Version used: 1.1.0
Devices/Android versions reproduced on: Samsung S7 edge (API 24), One Plus 3T (API 28), One Plus 5T (API 28), Emualtor Google Pixel 3A XL (API 29)
A memory leak happens in a fragment transition with custom animations applied if the screen is turned off before the transition begins. In the attached sample you can see that the layout of the "LeakingFragment" is being leaked as long as the activity is opened because Fragment.mAnimationInfo holds a reference on it. I can see that mAnimationInfo is never set to null except in the constructor. As a first fix I would suggest to set mAnimationInfo to null in onDestroyView of the fragment. This does not fix the underlying issue of the memory leak during transitions since onDestroy and onDismiss of the "LeakingFragment" are only called when the activity itself goes into the background and not when the new fragment is replacing it.