Widget is updating frequently after OneSignal initialization

[GGFicht]

Description: Without OneSignal SDK, widgets usually take a bit of time to update (minimum 30 min) controlled by SO to avoid too much battery consumption. By adding a widget to a project together with OneSignal it is observed that the widget callback is being called with a high frequency.

Environment App gradle dependency: "com.onesignal:OneSignal:[4.0.0, 4.99.99]" Build.gradle plugin: "gradle.plugin.com.onesignal:onesignal-gradle-plugin:[0.12.10, 0.99.99]"

Steps to Reproduce Issue:

1. Add a widget to your project
2. Add the OneSignal SDK to your project
3. Init OneSignal SDK in Application class

The widget will start being updated with a higher frequency than normal.

Anything else:

I created this repository for easier reproduction of this issue: https://github.com/GGFicht/widget-onesignal-auto-update/tree/main

I recommend cloning the above project and following the readme.txt.

If not possible to clone, here is a log, I replaced the project id keys to the string: "PROJECT-ID". logs.txt

[jkasten2]

@GGFicht Thanks for reporting with a example project! Not sure off hand why OneSignal would change the update frequency of a widget. Can you provide a few more details?

1. You noted "high frequency", what user actions trigger the onUpdate call? Or is it just x amount of time?
2. What Android version(s) have you tested and noticed this issue?
3. Any differences in device model or Android Launchers?

[GGFicht]

@jkasten2 Thanks for the response. Sure, I'm happy to provide any extra details needed.

1 - I noticed that when opening/ minimizing the application the onUpdate call is triggered, usually twice. 2 - I tested in Android 10 and 11. With a Samsung Galaxy A10, Xiaomi Redmi and an android emulator. 3 - No, all tested devices showed the same behavior.

[Vitor-Bukovitz]

@jkasten2 Any updates on this issue? Happening for me as well.

[AlexanderPh]

Hello everyone! @jkasten2 Any updates on this issue? Faced a similar problem.

[jkasten2]

Could you capture a stack trace when the widget's onUpdate gets call? Hoping this trace will include a OneSignal method that shows the root cause of the refresh.

If the above is not true, then the next steps would be to bisect the operations the OneSignal SDK does and try to uncover the root cause through process of elimination. If you open the OneSignalSDK folder in this repo in Android Studio you will be presented with an example project that you can add a widget to and modify the OneSignal SDK directly to hunt down the root cause.

[flowerasny]

Hello!

I have the same issue, Is there any update or workaround?

[flowerasny]

@kesheshyan @jkasten2 is there any chance for a fix?

[olegk00]

Hi, are there any updates on this issue from the OneSignal team?

[brismithers]

It looks like this is an "intended behavior" with the androidx.work library (i.e. WorkManager) that is used by the OneSignal SDK. That issue is being tracked here.

To summarize:

1. OneSignal will schedule work via WorkManager for various asynchronous tasks within the SDK.
2. WorkManager will disable their receiver androidx.work.impl.background.systemalarm.RescheduleReceiver when it isn't needed.
3. The disabling of a component drives a call to the widget's onUpdate to be called.

Roughly, scheduling work = a call to onUpdate

Unfortunately the OneSignal SDK relies pretty heavily on WorkManager. As a workaround, a suggestion is to schedule a "dummy" work via WorkManager with an initial delay of 10 years, example code below.

    override fun onCreate() {
        super.onCreate()

        val workRequest = OneTimeWorkRequest.Builder(DummyWorker::class.java)
            .setInitialDelay(3650, TimeUnit.DAYS)
            .build()

        WorkManager.getInstance(applicationContext)
            .enqueueUniqueWork(
                "XXXXX",
                ExistingWorkPolicy.REPLACE,
                workRequest
            )
    }

    class DummyWorker(context: Context, workerParams: WorkerParameters) : Worker(context, workerParams) {
        override fun doWork(): Result {
            return Result.success()
        }
    }

We'll look into updating our SDK to do something like above. Hope this helps!

[RuslanPopenko]

Hello @brismithers ! Do you have an update on this issue? Have you fixed it in the latest versions? Thank you

[jkasten2]

@RuslanPopenko looking at Google's 115575872 issue it looks like there hasn't been any progress on them resolving it on their end.

We are considering adding the work around noted above, however we need to carefully consider if this will create any side effects in any app. I recommend you try the work around above in your app, however I also highly recommend you test to ensure it doesn't create any issues with your app.