Fixed
Status Update
Comments
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #2
Indexing also runs indefinitely here with Android studio 3.3 and a project that contains a NDK library (native engine + game). Previous versions, for instance 3.2.1, worked fine. Still occurs after clearing the caches and deleting the .idea folder. On a desktop with 32 GB of RAM it's not running out of memory but it indexes forever, pegging an entire CPU and disk access to 100%, and it never stops. The same thing occurs with gradle 4.6 or 4.10. If I enable the experimental scan active configuration only setting, everything is basically broken - no syntax highlighting, cpp files don't show. Waiting to see if there's a workaround before reverting to 3.2.1 and being much more cautious about updating in the future ..
ap...@google.com <ap...@google.com> #3
When I let it run for hours, the scanning eventually did complete, then the indexing took more hours, I let it run as well, and eventually it switched to 'building symbols' which also started taking a long time without progress, but that, eventually, crashed Android Studio with an out of memory error, telling me to increase the heap size. I did, and upon restarting Android Studio, it started over at scanning .. so I gave up for now. This is with a mid-size NDK project.
il...@google.com <il...@google.com> #4
Even after a dirty downgrade to AS 3.2 from 3.3 my project was stuck on scanning files to index and building symbols. I ended up having to fully remove all Android Studio files/folders. After relaunching AS 3.2 and setting heap size to 8GB the scanning, indexing and building symbols took just a couple minutes.
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.