WorkManager is not initialized properly

[nan-li]

Description

We have seen many reported crashes related to this particular WorkManager IllegalStateException:

WorkManager is not initialized properly. You have explicitly disabled WorkManagerInitializer in your manifest, have not manually called WorkManager#initialize at this point, and your Application does not implement Configuration.Provider.

However, the OneSignal SDK uses the default WorkManagerInitializer and does not disable it. We are collecting information to investigate any solutions on our end as well as make a report of this to Google, as this seems to be related to an AndroidX library that OneSignal uses. For reference, these are reports of this and related exceptions to Google's Issue Tracker.

Current status

Google Issue Tracker

We reported this to Google's WorkManager issues here.

Summary

From reported stacktraces, the crash arises from OSNotificationRestoreWorkManager.beginEnqueueingWork(), OSFocusHandler.cancelOnLostFocusWorker() , and OSFocusHandler.startOnLostFocusWorker().

We know this can be related to multiprocess, but we have also seen many reports of this exception in applications that don't use multiprocess.

This is happening on applications that don't use WorkManager themselves and don't use Custom WorkManager Configuration and Initialization.

OneSignal maintainers have not been able to reproduce this crash, and users have not reported being able to reproduce this crash either. While there have been reports of some apps encountering this crash 100% of the time, those cases are related to other underlying issues.

This crash is also happening across multiple versions of androidx.work:work-runtime including on the latest stable release 2.7.1. It also appears to affect devices across types, brands, and Android versions.

We speculate it may have to do with the initialization of libraries and components during an app's startup process, and encountering edge cases where OneSignal tries to access the WorkManager singleton but it has not yet been initialized by the system. This crash happens when the OneSignal SDK calls WorkManager.getInstance(Context) and the WorkManager is null.

Also from Android docs, content providers are created on the application main thread at application launch time and Android initializes content providers in an undetermined order. If there are many providers to initialize, the one that contains the WorkManagerInitializer may not get created until later in the process, making the edge case more likely. In addition, if other <providers>s in the Manifest have initOrder set, those will initialize first.

Details Appreciated

To investigate further and gather insight into this crash's relationship to the app startup process, please tell us as much of the following information as possible.

1. Confirm that you are not using custom WorkManagerInitializer yourself.

2. Please look in the Merged Manifest for all the <provider> tags you have. Please provide the exact content of all of them. This information is informative as we speculate that having more ContentProviders may cause this crash to happen more often. Providing the full information helps us know which ones are involved. Here is an example:

    <provider 
        android:name="com.google.firebase.provider.FirebaseInitProvider" 
        android:authorities="{myApplicationId}.firebaseinitprovider" 
        android:directBootAware="true" 
        android:exported="false" 
        android:initOrder="100" />
    
    <provider 
        android:name="androidx.startup.InitializationProvider" 
        android:authorities="{myApplicationId}.androidx-startup" 
        android:exported="false" > 
        <meta-data 
            android:name="androidx.lifecycle.ProcessLifecycleInitializer" 
            android:value="androidx.startup" /> 
        <meta-data 
            android:name="androidx.work.WorkManagerInitializer" 
            android:value="androidx.startup" /> 
    </provider>
    
    <provider 
        android:name="io.intercom.android.sdk.IntercomInitializeContentProvider" 
        android:authorities="{myApplicationId}.IntercomInitializeContentProvider" 
        android:exported="false" />
    
    // ... and more

3. Look in the Merged Manifest or run ./gradlew app:dependencies to tell us the version of androidx.work:work-runtime your app is using.

4. Analytics of this crash: What devices and Android versions are experiencing the crash? Are there some devices or Android versions that are affected more?

5. Analytics of this crash: How many users and what percent of your users experienced this crash?

6. The stacktrace for this crash.

7. The version of the OneSignal-Android-SDK your app is using.

8. Are you able to reproduce this crash yourself?

9. Do you have information about when you started seeing this crash, what changes were made?

Possible Fix on the SDK User's End

Implement a custom WorkManagerInitializer for your app by following the On-Demand Initialization guide. Make sure to complete both steps for "Remove the default initializer" and "Implement Configuration.Provider".

