Feature Request: Support delayed WorkManager initialization by initializing WorkManager in Services/Receivers [127497100]

Fixed

Feature Request

Status Update

No update yet.

Description

li...@pinterest.com

created issue #1

Mar 5, 2019 11:23PM

Component used: WorkManager
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)

Comments

su...@google.com <su...@google.com> #2Mar 5, 2019 11:26PM

Please include a sample project that reproduces your issue.

ap...@google.com <ap...@google.com> #3Apr 3, 2019 12:35AM

Sample project attached. Just add to plain project this dependencies allow to reproduce.

def emoji2_version = "1.1.0-beta01"
implementation "androidx.emoji2:emoji2:$emoji2_version"

def lifecycle_version = "2.5.0-alpha01"
implementation "androidx.lifecycle:lifecycle-process:$lifecycle_version"

ra...@google.com <ra...@google.com> Apr 3, 2019 08:30PM

Marked as fixed, reassigned to ra...@google.com.

li...@pinterest.com <li...@pinterest.com> #4Apr 15, 2019 05:39PM

The reason may be related to this change, which check itself before it is initialized. Use 2.4.0 of lifecycle-process as workaround.

su...@google.com <su...@google.com> #5Apr 15, 2019 05:46PM

Yes, this is due to this change, as well as the fact that EmojiCompatInitializer has a ProcessLifecycleInitializer as a dependency and also re-calls it, but in manual mode.

li...@pinterest.com <li...@pinterest.com> #6Apr 15, 2019 06:02PM

ProcessLifecycleInitializer is expected to already be initialized (via the manifest provider for App Startup) by the time that code runs - App Startup shouldn't be calling create if that component has already been initialized, hence you shouldn't get any exception. We'll take a look on where things are breaking down though.

cr...@gmail.com <cr...@gmail.com> #7May 25, 2019 09:07PM

Thanks for the answer.

As I understand EmojiCompatInitializer has ProcessLifecycleInitializer as a dependency. That is mean, the ProcessLifecycleInitializer must be executed before the EmojiCompatInitializer, which in its create method calls the delayUntilFirstResume method, which in turn calls the ProcessLifecycleInitializer via appInitializer.initializeComponent(ProcessLifecycleInitializer.class)

Maybe it would be more correct to create a bug in emoji-2, but let it be here.