Fixed
Status Update
No update yet.
Comments
tj...@gmail.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.
te...@gmail.com
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.
st...@gmail.com
I can confirm this too for 27.1.0. Any workaround for this?
da...@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.
wh...@gmail.com
I also confirm this. Helps only return on 27.0.2
il...@google.com
fl...@gmail.com
I can confirm this bug. Reverting to 27.0.2 helped.
jo...@onsalesit.com
same here. reverte is the only workaround atm
dj...@gmail.com
I have the same issue. I had enter animation as fade_in and exit animation as fade_out. For me temporary solution is change exit animation to 0, transaction now looks almost the same as with fade_out exit animation
mo...@google.com
mo...@google.com
Thank you for reporting this bug. I am able to reproduce it. It was caused when fixing another bug and this error wasn't caught during testing.
ra...@gmail.com
Same issue. I had to roll back version to fix it
mo...@google.com
Fix has been submitted and should be in the next public release.
kk...@google.com
This bug has been fixed in Support Library 27.1.1.
al...@gmail.com
In the app that I am working on, this issue only occurs when pressing back (unwinding the transaction). The problem is still reproducible in 27.1.1. Does 27.1.1 fix the problem for others?
Description
Version used: 27.1.0
Theme used: AppCompat No ActionBar
Devices/Android versions reproduced on:
I currently use a base fragment transaction with the following code to animate fragment replacements by default from within a support fragment:
getFragmentManager()
.beginTransaction()
.setCustomAnimations(android.R.anim.fade_in, android.R.anim.fade_out, android.R.anim.fade_in, android.R.anim.fade_out);
This worked great on Support library version 27.0.2 and below. Version 27.1.0 however causes the replaced fragment to flicker for a second or so after the new fragment is shown.
The fragment transactions do NOT have setReorderingAllowed to true, NOR do they postpone any pending transitions.