This crash happens when the OneSignal SDK calls WorkManager.getInstance(Context) when the WorkManager singleton has not yet been initialized by the system, and the method will produce this exception. However, if an app implemented custom WorkManagerInitializer, this method will instead initialize the WorkManager singleton when it is null.

If you do this, please report back your results.

[nan-li]

One internal report:

1. Not using custom WorkManagerInitializer and not disabling the default. No multiprocess.

2. The app developer has 8 <provider> tags in the Merged Manifest, 4 of which has initOrder set:

        <provider
            android:name="androidx.startup.InitializationProvider"
            android:authorities="{myApplicationId}.androidx-startup"
            android:exported="false" >
            <meta-data
                android:name="androidx.lifecycle.ProcessLifecycleInitializer"
                android:value="androidx.startup" />
            <meta-data
                android:name="androidx.work.WorkManagerInitializer"
                android:value="androidx.startup" />
        </provider>
    
        <provider
            android:name="{some.library}.SomeProvider"
            android:authorities="{myApplicationId}.SomeProvider"
            android:exported="false"
            android:initOrder="99" />

        <provider
            android:name="com.google.firebase.provider.FirebaseInitProvider"
            android:authorities="{myApplicationId}.firebaseinitprovider"
            android:directBootAware="true"
            android:exported="false"
            android:initOrder="100" />

        <provider
            android:name="{some.library}.SomeProvider"
            android:authorities="{myApplicationId}.SomeProvider"
            android:exported="false" />

        <provider
            android:name="{some.library}.SomeProvider"
            android:authorities="{myApplicationId}.SomeProvider"
            android:exported="false"
            android:grantUriPermissions="true"
            android:initOrder="101" />

        <provider
            android:name="com.google.android.gms.ads.MobileAdsInitProvider"
            android:authorities="{myApplicationId}.mobileadsinitprovider"
            android:exported="false"
            android:initOrder="100" />

        <provider
            android:name="{some.library}.SomeProvider"
            android:authorities="{myApplicationId}.SomeProvider"
            android:exported="false"
            android:grantUriPermissions="true" />

        <provider
            android:name="{some.library}.SomeProvider"
            android:authorities="{myApplicationId}.SomeProvider" />
    

3. androidx.work:work-runtime version 2.7.1

4. Analytics of this crash: What devices and Android versions are experiencing the crash? Are there some devices or Android versions that are affected more?

Reported for Samsung and Hawei. Unsure of more specifics (unreported to us).

5. Reported ~500 crashes over 7 days for OSNotificationRestoreWorkManager.beginEnqueueingWork() and ~400 crashes over 7 days for OSFocusHandler.startOnLostFocusWorker. Percentage: Unreported to us.

6. The stacktrace for this crash.

Fatal Exception: java.lang.IllegalStateException
WorkManager is not initialized properly. You have explicitly disabled WorkManagerInitializer in your manifest, have not manually called WorkManager#initialize at this point, and your Application does not implement Configuration.Provider.

androidx.work.impl.WorkManagerImpl.getInstance (WorkManagerImpl.java:158)
androidx.work.WorkManager.getInstance (WorkManager.java:184)
com.onesignal.OSNotificationRestoreWorkManager.beginEnqueueingWork (OSNotificationRestoreWorkManager.java:48)
com.onesignal.OneSignal.handleActivityLifecycleHandler (OneSignal.java:968)
com.onesignal.OneSignal.init (OneSignal.java:845)
com.onesignal.OneSignal.setAppId (OneSignal.java:728)
com.onesignal.OneSignal.reassignDelayedInitParams (OneSignal.java:1174)
com.onesignal.OneSignal.onRemoteParamSet (OneSignal.java:882)
com.onesignal.OneSignal$7.complete (OneSignal.java:1115)
com.onesignal.OneSignalRemoteParams.processJson (OneSignalRemoteParams.java:206)
com.onesignal.OneSignalRemoteParams.access$100 (OneSignalRemoteParams.java:12)
com.onesignal.OneSignalRemoteParams$1.onSuccess (OneSignalRemoteParams.java:151)
com.onesignal.OneSignalRestClient$5.run (OneSignalRestClient.java:292)
java.lang.Thread.run (Thread.java:784)

7. OneSignal Android SDK v4.7.1.

