Status Update
Comments
il...@google.com <il...@google.com> #2
Can you please upgrade to
yo...@luchegroup.com <yo...@luchegroup.com> #3
Thank you for your information about the fragment library updates. I've tried Fragment 1.6.0-alpha03 and unfortunately, this issue is still there. Saved state bundle structure is very different but it still contains duplicate state objects.
Here's what I get when TransactionTooLargeException
occurs with Fragment 1.6.0-alpha03. Apparently, there are 2 androidx.lifecycle.ViewModelProvider.DefaultKey:com.github.keithyokoma.poc.fatbundle.ui.home.HomeViewModel [size=268520]
entries in the saved state Bundle according to the ActivityStopInfo
log.
ActivityStopInfo W Bundle stats:
ActivityStopInfo W android:viewHierarchyState [size=6704]
ActivityStopInfo W android:views [size=6656]
ActivityStopInfo W androidx.lifecycle.BundlableSavedStateRegistry.key [size=546284]
ActivityStopInfo W androidx.lifecycle.internal.SavedStateHandlesProvider [size=1092]
ActivityStopInfo W android:support:activity-result [size=2252]
ActivityStopInfo W KEY_COMPONENT_ACTIVITY_REGISTERED_KEYS [size=1456]
ActivityStopInfo W android:support:fragments [size=542572]
ActivityStopInfo W fragment_02795c46-b71a-4ebf-b4d0-4f3e11676843 [size=542080]
ActivityStopInfo W childFragmentManager [size=539668]
ActivityStopInfo W fragment_bcb533f9-fd30-4807-8182-2b3510e88075 [size=539176]
ActivityStopInfo W viewRegistryState [size=269804]
ActivityStopInfo W androidx.lifecycle.BundlableSavedStateRegistry.key [size=269680]
ActivityStopInfo W androidx.lifecycle.internal.SavedStateHandlesProvider [size=268720]
ActivityStopInfo W androidx.lifecycle.ViewModelProvider.DefaultKey:com.github.keithyokoma.poc.fatbundle.ui.home.HomeViewModel [size=268520]
ActivityStopInfo W values [size=268428]
ActivityStopInfo W registryState [size=268972]
ActivityStopInfo W androidx.lifecycle.BundlableSavedStateRegistry.key [size=268848]
ActivityStopInfo W androidx.lifecycle.internal.SavedStateHandlesProvider [size=268720]
ActivityStopInfo W androidx.lifecycle.ViewModelProvider.DefaultKey:com.github.keithyokoma.poc.fatbundle.ui.home.HomeViewModel [size=268520]
ActivityStopInfo W values [size=268428]
ActivityStopInfo W savedInstanceState [size=1284]
il...@google.com <il...@google.com> #4
Thanks, that new structure makes it a lot more obvious about what is going on and confirms that there is something going wrong on our end. We'll take a look.
ap...@google.com <ap...@google.com> #5
Branch: androidx-main
commit 345d09ca4e1908954e8d38979cf9a63d0f030b1d
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Nov 08 17:15:50 2022
Prevent saving ViewModels in view saved state
Since converted fragents over to creation extras, we have a problem
where ViewModels were being saved in both the fragment and fragment view
saved state registries.
The cause of this is that the FragmentViewLifecycleOwner uses the
ViewModelStore of the fragment so when it calls enableSavedStateHandles
its registry also signs up to save all ViewModels in that store.
This is resolved by no longer calling enabledSavedStateHandles in
FragmentViewLifecycleOwner and making the default CreationExtras use the
fragment components directly.
RelNote: "Fragment will no longer incorrectly save ViewModels as part of
the view registry state."
Test: added test
Bug: 253546214
Change-Id: I10d2b5363d0abe967e92ad90a578d3bf88a2ca3b
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentViewLifecycleOwnerTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentViewLifecycleOwner.java
jb...@google.com <jb...@google.com> #6
This has been fixed internally and will be available in the Fragment 1.6.0-alpha04
release.
ju...@google.com <ju...@google.com> #7
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.fragment:fragment:1.6.0-alpha04
yo...@luchegroup.com <yo...@luchegroup.com> #8
Thanks for the bug fix, I have confirmed that the issue is resolved.
eu...@gmail.com <eu...@gmail.com> #9
We have a crash now with this change:
java.lang.IllegalStateException: enableSavedStateHandles() wasn't called prior to createSavedStateHandle() call
at androidx.lifecycle.SavedStateHandleSupport.getSavedStateHandlesProvider(SavedStateHandleSupport.kt:115)
at androidx.lifecycle.SavedStateHandleSupport.createSavedStateHandle(SavedStateHandleSupport.kt:65)
at androidx.lifecycle.SavedStateHandleSupport.createSavedStateHandle(SavedStateHandleSupport.kt:103)
at androidx.lifecycle.AbstractSavedStateViewModelFactory.create(AbstractSavedStateViewModelFactory.java:89)
at dagger.hilt.android.internal.lifecycle.HiltViewModelFactory.create(HiltViewModelFactory.java:116)
at androidx.lifecycle.ViewModelProvider.get(ViewModelProvider.kt:187)
at androidx.lifecycle.ViewModelProvider.get(ViewModelProvider.kt:153)
at androidx.lifecycle.viewmodel.compose.ViewModelKt.get(ViewModel.kt:215)
at androidx.lifecycle.viewmodel.compose.ViewModelKt.viewModel(ViewModel.kt:156)
at our.code. (points to the place where the ViewModel is injected into a constructor of a Composable view
What we do in the composable code we call viewModel
like:
val extras = MutableCreationExtras()
extras[SAVED_STATE_REGISTRY_OWNER_KEY] = LocalSavedStateRegistryOwner.current
extras[VIEW_MODEL_STORE_OWNER_KEY] = checkNotNull(LocalViewModelStoreOwner.current) {
"No ViewModelStoreOwner was provided via LocalViewModelStoreOwner"
}
extras[DEFAULT_ARGS_KEY] = bundleOf("PARAM_KEY" to "PARAM_VALUE")
return viewModel(extras = extras)
I see that enableSavedStateHandles
was deleted from FragmentViewLifecycleOwner
.
Can you give some recommendations about situation?
jb...@google.com <jb...@google.com> #10
Please file a separate bug with a minimal sample project that reproduces this issue.
Description
Devices/Android versions reproduced on: Nothing A063 running Android 12
PoC project:
When saving the ViewModel state object using SavedStateHandle, the object is stored in the Bundle of the FragmentState.
The issue is that the Bundle contains 2 identical ViewModel state object with different keys(`androidx.lifecycle.internal.SavedStateHandlesProvider` and `androidx.lifecycle.BundlableSavedStateRegistry.key`), so it takes up twice as much as the ViewState object size. If the ViewState object size gets bigger, it can easily cause `TransactionTooLargeException` whereas the single ViewState size is small enough to fit in the Bundle limit.