[Bug]: WorkManager crash on OneSignal 4.8.9

[bundleberk]

What happened?

I am using onesignal 4.8.9 and workmanager 2.8.1. I'm disabling workmanager initializer in my manifest because im using a custom workmanager configuration for setting the hilt worker factory. I am not initializing workmanager myself. I am seeing this crash in crashlytics and it is not rare, happens a lot.

We cannot upgrade to onesignal 5.x.x because of a bug that causes unresponsive notifications on xiaomi devices. So we are kind of stuck here.

Fatal Exception: java.lang.IllegalStateException: WorkManager is already initialized. Did you try to initialize it manually without disabling WorkManagerInitializer? See WorkManager#initialize(Context, Configuration) or the class level Javadoc for more information. at androidx.work.impl.WorkManagerImpl.initialize(WorkManagerImpl.java:200) at androidx.work.WorkManager.initialize(WorkManager.java:210) at com.onesignal.OSWorkManagerHelper.getInstance(OSWorkManagerHelper.kt:62) at com.onesignal.OSNotificationWorkManager.beginEnqueueingWork(OSNotificationWorkManager.java:66) at com.onesignal.NotificationBundleProcessor$3.onResult(NotificationBundleProcessor.java:423) at com.onesignal.OSNotificationDataController$5.run(OSNotificationDataController.java:242) at java.lang.Thread.run(Thread.java:923)

Any solutions?

Steps to reproduce?

Cannot reproduce

What did you expect to happen?

I expect no crashes

OneSignal Android SDK version

Release 4.8.9

Android version

13, 12, 11, 10, 9, 8, 7.1, 7.0

Specific Android models

No response

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[jkasten2]

@bundleberk I believe this is due a workaround for the "WorkManager is not initialized properly" bug with WorkManager we added in 4.8.5. In summary, since Google's WorkManager doesn't initialize sometimes (root cause of bug is unknown) the SDK OneSignal detects this and then initializes it to work around their bug. However if your app is also initializing WorkManager it can race with OneSignal initializing it, which results in the "WorkManager is already initialized" crash.

• Do you also have "WorkManager is already initialized" being thrown from your code initializing WorkManager? Or are you catching that?
• I wouldn't expect the crash to be common, as the race condition comes down to a a single if check. What percentage of crashes do you see? Could you share the crash report from the Google Console with OneSignal? See Google's guide on how to share SDK crashes.

In 5.x.x the "WorkManager is already initialized" should never throw from OneSignal code.

We cannot upgrade to onesignal 5.x.x because of a bug that causes unresponsive notifications on xiaomi devices. So we are kind of stuck here.

Thanks for the feedback, this signal means we can try get more priority on fixing that issue.

[bundleberk]

I am not initializing workmanager manually, I am only using a custom configuration to set hiltworkerfactory.

according to this document to be able to use custom configurations, the default workmanager initializer must be removed by adding a provider to the manifest and initializing workmanager yourself after that is not necessary.

I don't see the crash caused from our code and I've never caught it myself trying, so I guess somehow our app is winning the work manager initialization race every time somehow.

@jkasten2 do you think it would make a difference if I initialize workmanager manually just before I call onesignal.init()? And if you just check Workmanager.isInitialized() before initializing could solve the issue?

it is seen as the most common crash on crashlytics. I have approximately 12000 users downloaded this version of the app. Because this is a fresh release i don't see the crash on play console yet, only in crashlytics. as soon as i see it there i will share it with onesignal.

[bundleberk]

Any updates on this? @jkasten2

[emawby]

This looks like a duplicate of #1748. OneSignal is actively investigating solutions, but I will close this one to continue discussion in the other thread.