8. Are you able to reproduce this crash yourself? No, can't reproduce.

9. Started seeing this after upgrading the from the previous major release (3.x.x).

[toseefhaiderkhansugguu]

Description

We have seen many reported crashes related to this particular WorkManager IllegalStateException:

WorkManager is not initialized properly. You have explicitly disabled WorkManagerInitializer in your manifest, have not manually called WorkManager#initialize at this point, and your Application does not implement Configuration.Provider.

However, the OneSignal SDK uses the default WorkManagerInitializer and does not disable it. We are collecting information to investigate any solutions on our end as well as make a report of this to Google, as this seems to be related to an AndroidX library that OneSignal uses. For reference, these are reports of this and related exceptions to Google's Issue Tracker.

Current status

Google Issue Tracker

We reported this to Google's WorkManager issues here.

Summary

From reported stacktraces, the crash arises from OSNotificationRestoreWorkManager.beginEnqueueingWork(), OSFocusHandler.cancelOnLostFocusWorker() , and OSFocusHandler.startOnLostFocusWorker().

We know this can be related to multiprocess, but we have also seen many reports of this exception in applications that don't use multiprocess.

This is happening on applications that don't use WorkManager themselves and don't use Custom WorkManager Configuration and Initialization.

OneSignal maintainers have not been able to reproduce this crash, and users have not reported being able to reproduce this crash either. While there have been reports of some apps encountering this crash 100% of the time, those cases are related to other underlying issues.

This crash is also happening across multiple versions of androidx.work:work-runtime including on the latest stable release 2.7.1. It also appears to affect devices across types, brands, and Android versions.

We speculate it may have to do with the initialization of libraries and components during an app's startup process, and encountering edge cases where OneSignal tries to access the WorkManager singleton but it has not yet been initialized by the system. This crash happens when the OneSignal SDK calls WorkManager.getInstance(Context) and the WorkManager is null.

Also from Android docs, content providers are created on the application main thread at application launch time and Android initializes content providers in an undetermined order. If there are many providers to initialize, the one that contains the WorkManagerInitializer may not get created until later in the process, making the edge case more likely. In addition, if other <providers>s in the Manifest have initOrder set, those will initialize first.

Details Appreciated

To investigate further and gather insight into this crash's relationship to the app startup process, please tell us as much of the following information as possible.

1. Not using custom WorkManagerInitializer. by default onesignal injecting to my merged manifest file
2. <provider android:name="androidx.startup.InitializationProvider" android:authorities="bundle id.androidx-startup" android:exported="false" > <meta-data android:name="androidx.work.WorkManagerInitializer" android:value="androidx.startup" /> <meta-data android:name="androidx.lifecycle.ProcessLifecycleInitializer" android:value="androidx.startup" /> </provider>
3. Look in the Merged Manifest or run ./gradlew app:dependencies to tell us the version of androidx.work:work-runtime your app is using.
4. device model :Oppo A12 Android version 9
5. I am seeing this crash on close testing release and also when we test apk
6. At this time i have this android logcat screenshoot

7. The version of the OneSignal-unity-SDK is 3.0.7
8. Yes. this crash mostly occurs on low end devices at the time of one-signal initialisation
9. Started to see this crash on latest update i updated my SDK from 2.14.1 to 3.0.7
   10-unity 2020.3.42f1

Possible Fix on the SDK User's End

Implement a custom WorkManagerInitializer for your app by following the On-Demand Initialisation guide. Make sure to complete both steps for "Remove the default initializer" and "Implement Configuration.Provider".

This crash happens when the OneSignal SDK calls WorkManager.getInstance(Context) when the WorkManager singleton has not yet been initialised by the system, and the method will produce this exception. However, if an app implemented custom WorkManagerInitializer, this method will instead initialize the WorkManager singleton when it is null.

If you do this, please report back your results.

[jkasten2]

@toseefhaiderkhansugguu Thanks for reporting, however on item 2 I noticed you don't have the com.google.firebase.provider.FirebaseInitProvider <provider> listed so your list seems incomplete.
With Unity can you check this specific file for all the <provider> entries?

