Fixed
Status Update
No update yet.
Comments
il...@google.com
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.
il...@google.com
lo...@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.
ja...@gmail.com
I can confirm this too for 27.1.0. Any workaround for this?
b9...@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.
ka...@gmail.com
I also confirm this. Helps only return on 27.0.2
b9...@gmail.com
I can confirm this bug. Reverting to 27.0.2 helped.
yc...@gmail.com
same here. reverte is the only workaround atm
il...@google.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
[Deleted User] <[Deleted User]>
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.
kk...@google.com
Same issue. I had to roll back version to fix it
[Deleted User] <[Deleted User]>
Fix has been submitted and should be in the next public release.
an...@gmail.com
This bug has been fixed in Support Library 27.1.1.
il...@google.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?
al...@gmail.com
The following scenario is still unfixed:
Have Don't keep activities enabled.
Start the app.
Push home button.
On 27.0.2 I have the following output at logcat:
V/ViewModelFirst: Created
V/ViewModelFirst: onCleared
V/FragmentFirst: onDestroy
V/MainActivity: onDestroy
Which totally correct.
But on 27.1.1 till 28.0.0-alpha3 I have the following output at logcat:
V/ViewModelFirst: Created
V/FragmentFirst: onDestroy
V/MainActivity: onDestroy
As we can see activity and fragment was destroyed but viewModel was not notified with onCleared.
I suspect that in case if the Don't keep activities will be disabled and the app at background will be naturally unloaded by Android at some moment of time the viewModel.onCleared() will not be called which is very sad.
Have Don't keep activities enabled.
Start the app.
Push home button.
On 27.0.2 I have the following output at logcat:
V/ViewModelFirst: Created
V/ViewModelFirst: onCleared
V/FragmentFirst: onDestroy
V/MainActivity: onDestroy
Which totally correct.
But on 27.1.1 till 28.0.0-alpha3 I have the following output at logcat:
V/ViewModelFirst: Created
V/FragmentFirst: onDestroy
V/MainActivity: onDestroy
As we can see activity and fragment was destroyed but viewModel was not notified with onCleared.
I suspect that in case if the Don't keep activities will be disabled and the app at background will be naturally unloaded by Android at some moment of time the viewModel.onCleared() will not be called which is very sad.
lb...@gmail.com
@15 You should open a new thread. Once Google closes an issue , there is a much smaller chance they ever read what you've written in it, and it happens a lot, sadly
al...@gmail.com
3g...@gmail.com
file sdcard encrypt....
[Deleted User] <[Deleted User]>
Common
Description
implementation 'com.android.support:appcompat-v7:27.1.0'
implementation "android.arch.lifecycle:runtime:1.1.0"
implementation "android.arch.lifecycle:extensions:1.1.0"
implementation "android.arch.lifecycle:common-java8:1.1.0"
Version used: 27.1.0
Theme used: N/A
Devices/Android versions reproduced on: Emulator 24
- Relevant code to trigger the issue.
Make an Activity that contains a Fragment.
Make the Activity use a ViewModel, and make the Fragment also use a ViewModel.
Start the Activity and press back.
The Activity's ViewModel's onCleared method is called.
With AppCompat 27.0.2, the Fragment's ViewModel's onCleared method is called (as it should)
With AppCompat 27.1.0, the Fragment's ViewModel's onCleared method is not called (incorrect).
See the attached project that shows the issue.
With 27.0.2, the logs read:
---------------------------
org.jraf.android.viewmodelproblem.MainActivity: onCreate
org.jraf.android.viewmodelproblem.MainActivityViewModel: constructor
org.jraf.android.viewmodelproblem.MainFragment: onCreate
org.jraf.android.viewmodelproblem.MainFragmentViewModel: constructor
[back is pressed]
org.jraf.android.viewmodelproblem.MainActivity: onDestroy
org.jraf.android.viewmodelproblem.MainActivityViewModel: onCleared
org.jraf.android.viewmodelproblem.MainFragmentViewModel: onCleared
org.jraf.android.viewmodelproblem.MainFragment: onDestroy
With 27.1.0, the logs read:
---------------------------
org.jraf.android.viewmodelproblem.MainActivity: onCreate
org.jraf.android.viewmodelproblem.MainActivityViewModel: constructor
org.jraf.android.viewmodelproblem.MainFragment: onCreate
org.jraf.android.viewmodelproblem.MainFragmentViewModel: constructor
[back is pressed]
org.jraf.android.viewmodelproblem.MainActivity: onDestroy
org.jraf.android.viewmodelproblem.MainActivityViewModel: onCleared
org.jraf.android.viewmodelproblem.MainFragment: onDestroy
This seems to happen because of line 1645 of Fragment, this test:
if (mViewModelStore != null && !mHost.mFragmentManager.isStateSaved()) {
is always false because mHost.mFragmentManager.isStateSaved() is true.