Fixed
Status Update
Comments
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #2
Update: I was able to downgrade to 32.1.10 and I can confirm it's smooth again. The issue is indeed in emulator version 33.1.1
ap...@google.com <ap...@google.com> #3
It's happening to me too and I also confirm that reverting to 32.1.10 fixes the issue.
We should have an easier way of reverting versions. AS should allow picking the version similarly to how we already do for the other tools in SDK manager.
We should have an easier way of reverting versions. AS should allow picking the version similarly to how we already do for the other tools in SDK manager.
il...@google.com <il...@google.com> #4
Hi,
would you try to turn on hardware GPU rendering (instead of auto GPU) and see if it fixes this issue?
would you try to turn on hardware GPU rendering (instead of auto GPU) and see if it fixes this issue?
Description
Component used: Lifecycle
Version used: 2.5.0-alpha01
Currently the call to
enableSavedStateHandles()
creates aViewModel
using theViewModelStore
. This requires that the ViewModelStore be set on any component attempting to make the call, but there are scenarios where the call toenableSavedStateHandles
needs to happen before that in particular in the Fragment and Navigation components where the call is not immediately made when the object is constructed or sometimes not at all.If we remove the reliance on
SavedStateHandles
(and therefore view models), we can lean into theSavedStateProvider
APIs and the call toenableSavedStateHandles()
can be made before theViewModelStore
is set.