• Temp\gradleOut\launcher\build\intermediates\merged_manifests\release\AndroidManifest.xml
  • Also if possible please provide the matching lines from Temp\gradleOut\launcher\build\intermediates\manifest_merge_blame_file\release\manifest-merger-blame-release-report.txt so we know the exact versions involved.

<provider> entries from other libraries seems to be the best lead we have so far on the issue.

[nan-li]

Hi @toseefhaiderkhansugguu,

Another thing that stands out is that you can reproduce this crash, which is a big step forward because we have not heard reports of successful reproduction.

"Yes. this crash mostly occurs on low end devices at the time of one-signal initialisation"

1. For devices you can reproduce this on, can you estimate how often this crash happens?
   100% of the time? 50%? Very rarely?
2. Any statistics on how often or rare this crash happens in general?
   For example, you tested on 100 devices and 3 devices have seen this crash, etc.
3. Can you test for us if setting initOrder of the InitializationProvider to a high value leads to the crash happening less often?
   But first, we would like to know all of the <provider>s from your merged manifest as @jkasten2 asked above like this:

        <provider
            android:name="androidx.startup.InitializationProvider"
            android:authorities="{myApplicationId}.androidx-startup"
            android:exported="false" >
            <meta-data
                android:name="androidx.lifecycle.ProcessLifecycleInitializer"
                android:value="androidx.startup" />
            <meta-data
                android:name="androidx.work.WorkManagerInitializer"
                android:value="androidx.startup" />
        </provider>

       ...

        <provider
            android:name="{some.library}.SomeProvider"
            android:authorities="{myApplicationId}.SomeProvider"
            android:exported="false"
            android:initOrder="99" />

       ...

        <provider
            android:name="com.google.firebase.provider.FirebaseInitProvider"
            android:authorities="{myApplicationId}.firebaseinitprovider"
            android:directBootAware="true"
            android:exported="false"
            android:initOrder="100" />

       ...

        <provider
            android:name="com.google.android.gms.ads.MobileAdsInitProvider"
            android:authorities="{myApplicationId}.mobileadsinitprovider"
            android:exported="false"
            android:initOrder="100" />
    

[mhchoi-bagelcode]

I implemented the below code as Google's guide to fix this issue temporally on our side. But unfortunately this issue has not resolved yet. And the worse part of this crash is that it usually occur on main activity's onResume cycle, so it kills my app whenever users return from other activities like as Ad viewer, etc.

Is there anyone who resolves this issue with the below fix?

Possible Fix on the SDK User's End

Implement a custom WorkManagerInitializer for your app by following the On-Demand Initialization guide. Make sure to complete both steps for "Remove the default initializer" and "Implement Configuration.Provider".

This crash happens when the OneSignal SDK calls WorkManager.getInstance(Context) when the WorkManager singleton has not yet been initialized by the system, and the method will produce this exception. However, if an app implemented custom WorkManagerInitializer, this method will instead initialize the WorkManager singleton when it is null.

If you do this, please report back your results.

And here's answers for questions.

1. I'm using custom WorkManagerInitializer like as the below code to try to fix this issue (but not worked)

