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

Project: platform/frameworks/support
Branch: androidx-main

commit 11a3cb30e7c9067a27eb10bf96e89afdc283ba2e
Author: pingxuanli <pingxuanli@google.com>
Date: Mon Aug 22 13:03:03 2022

Adding error message check in EntityUpsertionAdapter.

Bug: 243039555
Test: Tests are in EntityUpsertionAdapterTest file. By using toy, can check for foreign key constraint. (FK violation is commented out to prevent crash but the errors were thrown correctly)
Relnote: restrict the minimum version that supports Upsert to at least 16
Change-Id: I5f67f2ab5d41a313c48dac42f485f8345f74c1b1

M room/room-common/api/current.txt
M room/room-runtime/api/restricted_current.txt
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/DaoConflictStrategyTest.java
M room/room-common/src/main/java/androidx/room/Upsert.kt
M room/room-common/api/public_plus_experimental_current.txt
M room/room-runtime/api/current.txt
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/LiveDataQueryTest.java
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/EntityUpsertionAdapterTest.java
M room/room-runtime/api/public_plus_experimental_current.txt
M room/room-runtime/src/main/java/androidx/room/EntityUpsertionAdapter.kt
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/vo/Toy.java
M room/room-common/api/restricted_current.txt

https://android-review.googlesource.com/2191947

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

This bug was linked in a change in the following release(s):

androidx.room:room-common:2.5.0-beta01
androidx.room:room-runtime:2.5.0-beta01

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

This fix is also preventing the update when there is a uniqueness conflict on an index (code 2067 SQLITE_CONTRAINT_UNIQUE). In this case `checkUniquenessException(ex)` rethrows the exception. Is it expected ?

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

Thanks for the comment, indeed checkUniquenessException should not throw for SQLITE_CONSTRAINT_UNIQUE as per the SQLite docs:

The special UPSERT processing happens only for uniqueness constraint on the table that is receiving the INSERT. A "uniqueness constraint" is an explicit UNIQUE or PRIMARY KEY constraint within the CREATE TABLE statement, or a unique index. UPSERT does not intervene for failed NOT NULL or foreign key constraints or for constraints that are implemented using triggers.

In https://www.sqlite.org/lang_UPSERT.html

We'll make a fix to includes SQLITE_CONSTRAINT_UNIQUE as part of the 'uniqueness constraint' that will lead to an UPDATE.

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

Thanks for the update, really appreciate it !

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

Hello,

I've just hit this issue and I would like to know what's the status on handling 2067 SQLITE_CONSTRAINT_UNIQUE the same way and proceed to an update. I was very surprised upsert wasn't working.

Thanks