Crash in WorkerScheduler.startService

[upside-sarah]

Optimizely version: 3.10.1
Android versions: 6.0+

We have seen a repeated crash in our app related to the event rescheduler receiver. We have seen it reported in Google Play Store, but we have not been able to reproduce this crash locally, so it appears to be flaky. We added the receiver with the intent filters as described in the docs:

        <receiver android:enabled="true" android:exported="false" android:name="com.optimizely.ab.android.event_handler.EventRescheduler">
            <intent-filter>
                <action android:name="android.intent.action.MY_PACKAGE_REPLACED"/>
                <action android:name="android.intent.action.BOOT_COMPLETED"/>
                <action android:name="android.net.wifi.supplicant.CONNECTION_CHANGE"/>
            </intent-filter>
        </receiver>

Is there something else that we need to do to ensure our WorkManager is initialized here? We have not implemented a custom event handler or rescheduler, and we currently do not register any handlers in the code (we only have this change in the AndroidManifest.xml), but it was unclear to me in the documentation if we need to implement anything else.

Thanks!

Stacktrace:

Exception java.lang.RuntimeException: Unable to start receiver com.optimizely.ab.android.event_handler.EventRescheduler: 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.handleReceiver (ActivityThread.java:3797)
  at android.app.ActivityThread.access$1400 (ActivityThread.java:219)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1870)
  at android.os.Handler.dispatchMessage (Handler.java:107)
  at android.os.Looper.loop (Looper.java:214)
  at android.app.ActivityThread.main (ActivityThread.java:7378)
  at java.lang.reflect.Method.invoke
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:492)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:935)
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.optimizely.ab.android.shared.WorkerScheduler.startService (WorkerScheduler.java:102)
  at com.optimizely.ab.android.shared.WorkerScheduler.startService (WorkerScheduler.java:75)
  at com.optimizely.ab.android.event_handler.EventRescheduler.reschedule (EventRescheduler.java:88)
  at com.optimizely.ab.android.event_handler.EventRescheduler.onReceive (EventRescheduler.java:72)
  at android.app.ActivityThread.handleReceiver (ActivityThread.java:3788)

[jaeopt]

@upside-sarah Thanks for sharing. We'll take a look.

[jaeopt]

@upside-sarah can you confirm if you use a custom WorkManager configuration and Configuration.Provider has been set properly? https://developer.android.com/topic/libraries/architecture/workmanager/advanced/custom-configuration

[upside-sarah]

@jaeopt thanks so much for the quick response- we do not use a custom WorkManager configuration (and therefore do not set Configuration.Provider)

[upside-sarah]

@jaeopt we removed this receiver from our manifest as a short-term fix to resolve these crashes in our release, but would love to find a more permanent solution so we can add this behavior back in a future release soon!

[jaeopt]

@upside-sarah it's a good idea. We'll get you updated when we find more info on the issue.

[upside-sarah]

@jaeopt Update: we removed all references of EventRescheduler in our latest app version, but we are still seeing this issue reported for that release in the Play Store. Would love any additional guidance here. Thank you!

[jaeopt]

@upside-sarah It does not make sense that EventRescheduler is still called even after the receiver has been removed from the manifest. We'll look into it.
Can you confirm that those new crashes come from EventRescheduler and also if you do not register it programmatically anywhere in your app?

[upside-sarah]

@jaeopt I agree that it doesn't make sense 😅

1. confirmed that the issue is coming from EventRescheduler. We're seeing the same stacktrace as before:

Exception java.lang.RuntimeException: Unable to start receiver com.optimizely.ab.android.event_handler.EventRescheduler: 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.

2. we don't have any references to EventRescheduler in our app (searching the entire codebase for "EventRescheduler" returns nothing)

I don't know if there's some possibility that on upgrade, the previous receiver would be called? Otherwise, I'm unclear as to how this would be triggering.

[jaeopt]

@upside-sarah we found why you get the call even after EventRescheduler link is removed. In SDK 3.10.0+, the receiver is declared in the SDK manifest, which will be automatically merged into your final app manifest (so you do not need to declare the receiver again in your app manifest).

You can disable the receiver from our SDK with this ("remove") in your manifest -

<receiver
      android:name="com.optimizely.ab.android.event_handler.EventRescheduler"
      tools:node="remove">
</receiver>

Let us know if it works for you.

[upside-sarah]

Hi @jaeopt- that completely makes sense, we can definitely explicitly remove the EventRescheduler in our next release. Just want to confirm y'all are still looking into a solution for the greater problem (i.e. why declaring the rescheduler leads to a crash?), ideally we wouldn't have this disabled indefinitely. Thank you!

[jaeopt]

@upside-sarah We'll continue looking into the issue and get you updated.

[Tamara-Barum]

Closing this open git issue as fixed per the above. we do have a backlog issue for the long-term fix tied to feature backlog.