// In Application.java

 public class GlobalApplication extends MultiDexApplication implements Configuration.Provider {
  private static final String TAG = "UnityPlayerActivity";

  // TEMP: Avoid OneSignal Crash https://github.com/OneSignal/OneSignal-Android-SDK/issues/1672
  @Override
  public Configuration getWorkManagerConfiguration() {
      return new Configuration.Builder()
              .setMinimumLoggingLevel(android.util.Log.INFO)
              .build();
  }
  
  ...

// In Manifest.xml

...
    <!-- TEMP: Avoid OneSignal Crash https://github.com/OneSignal/OneSignal-Android-SDK/issues/1672 -->
    <provider
      android:name="androidx.startup.InitializationProvider"
      android:authorities="${applicationId}.androidx-startup"
      tools:node="remove">
    </provider>
...    

<provider android:authorities="{myApplicationId}.IronsourceLifecycleProvider" android:exported="false" android:name="com.ironsource.lifecycle.IronsourceLifecycleProvider"/>

<provider android:authorities="{myApplicationId}.applovincontentprovider" android:exported="false" android:grantUriPermissions="true" android:initOrder="101" android:name="com.applovin.sdk.AppLovinInitProvider"/>
        
<provider android:authorities="{myApplicationId}.mobileadsinitprovider" android:exported="false" android:initOrder="100" android:name="com.google.android.gms.ads.MobileAdsInitProvider"/>

<provider android:authorities="{myApplicationId}.AudienceNetworkContentProvider" android:exported="false" android:name="com.facebook.ads.AudienceNetworkContentProvider"/>

<provider android:authorities="{myApplicationId}.firebaseinitprovider" android:directBootAware="true" android:exported="false" android:initOrder="100" android:name="com.google.firebase.provider.FirebaseInitProvider"/>

<provider android:authorities="{myApplicationId}.vungle-provider" android:exported="false" android:name="com.vungle.warren.utility.VungleProvider"/>

<provider android:authorities="{myApplicationId}.FacebookInitProvider" android:exported="false" android:name="com.facebook.internal.FacebookInitProvider"/>

androidx.work:work-runtime 2.7.0

most version of Android (5~12)
many devices models

200 crashes per day on Google Play Console. It's almost a half of all crashes we're getting.
I've been getting about 10 reports from users per a day about this crash.

Caused by: java.lang.RuntimeException: Unable to resume activity {UnityPlayerActivity}: java.lang.IllegalStateException: WorkManager is not initialized properly.  You have explicitly disabled WorkManagerInitializer in your manifest, have not manually called WorkManager#initialize at this point, and your Application does not implement Configuration.Provider.
  at android.app.ActivityThread.performResumeActivity (ActivityThread.java:5230)
  at android.app.ActivityThread.handleResumeActivity (ActivityThread.java:5269)
  at android.app.servertransaction.ResumeActivityItem.execute (ResumeActivityItem.java:54)
  at android.app.servertransaction.ActivityTransactionItem.execute (ActivityTransactionItem.java:45)
  at android.app.servertransaction.TransactionExecutor.executeLifecycleState (TransactionExecutor.java:176)
  at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:97)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2438)
  at android.os.Handler.dispatchMessage (Handler.java:106)
  at android.os.Looper.loopOnce (Looper.java:226)
  at android.os.Looper.loop (Looper.java:313)
  at android.app.ActivityThread.main (ActivityThread.java:8663)
  at java.lang.reflect.Method.invoke
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:567)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
Caused by java.lang.IllegalStateException: WorkManager is not initialized properly.  You have explicitly disabled WorkManagerInitializer in your manifest, have not manually called WorkManager#initialize at this point, and your Application does not implement Configuration.Provider.
  at androidx.work.impl.WorkManagerImpl.getInstance (WorkManagerImpl.java:158)
  at androidx.work.WorkManager.getInstance (WorkManager.java:184)
  at com.onesignal.OSFocusHandler.cancelOnLostFocusWorker (OSFocusHandler.kt:94)
  at com.onesignal.ActivityLifecycleHandler.handleFocus (ActivityLifecycleHandler.java:194)
  at com.onesignal.ActivityLifecycleHandler.onActivityResumed (ActivityLifecycleHandler.java:95)
  at com.onesignal.ActivityLifecycleListener.onActivityResumed (ActivityLifecycleListener.java:91)
  at android.app.Application.dispatchActivityResumed (Application.java:435)
  at android.app.Activity.dispatchActivityResumed (Activity.java:1437)
  at android.app.Activity.onResume (Activity.java:1994)
  at ..UnityPlayerActivity.onResume (UnityPlayerActivity.java:339)
  at android.app.Instrumentation.callActivityOnResume (Instrumentation.java:1476)
  at android.app.Activity.performResume (Activity.java:8441)
  at android.app.ActivityThread.performResumeActivity (ActivityThread.java:5200)

com.onesignal:OneSignal 4.8.3

No, I can't.

After I updated onesignal SDK version from 3.16.2 to 4.8.3

[jkasten2]

@mhchoi-bagelcode Thanks for reporting, and trying the workaround, it would seems this doesn't fix the root issue then based on your testing.

Possible issue

Can you check the logcat on your own devices to see if you have any java.lang.NoClassDefFoundError entries? Example:

