Fixed
Status Update
No update yet.
Comments
su...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit e2ac3b6793a301fe493b4e657e9cf1a02c780887
Author: Ian Lake <ilake@google.com>
Date: Fri Mar 18 23:02:22 2022
Call enableSavedStateHandles() immediately after performAttach()
Now that enableSavedStateHandles() no longer requires immediate
access to a ViewModel, we can safely call it immeidately after
performAttach().
Test: existing tests still pass
BUG: 215406268
Change-Id: I348ae5f95cb607e92e2f38bccc2b6d5b5876fb16
M navigation/navigation-common/build.gradle
M fragment/fragment/build.gradle
M activity/activity/src/main/java/androidx/activity/ComponentActivity.java
M fragment/fragment-ktx/build.gradle
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M activity/activity-ktx/build.gradle
M activity/activity/build.gradle
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentViewLifecycleOwner.java
M navigation/navigation-common/src/main/java/androidx/navigation/NavBackStackEntry.kt
https://android-review.googlesource.com/2032475
Branch: androidx-main
commit e2ac3b6793a301fe493b4e657e9cf1a02c780887
Author: Ian Lake <ilake@google.com>
Date: Fri Mar 18 23:02:22 2022
Call enableSavedStateHandles() immediately after performAttach()
Now that enableSavedStateHandles() no longer requires immediate
access to a ViewModel, we can safely call it immeidately after
performAttach().
Test: existing tests still pass
BUG: 215406268
Change-Id: I348ae5f95cb607e92e2f38bccc2b6d5b5876fb16
M navigation/navigation-common/build.gradle
M fragment/fragment/build.gradle
M activity/activity/src/main/java/androidx/activity/ComponentActivity.java
M fragment/fragment-ktx/build.gradle
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
M activity/activity-ktx/build.gradle
M activity/activity/build.gradle
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentViewLifecycleOwner.java
M navigation/navigation-common/src/main/java/androidx/navigation/NavBackStackEntry.kt
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 29973ff449dbac17299da3c113017e01dbde09d8
Author: Ian Lake <ilake@google.com>
Date: Fri Mar 18 22:16:45 2022
Remove dependency on ViewModels in enableSavedStateHandles()
Rather than requiring the creation of a ViewModel as part of
the call to enableSavedStateHandle(), defer that creation
until createSavedStateHandle() is actually called. This
ensures that enableSavedStateHandles() is safe to call before
the owner is attached to a Context, etc.
Relnote: "You can now retrieve a previously registered
`SavedStateProvider` from a `SavedStateRegistry` via
`getSavedStateProvider()`."
Test: updated tests
BUG: 215406268
Change-Id: I7ea470c1af0385b8bc9d8ca653c84cc8d224e6cf
M savedstate/savedstate/api/restricted_current.txt
M savedstate/savedstate/src/main/java/androidx/savedstate/SavedStateRegistry.java
M savedstate/savedstate/api/current.txt
M lifecycle/lifecycle-viewmodel-savedstate/build.gradle
M lifecycle/lifecycle-viewmodel-savedstate/src/main/java/androidx/lifecycle/SavedStateHandleSupport.kt
M lifecycle/lifecycle-viewmodel-savedstate/src/androidTest/java/androidx/lifecycle/viewmodel/savedstate/SavedStateHandleSupportTest.kt
M savedstate/savedstate/api/public_plus_experimental_current.txt
https://android-review.googlesource.com/2032091
Branch: androidx-main
commit 29973ff449dbac17299da3c113017e01dbde09d8
Author: Ian Lake <ilake@google.com>
Date: Fri Mar 18 22:16:45 2022
Remove dependency on ViewModels in enableSavedStateHandles()
Rather than requiring the creation of a ViewModel as part of
the call to enableSavedStateHandle(), defer that creation
until createSavedStateHandle() is actually called. This
ensures that enableSavedStateHandles() is safe to call before
the owner is attached to a Context, etc.
Relnote: "You can now retrieve a previously registered
`SavedStateProvider` from a `SavedStateRegistry` via
`getSavedStateProvider()`."
Test: updated tests
BUG: 215406268
Change-Id: I7ea470c1af0385b8bc9d8ca653c84cc8d224e6cf
M savedstate/savedstate/api/restricted_current.txt
M savedstate/savedstate/src/main/java/androidx/savedstate/SavedStateRegistry.java
M savedstate/savedstate/api/current.txt
M lifecycle/lifecycle-viewmodel-savedstate/build.gradle
M lifecycle/lifecycle-viewmodel-savedstate/src/main/java/androidx/lifecycle/SavedStateHandleSupport.kt
M lifecycle/lifecycle-viewmodel-savedstate/src/androidTest/java/androidx/lifecycle/viewmodel/savedstate/SavedStateHandleSupportTest.kt
M savedstate/savedstate/api/public_plus_experimental_current.txt
ra...@google.com
li...@pinterest.com
This decoupling has been complete and will be available in Lifecycle 2.5.0-alpha06.
su...@google.com
As this is a new API, this will first be released in 2.1.0-alpha01 and go through the normal alpha/beta/rc/stable release process. You can expect the first alpha in the next 2 weeks.
li...@pinterest.com
Great! Thanks for the fast response.
cr...@gmail.com
Wow super fast responce
Description
Version used: 1.0.0-beta05
Devices/Android versions reproduced on: all devices
The context of this ticket is to support initializing WorkManager a bit later after the application cold start in order to keep cold start fast. I am aware that:
1. WorkManager has this auto-initialization support through the WorkManagerInitializer provider.
2. It can be disabled and replaced by a custom provider to call WorkManager.initialize() directly or call it from Application.onCreate().
3. A number of services and receivers are registered by WorkManager and they rely on the early initialization of the WorkManager.
During testing, I realized the WorkManager.initialize() spends non-trivial time, it could be 50ms on some low end devices. So I want to avoid that delay during the cold start and have an option to initialize WorkManager a bit later. The request is to add code into the receivers and services to initialize WorkManager by themselves if WorkManager has not been initialized. This will help to cover the time from the application startup to the time that the application initialize the WorkManager manually.
Currently, a crash will happen in those receivers and services if they are triggered before the WorkManager is initialized in the application.
03-04 22:35:15.552 5784-5784/? E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.pinterest, PID: 5784
java.lang.RuntimeException: Unable to create service androidx.work.impl.background.systemjob.SystemJobService: java.lang.IllegalStateException: WorkManager needs to be initialized via a ContentProvider#onCreate() or an Application#onCreate().
at android.app.ActivityThread.handleCreateService(ActivityThread.java:3172)
at android.app.ActivityThread.-wrap5(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1550)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6077)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:866)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:756)
Caused by: java.lang.IllegalStateException: WorkManager needs to be initialized via a ContentProvider#onCreate() or an Application#onCreate().
at androidx.work.impl.background.systemjob.SystemJobService.onCreate(SystemJobService.java:68)
at android.app.ActivityThread.handleCreateService(ActivityThread.java:3162)
at android.app.ActivityThread.-wrap5(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1550)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6077)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:866)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:756)