Rejecting re-init on previously-failed class java.lang.Class<di2>: java.lang.NoClassDefFoundError: Failed resolution of: Landroid/webkit/PacProcessor;
...
at void com.google.android.gms.ads.internal.webview.ac.<init>(com.google.android.gms.ads.internal.webview.aw,

From the related Unity thread

The only theory we have is that other providers could be failing to load causing the other providers to never run. This is only a theory but there seems to be some relation so far. It is important to fix all java.lang.NoClassDefFoundError entries you are seeing to know if this has any effect.

Lastly are you able to reproduce the crash in any scenarios on your own devices?

[mhchoi-bagelcode]

@jkasten2
Unfortunately there's no logs about java.lang.NoClassDefFoundError. And I can't reproduce the crash on my own device. For next try, I'm going to remove the custom WorkManager logic soon and merge the below initOrder tag to the manifest and see the crashes will be gone.

    <provider android:name="androidx.startup.InitializationProvider"
      android:initOrder="200"
      tools:node="merge">
    </provider>

[jkasten2]

@mhchoi-bagelcode Thanks for the java.lang.NoClassDefFoundError detail, good to know that isn't a factor in your case.

I agree that setting a higher android:initOrder value is the next best thing to try here.

[mhchoi-bagelcode]

@jkasten2 Unfortunately, This crash has not been resolved, even if I injected the initOrder tag to our Manifest.xml

        <provider android:authorities="com.bagelcode.slots1.androidx-startup" android:exported="false" android:initOrder="200" android:name="androidx.startup.InitializationProvider">
            <meta-data android:name="androidx.work.WorkManagerInitializer" android:value="androidx.startup"/>
        </provider>

I don't know what to do for next step.
Maybe I can try downgrade sdk to 3.16.2 (that's I used before)
Is this safe idea?

[jkasten2]

@mhchoi-bagelcode There is possible fix that has worked for two others:

I solved this bug by removing these two attributes from my AndroidManifest.xml file.

<application
    android:label="@string/android_app_name" 
    android:icon="@drawable/Icon"
    android:largeHeap="true" 
    android:hardwareAccelerated="false" 
    android:allowBackup="false" 
    android:fullBackupContent="false" 
    tools:node="replace" 
    tools:ignore="GoogleAppIndexingWarning" 
    android:networkSecurityConfig="@xml/network_security_config">

Remove the tools:node="replace" attribute.

<activity 
    android:name="com.facebook.FacebookActivity" 
    android:configChanges="keyboard|keyboardHidden|screenLayout|screenSize|orientation" 
    android:theme="@android:style/Theme.Translucent.NoTitleBar" 
    android:label="@string/facebook_app_name" />

Remove the android:theme="@android:style/Theme.Translucent.NoTitleBar" attribute.

Source: #1561 (comment)

I would also recommend adding details to this Google thread to bring the issue to their attention:
https://issuetracker.google.com/issues/258176803

From what we have found so far this WorkManger issue doesn't seem to be an issue the way OneSignal is using WorkManager. The bug is present in app's that don't use OneSignal too, so we are trying to get Google to invest in helping find the root cause as well.

[alekssunsss]

There is a new last message (Jan 3, 2023 08:31PM) in the Google thread https://issuetracker.google.com/issues/258176803
What do you think about it?

[mhchoi-bagelcode]

@mhchoi-bagelcode There is possible fix that has worked for two others:

I solved this bug by removing these two attributes from my AndroidManifest.xml file.

<application
    android:label="@string/android_app_name" 
    android:icon="@drawable/Icon"
    android:largeHeap="true" 
    android:hardwareAccelerated="false" 
    android:allowBackup="false" 
    android:fullBackupContent="false" 
    tools:node="replace" 
    tools:ignore="GoogleAppIndexingWarning" 
    android:networkSecurityConfig="@xml/network_security_config">

Remove the tools:node="replace" attribute.

<activity 
    android:name="com.facebook.FacebookActivity" 
    android:configChanges="keyboard|keyboardHidden|screenLayout|screenSize|orientation" 
    android:theme="@android:style/Theme.Translucent.NoTitleBar" 
    android:label="@string/facebook_app_name" />

Remove the android:theme="@android:style/Theme.Translucent.NoTitleBar" attribute.

Source: #1561 (comment)

I would also recommend adding details to this Google thread to bring the issue to their attention: https://issuetracker.google.com/issues/258176803

From what we have found so far this WorkManger issue doesn't seem to be an issue the way OneSignal is using WorkManager. The bug is present in app's that don't use OneSignal too, so we are trying to get Google to invest in helping find the root cause as well.

This solution is not fit to our project (no tools:node="replace" attrubute already), so I couldn't try it.
I also recommend you to see the Google's comment @alekssunsss said.

[nan-li]

We saw the response from the Google representative, but they may not completely understand how OneSignal-Android-SDK is used in applications, or how the SDK uses WorkManager. It didn’t help us understand why this crash happens.

They are correct if OneSignal is initialized in a Content Provider, but it is not. The default Work Manger should be initialized by androidx.startup , which should be initialized before the Application class.

We can still try the speculative fix to initialize Work Manager ourselves if it is null, but because we don’t completely understand this crash, it will be speculative and the app can potentially run into a different crash in another part of the app (one that says WorkManager is already initialized.).

However, maybe it doesn't run into that second crash and this crash would be fixed.

[hayk888997]

hey @nan-li , Have you tried to add Multiprocess support dependency?

`implementation "androidx.work:work-multiprocess:$work_version"`

link to documentation

[nan-li]

Hey @hayk888997,

Good suggestion. Multiprocess support dependency is something that end users of OneSignal can add to their own Android Manifest if their app uses multiprocess. This rare crash we are seeing seems unrelated to having multiprocess apps as we have numerous reports of it on apps that do not use multiprocess.

[jkasten2]

Anyone who is having this issue please update to OneSignal-Android-SDK 4.8.5 as this should address this issue.

Please report back if updating to this version fixes the issue for you or if you continue to see these same crashes.

[kokowilly]

Caused by 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:185)
       at androidx.work.WorkManager.initialize(WorkManager.java:210)
       at com.onesignal.OSWorkManagerHelper.getInstance(OSWorkManagerHelper.kt:62)
       at com.onesignal.OSNotificationRestoreWorkManager.beginEnqueueingWork(OSNotificationRestoreWorkManager.java:47)
       at com.onesignal.UpgradeReceiver.onReceive(UpgradeReceiver.java:47)
       at android.app.ActivityThread.handleReceiver(ActivityThread.java:4894)
       at android.app.ActivityThread.-$$Nest$mhandleReceiver()
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2420)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loopOnce(Looper.java:226)
       at android.os.Looper.loop(Looper.java:313)
       at android.app.ActivityThread.main(ActivityThread.java:8757)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067) 

issue still persists, it happens after the App update. I cannot reproduce it on the emulator. got the data from Crashlytics.

Using 4.8.6

I run dependency initialization multithreaded.
I disabled WorkManagerInitializer.

Looking at your code, it might be possible that workmanager initialization happens during the small gap on checking workmanager instance is present or not, and request to initialize the workmanager from OSWorkManagerHelper. (Speculative)

[nan-li]

Hi @willyric17,

Thank you for reporting this update, and I apologize for the delay in responding.

The WorkManager is already initialized crash is something I thought may be possible after our fixes, and your speculative guess could be correct. There is synchronization and Android's WorkManager library also contains synchronization so I did not think it should happen.

Can you tell me if you experienced any WorkManager issues with OneSignal on your previous version? Did you ever have WorkManager is not initialized properly crash in the past?

Can you tell me how often WorkManager is already initialized happens in crashlytics? What devices and Android versions are experiencing the crash? How many users does it affect?

[nan-li]

Hi all, we made updates to Work Manager in Release 5.1.15 for the User Model SDK and Release 4.8.10 for the Player Model SDK.

[shefich]

Hi all, we made updates to Work Manager in Release 5.1.15 for the User Model SDK and Release 4.8.10 for the Player Model SDK.

Need update for version 3.x.x

[nan-li]

Yes, we will release updates for the cross-platform SDKs.

[shefich]

Yes, we will release updates for the cross-platform SDKs.

Yes, sorry I mean new version for Unity.

[jkasten2]

@shefich This update is now included in the OneSignal-Unity-SDK 5.1.7 release.

[shefich]

@jkasten2 what about version 3.x.x?
I mean update for the old SDK.