Disabling component leads to AppWidgetProvider.onUpdate call [115575872]

Feature Request

Status Update

No update yet.

Description

ki...@gmail.com

created issue #1

Sep 13, 2018 11:26AM

Component used: android.arch.work:work-runtime
Version used: 1.0.0-alpha08
Devices/Android versions reproduced on: Pixel, and others

Steps:
1. Application with widget.
2. In AppWidgetProvider.onUpdate we schedule work.
3. After work ends WorkManager library disables
4. OS trigger AppWidgetProvider.onUpdate again.

And this will happen infinitely. So we unable to use WorkManager for widget updates.

See logs and sample project attached.

Знімок екрана о 14.24.32.png

200 KB

View

Download

WorkmanagerBug.zip

177 KB

Download

Comments

ki...@gmail.com <ki...@gmail.com> #2Sep 13, 2018 11:28AM

Not at the moment. But we have been asked this before, so I will treat this as a feature request.

az...@gmail.com <az...@gmail.com> #3Sep 13, 2018 11:39AM

OK thanks. At the moment I am just adding the name to the Data for the work request and retrieving it in startWork(), which works well enough.

ra...@google.com <ra...@google.com> Sep 19, 2018 11:33AM

Assigned to ra...@google.com.

ra...@google.com <ra...@google.com> #4Sep 19, 2018 05:44PM

Status: Won't Fix (Intended Behavior)

Thanks for the bug report.

PackageManager sends a PACKAGE_CHANGED broadcast whenever components are enabled and disabled. The component here is androidx.work.impl.background.systemalarm.RescheduleReceiver.

WorkManager is trying to be a good citizen here by disabling the receiver when there is no need for the receiver (whenever there is no more pending Work, we disable the Receiver).

AppWidgetServiceImpl in turn, registers a receiver for PACKAGE_CHANGED and subsequently calls updateProviderForPackageLocked() (

https://github.com/aosp-mirror/platform_frameworks_base/blob/master/services/appwidget/java/com/android/server/appwidget/AppWidgetServiceImpl.java#L419)
This is why your AppWidgetProvider's onUpdate() method is being called.

In your case, you should not unconditionally enqueue Workers when your onUpdate() method is called.
You should only enqueue workers for a specific Intent, when onEnabled() is called, or keep track of Workers that have been enqueued already. That way you will avoid having this issue.

ki...@gmail.com <ki...@gmail.com> #5Sep 20, 2018 09:13AM

I understand the cause, thanks.

What benefits gives us disabling component?

I feel breaking system functionality (ability to use WorkManager directly with widgets) is not good.

Also onEnabled is called only once and one AppWidgetProvider may handle many widgets. And system may call onUpdate for every widgetId in different time.

I think it still important to support system API even if we can workaround this problem.

ra...@google.com <ra...@google.com> #6Sep 20, 2018 05:15PM

Disabling the RescheduleReceiver makes it quicker when booting up the device, because otherwise your receivers have to be initialized and hence more work is being done.

WorkManager is not breaking any system functionality. You should be able to check if you have work enqueued already or use ExistingWorkPolicy.KEEP. Unconditionally enqueueing work in an onUpdate() is a bad idea.

[Deleted User] <[Deleted User]> #7Nov 16, 2018 03:59PM

If the work is already enqueued, then we wouldn't get the `onUpdate` callback. So if we're using work manager, we can't use `onUpdate` for any work because there's no extra information to determine whether this is from widget first being, widget needing an update because the update interval has passed, if the widget needs updating because a new version of the application has been installed, or if it's something we should ignore (e.g. `RescheduleReceiver` being removed).

So it seems we can't use work manager with widgets without resorting to hacks like an always queued worker that does nothing so that we never remove the rescheduler receiver.

su...@google.com <su...@google.com> #8Nov 16, 2018 07:02PM

As #6 states, unconditionally enqueuing work in onUpdate() seems like a bad idea given the behavior of that API and when it's called. I wouldn't put your hacks in the WorkManager part of the code - it makes much more sense to have a local cache of data for the widget and conditionally/periodically update that and have the AppWidgetProvider#onUpdate() reference that data.

[Deleted User] <[Deleted User]> #9Nov 20, 2018 11:55AM

The original intention for using work manager inside onUpdate was to avoid the use of services - as we have to make them foreground service on 8.0+ but they can still throw "did not call startForeground within 5 seconds". So the above approach of having a periodic job update a local cache and letting onUpdate render that data is fine, but it defeats the point of why we wanted to use work manager in the first place (as the provider will have to start a service to update still)

su...@google.com <su...@google.com> #10Nov 20, 2018 05:58PM

The problem you are encountering is not unique to WorkManager. Anything that enables or disables components in your app will trigger an AppWidgetProvider#onUpdate. You have to handle this in the general case anyway - this is why we're suggesting that your current approach is flawed.

Why don't you enqueue a periodic job in AppWidgetProvider#onEnabled and stop it in AppWidgetProvider#onDeleted?

ki...@gmail.com <ki...@gmail.com> #11Nov 20, 2018 07:01PM

Yes, enabling/disabling components will trigger onUpdate. But does not create a loop onUpdate -> schedule -> job finished -> onUpdate -> ...

Just for information: ExistingWorkPolicy.KEEP cannot be used in this case. We have to use REPLACE. Because "onUpdate" can be also called when new widget was added to screen and when application was updated. In this case widget on the screen is empty and we cannot wait when job that was scheduled previously will be executed. So REPLACE is the answer to reschedule job and execute as soon as possible. In this case job will be scheduled forever (component will be enabled) and executed every time onUpdate called (because of REPLACE).

Doesn't looks like good workaround to me.

su...@google.com <su...@google.com> #12Nov 20, 2018 07:36PM

In general, there's very little room for change here - the platform functionality really can't be changed, and if WorkManager doesn't do the enable/disable dance with its receivers, you will have a negative battery impact. So let's see if we can find a good workaround.

onUpdate gives you an array of widget ids that need updating. Would you be able to schedule a KEEP job with a name that includes the widget identifier? Something like:

onUpdate(context, appWidgetManager, appWidgetIds) {
for (id : appWidgetIds) {
workManager.enqueueUniquePeriodicWork("widgetwork" + id, KEEP, workRequest);
}
}

ki...@gmail.com <ki...@gmail.com> #13Nov 20, 2018 07:46PM

No, only KEEP is not possible here. After application update widgets had to be updated immediately. Because right after application update "android:initialLayout" is inflated into widget and onUpdate called.

In this case we need track application build number and use either KEEP or REPLACE.

Are you sure that battery impact will significant? There are a lot of libraries (analytics/crash reporting, etc.) which has a lot of components (services, providers, receivers) which does not disable their components.

ra...@google.com <ra...@google.com> #14Nov 20, 2018 08:39PM

I think the Widget could just keep track of when the last time it enqueued a WorkRequest, and check if something needs to be done again.
You could track it using a field in your Widget implementation. Alternatively, you could also use a dedicated Intent - as a signal if something was needed to be done.

Unconditionally calling enqueue() on onUpdate() is a bad idea.

er...@googlemail.com <er...@googlemail.com> #15Jan 8, 2020 05:56PM

Struggling with the same issue. This is a major blocker for updating my app > Android 8.

ra...@google.com <ra...@google.com> #16Jan 8, 2020 06:12PM

One other thing you could do is to schedule another WorkRequest really far out into the future. So, you could create a OneTimeWorkRequest with an initial delay of 10 years.

That way there is always at least one outstanding request, and therefore WM don't disable the RescheduleReceiver.

er...@googlemail.com <er...@googlemail.com> #17Jan 8, 2020 06:15PM

To my understanding you cannot (easily) identify whether something has to be done or not. Even if my data hasn't changed, it could be that the widget needs an update (due to some re-layouting of the launcher etc. etc.). You, within onUpdate() you cannot really judge where the widget really has to be UPDATED or not. And therefore you will end up in the infinite loop of updating - or miss the updates which displays the widget in its initial (empty) state.

lb...@gmail.com <lb...@gmail.com> #18Feb 16, 2021 10:46PM

@16
Similar issue, but this time the Worker is the one that I tell it to update the app-widget, and it causes it to be done twice instead of once:

https://issuetracker.google.com/issues/180436098

If anyone knows of a way to overcome it, please let me know.

lb...@gmail.com <lb...@gmail.com> #19Feb 17, 2021 01:55AM

Google this is clearly a bug.
It started on API 29. Didn't occur before. Not documented. Not expected at all. Why should WorkManager affect AppWidget in any way? Why would the appWidget get updated just because there are no more scheduled tasks for the WorkManager?
Only when I do the appWidget update, it should be done. Not by some library of Google that decides that it got nothing to do, so it updates all appWidgets...

This is a library. It should be fixed.

dm...@gmail.com <dm...@gmail.com> #20Sep 13, 2021 01:28PM

If it is "Intended behavior", could you please at least document it?
Though it's obviously a bug.
No matter what your intentions are, WorkManager can't trigger side effects in an absolutely unrelated component.
Even if you are not using WorkManager to update a Widget, it will still trigger an update of all your Widgets.

dm...@gmail.com <dm...@gmail.com> #21Sep 13, 2021 01:32PM

Comment has been deleted.

Message last modified on Sep 13, 2021 01:34PM

st...@gmail.com <st...@gmail.com> #22Jan 10, 2022 07:52PM

Please at least document this behavior in the 'Create a simple widget' guide (https://developer.android.com/guide/topics/appwidgets). There's a Note block that suggests the use of WorkManager in the onUpdate method

Note: Because AppWidgetProvider is an extension of BroadcastReceiver, your process is not guaranteed to keep running after the callback methods return (see BroadcastReceiver for information about the broadcast lifecycle). If your widget setup process can take several seconds (perhaps while performing web requests) and you require that your process continues, consider starting a Task using WorkManager in the onUpdate() method. From within the task, you can perform your own updates to the widget without worrying about the AppWidgetProvider closing down due to an Application Not Responding (ANR) error.

sz...@gmail.com <sz...@gmail.com> #23Jan 27, 2022 09:42AM

Nonsense

ma...@gmail.com <ma...@gmail.com> #24Jan 31, 2022 08:49PM

I've started to see this issue from a WorkManager outside of the widget provider class. We have a OneTimeWorkRequest that is scheduled during different app lifecycle events. This is causing our widgets to continue to update.

to...@gmail.com <to...@gmail.com> #25Mar 11, 2022 11:41AM

Is there official example from Google how to update widgets from Work Manager?

If official suggestion is

If your widget setup process can take several seconds (perhaps while performing web requests) and you require that your process continues, consider starting a Task using WorkManager in the onUpdate() method. From within the task, you can perform your own updates to the widget without worrying about the AppWidgetProvider closing down due to an Application Not Responding (ANR) error.

then Google should provide example how to do that properly. Most of the suggestions (task with initial delay 10 years to disable RescheduleReceiver) above are hacks.

Since Foregrounds services can't be started from background since Android 12, more and more developers confused with official guide will meet this "intended behavior" of Work Manager and spend useless time trying to figure out what causes infinite loop of update of widget content.

va...@gmail.com <va...@gmail.com> #26Mar 11, 2022 04:03PM

#25

For periodic updates, just schedule a work when widget instance is added (onEnabled etc) and for any on-demand update, hook any click action to launching additional work requests. Latest version of WorkManager even supports immediate request, foreground notifications etc.

Note, do not hook work requests directly from onUpdate, it would just be a recursive infinite logic.

st...@gmail.com <st...@gmail.com> #27Mar 11, 2022 05:23PM

#26, where are we supposed to get appWidgetIds: IntArray that RemoteViews require other than in the onUpdate? As I understand it, only system knows the individual ids of every particular widget. Can you please provide an example of scheduling WorkManager's periodic task from onEnabled?

ra...@google.com <ra...@google.com> #28Mar 15, 2022 04:50PM

Status: Assigned (reopened)

We want to better support AppWidgets in WorkManager. Stay tuned for updates here.

lb...@gmail.com <lb...@gmail.com> #29Mar 15, 2022 04:59PM

@28 For now I use the workaround you've suggested, and added it to my own small repository of common utils :

https://github.com/AndroidDeveloperLB/CommonUtils

The class I use there is WorkerManagerUtils, if anyone wishes to use it.

va...@gmail.com <va...@gmail.com> #30Mar 16, 2022 12:34AM

#27, We had a logic to update all widget instances from background work via AppWidgetManager#getAppWidgetIds. Glance too has nice APIs on top of that.
Anyways, it seems like Google is adding better support from WorkManager as indicated in #28.

lb...@gmail.com <lb...@gmail.com> #31Mar 16, 2022 12:47AM

@30 What do you mean? What other solution is there?
And how would Google make things better?

va...@gmail.com <va...@gmail.com> #32Mar 16, 2022 12:49AM

#31, meant this future proposed plan.

"We want to better support AppWidgets in WorkManager. Stay tuned for updates here."

lb...@gmail.com <lb...@gmail.com> #33Mar 16, 2022 12:53AM

@32 OK I thought you know more details. Sorry

[Deleted User] <[Deleted User]> #34Mar 18, 2022 07:10AM

same here

https://issuetracker.google.com/issues/224824112

v....@gmail.com <v....@gmail.com> #35Jun 8, 2022 10:40PM

What I noticed is this doesnt happen with non-uniqueue, i.e. enqueueWork

dj...@gmail.com <dj...@gmail.com> #36Aug 11, 2022 03:24PM

Any news about this issue?

ap...@google.com <ap...@google.com> #37Apr 3, 2023 10:53PM

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

commit 047f000bc31a6f08bc2907dcf4f47c8712c56f68
Author: Shamali P <shamalip@google.com>
Date: Mon Apr 03 21:10:51 2023

Temporarily override onProviderChanged to do nothing to avoid any noise in between the test.

Per our investigation locally, work manager is causing PACKAGE_CHANGE and in turn causing this to be invoked that resets the widget with "null". Pretty much like

b/115575872

that happens on first worker being enqueued.

Will improve it in follow up (but to unblock flaky tests, sending this ahead).

Bug: 270621933
Test: Tested on cuttlefish and acid emulators
Change-Id: I3e6c5c7c5b71f0a188a4be1c87ce6c84cab480f7

M glance/glance-appwidget/src/androidAndroidTest/kotlin/androidx/glance/appwidget/AppWidgetHostTestActivity.kt

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

lb...@gmail.com <lb...@gmail.com> #38Apr 3, 2023 11:39PM

@37 Will your solution fix it on WorkManager, on Android, or both?
What's the best workaround for now?

sh...@google.com <sh...@google.com> #39May 11, 2023 10:24PM

Just came across this, #37 it is not related to this bug - donno how it ended up showing here. Please ignore it.

lb...@gmail.com <lb...@gmail.com> #40May 11, 2023 11:52PM

@39 Delete it, then. It shows your email...

ta...@getnomad.app <ta...@getnomad.app> #41Dec 19, 2023 04:08AM

Comment has been deleted.

Message last modified on Dec 19, 2023 07:22AM

dr...@gmail.com <dr...@gmail.com> #42Oct 5, 2024 09:12AM

Eeeewww... just got hit by this one. Reaallly horrible and unexpected that WorkManager can have an effect on AppWidgetProvider in this way.

Thing is, I've only been affected by this from WM 2.10.0-alpha02 onwards... the exact same code works fine with WM 2.10.0-alpha01 and before. I don't schedule work in onUpdate() unconditionally, and so far as I can see from initial investigations I'm not scheduling work in onUpdate() when I'm hit by this problem, so I'm not yet sure why I'm hit by this at all, and why only since WM 2.10.0-alpha02, but from then on I notice an extra trigger of onUpdate() that doesn't happen in prior versions of WM, and it's this extra trigger of onUpdate() which is causing me problems.

With the workaround suggested here, all my problems go away for WM 2.10.0-alpha02 onwards.

EDIT... I should clarify that I'm not seeing an infinite loop, probably because I'm not scheduling work unconditionally in onUpdate() (though in the past I have seen this behaviour, presumably when I was scheduling work unconditionally in onUpdate()).

Instead, what I'm seeing is that onUpdate() is triggered for a second time, part way through dealing with the first onUpdate() trigger (during which I initialise the widget, which includes fetching data for display in the widget). And this second trigger seems to interfere with the widget initialisation, even though I'm not responding to it.

Here are some excerpts from the log for WM 2.10.0-alpha01 (filtered WM- but also showing when onReceive and onUpdate are called in my AppWidgetProvider):

2024-09-30 19:56:06.983 31005-31005 MyAppWidgetProvider     D  onReceive
2024-09-30 19:56:06.983 31005-31005 MyAppWidgetProvider     D  onUpdate
2024-09-30 19:56:10.960 31005-31515 WM-PackageManagerHelper D  Skipping component enablement for androidx.work.impl.background.systemalarm.RescheduleReceiver
2024-09-30 19:56:10.978 31005-31515 WM-SystemJobScheduler   D  Scheduling work ID d3e31f0d-849e-478a-8c42-98e2cff32c85Job ID 8
2024-09-30 19:56:10.989 31005-31515 WM-GreedyScheduler      D  Starting tracking for d3e31f0d-849e-478a-8c42-98e2cff32c85
2024-09-30 19:56:10.996 31005-31515 WM-PackageManagerHelper D  Skipping component enablement for androidx.work.impl.background.systemalarm.RescheduleReceiver
2024-09-30 19:56:11.001 31005-31515 WM-SystemJobScheduler   D  Scheduling work ID 36ce22ba-b795-4f25-b558-8326ffa9589bJob ID 9
2024-09-30 19:56:11.002 31005-31515 WM-GreedyScheduler      D  Starting tracking for d3e31f0d-849e-478a-8c42-98e2cff32c85
2024-09-30 19:56:11.011 31005-31515 WM-ConstraintTracker    D  NetworkStateTracker24: initial state = NetworkState(isConnected=true, isValidated=true, isMetered=false, isNotRoaming=true)
2024-09-30 19:56:11.011 31005-31515 WM-NetworkStateTracker  D  Registering network callback
2024-09-30 19:56:11.014 31005-31515 WM-GreedyScheduler      D  Constraints met: Scheduling work ID WorkGenerationalId(workSpecId=d3e31f0d-849e-478a-8c42-98e2cff32c85, generation=0)
2024-09-30 19:56:11.017 31005-31518 WM-NetworkStateTracker  D  Network capabilities changed: [ Transports: WIFI Capabilities: NOT_METERED&INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VPN&VALIDATED&NOT_ROAMING&FOREGROUND&NOT_CONGESTED&NOT_SUSPENDED&NOT_VCN_MANAGED LinkUpBandwidth>=7869Kbps LinkDnBandwidth>=67913Kbps TransportInfo: <SSID: <unknown ssid>, BSSID: 02:00:00:00:00:00, MAC: 02:00:00:00:00:00, Security type: 2, Supplicant state: COMPLETED, Wi-Fi standard: 5, RSSI: -65, Link speed: 325Mbps, Tx Link speed: 325Mbps, Max Supported Tx Link speed: 866Mbps, Rx Link speed: 526Mbps, Max Supported Rx Link speed: 866Mbps, Frequency: 5180MHz, Net ID: -1, Metered hint: false, score: 60, CarrierMerged: false, SubscriptionId: -1, IsPrimary: -1> SignalStrength: -65]
2024-09-30 19:56:11.017 31005-31515 WM-Processor            D  Processor: processing WorkGenerationalId(workSpecId=d3e31f0d-849e-478a-8c42-98e2cff32c85, generation=0)
2024-09-30 19:56:11.024 31005-31005 WM-SystemJobService     D  onStartJob for WorkGenerationalId(workSpecId=d3e31f0d-849e-478a-8c42-98e2cff32c85, generation=0)
2024-09-30 19:56:11.031 31005-31516 WM-Processor            D  Work WorkGenerationalId(workSpecId=d3e31f0d-849e-478a-8c42-98e2cff32c85, generation=0) is already enqueued for processing
2024-09-30 19:56:11.032 31005-31005 WM-WorkerWrapper        D  Starting work for com.example.myapp.MyWorker
2024-09-30 19:56:14.718 31005-31517 WM-WorkerWrapper        D  com.example.myapp.MyWorker returned a Success {mOutputData=Data {}}.
2024-09-30 19:56:14.724 31005-31517 WM-WorkerWrapper        I  Worker result SUCCESS for Work [ id=d3e31f0d-849e-478a-8c42-98e2cff32c85, tags={ com.example.myapp.MyWorker,widget:199,cycle:0,name:b2d9a06d,type:onetime,trigger:config_activity,network:connected,version:1867,reference:0 } ]
2024-09-30 19:56:14.740 31005-31005 WM-Processor            D  Processor d3e31f0d-849e-478a-8c42-98e2cff32c85 executed; reschedule = false
2024-09-30 19:56:14.740 31005-31005 WM-GreedyScheduler      D  Stopping tracking for WorkGenerationalId(workSpecId=d3e31f0d-849e-478a-8c42-98e2cff32c85, generation=0)
2024-09-30 19:56:14.742 31005-31005 WM-SystemJobService     D  d3e31f0d-849e-478a-8c42-98e2cff32c85 executed on JobScheduler
2024-09-30 19:56:14.746 31005-31513 WM-GreedyScheduler      D  Cancelling work ID d3e31f0d-849e-478a-8c42-98e2cff32c85
2024-09-30 19:56:14.749 31005-31513 WM-NetworkStateTracker  D  Unregistering network callback
2024-09-30 19:56:14.751 31005-31005 WM-SystemJobService     D  onStopJob for WorkGenerationalId(workSpecId=d3e31f0d-849e-478a-8c42-98e2cff32c85, generation=0)

There is only one call to onUpdate. At the start of this log, I am adding the first widget to the homescreen, and saving from the config activity... I schedule two works: one is periodic (for ongoing widget updates) and the other as onetime (for the immediate widget update).

Here are the same logs for WM 2.10.0-alpha02 onwards:

2024-09-30 19:58:21.309 32660-32660 MyAppWidgetProvider     D  onReceive
2024-09-30 19:58:21.309 32660-32660 MyAppWidgetProvider     D  onUpdate
2024-09-30 19:58:25.767 32660-870   WM-SystemJobScheduler   D  Scheduling work ID dcef9a49-2e84-40f9-bf84-1f3b12a5c47cJob ID 12
2024-09-30 19:58:25.775 32660-870   WM-GreedyScheduler      D  Starting tracking for dcef9a49-2e84-40f9-bf84-1f3b12a5c47c
2024-09-30 19:58:25.789 32660-870   WM-SystemJobScheduler   D  Scheduling work ID 15aa8e86-eae0-4b9c-901f-6403f6c6ac5bJob ID 13
2024-09-30 19:58:25.791 32660-870   WM-GreedyScheduler      D  Starting tracking for dcef9a49-2e84-40f9-bf84-1f3b12a5c47c
2024-09-30 19:58:25.801 32660-870   WM-ConstraintTracker    D  NetworkStateTracker24: initial state = NetworkState(isConnected=true, isValidated=true, isMetered=false, isNotRoaming=true)
2024-09-30 19:58:25.801 32660-870   WM-NetworkStateTracker  D  Registering network callback
2024-09-30 19:58:25.803 32660-32660 WM-SystemJobService     D  onStartJob for WorkGenerationalId(workSpecId=dcef9a49-2e84-40f9-bf84-1f3b12a5c47c, generation=0)
2024-09-30 19:58:25.807 32660-956   WM-NetworkStateTracker  D  Network capabilities changed: [ Transports: WIFI Capabilities: NOT_METERED&INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VPN&VALIDATED&NOT_ROAMING&FOREGROUND&NOT_CONGESTED&NOT_SUSPENDED&NOT_VCN_MANAGED LinkUpBandwidth>=7869Kbps LinkDnBandwidth>=67913Kbps TransportInfo: <SSID: <unknown ssid>, BSSID: 02:00:00:00:00:00, MAC: 02:00:00:00:00:00, Security type: 2, Supplicant state: COMPLETED, Wi-Fi standard: 5, RSSI: -67, Link speed: 325Mbps, Tx Link speed: 325Mbps, Max Supported Tx Link speed: 866Mbps, Rx Link speed: 526Mbps, Max Supported Rx Link speed: 866Mbps, Frequency: 5180MHz, Net ID: -1, Metered hint: false, score: 60, CarrierMerged: false, SubscriptionId: -1, IsPrimary: -1> SignalStrength: -67]
2024-09-30 19:58:25.810 32660-895   WM-PackageManagerHelper D  androidx.work.impl.background.systemalarm.RescheduleReceiver enabled
2024-09-30 19:58:25.818 32660-895   WM-Processor            D  Processor: processing WorkGenerationalId(workSpecId=dcef9a49-2e84-40f9-bf84-1f3b12a5c47c, generation=0)
2024-09-30 19:58:25.839 32660-32660 WM-WorkerWrapper        D  Starting work for com.example.myapp.MyWorker
2024-09-30 19:58:25.841 32660-870   WM-GreedyScheduler      D  Constraints met: Scheduling work ID WorkGenerationalId(workSpecId=dcef9a49-2e84-40f9-bf84-1f3b12a5c47c, generation=0)
2024-09-30 19:58:25.849 32660-870   WM-Processor            D  Work WorkGenerationalId(workSpecId=dcef9a49-2e84-40f9-bf84-1f3b12a5c47c, generation=0) is already enqueued for processing
2024-09-30 19:58:26.889 32660-32660 MyAppWidgetProvider     D  onReceive
2024-09-30 19:58:26.890 32660-32660 MyAppWidgetProvider     D  onUpdate
2024-09-30 19:58:26.902 32660-32660 MyAppWidgetProvider     D  not re-scheduling periodic work for widget 200... doNotRescheduleOnUpdate was set to true
2024-09-30 19:58:29.196 32660-903   WM-WorkerWrapper        I  Worker result SUCCESS for Work [ id=dcef9a49-2e84-40f9-bf84-1f3b12a5c47c, tags={ com.example.myapp.MyWorker,widget:200,cycle:0,name:e5bd4606,type:onetime,trigger:config_activity,network:connected,version:1867,reference:0 } ]
2024-09-30 19:58:29.204 32660-32660 WM-Processor            D  Processor dcef9a49-2e84-40f9-bf84-1f3b12a5c47c executed; reschedule = false
2024-09-30 19:58:29.204 32660-32660 WM-GreedyScheduler      D  Stopping tracking for WorkGenerationalId(workSpecId=dcef9a49-2e84-40f9-bf84-1f3b12a5c47c, generation=0)
2024-09-30 19:58:29.205 32660-32660 WM-SystemJobService     D  dcef9a49-2e84-40f9-bf84-1f3b12a5c47c executed on JobScheduler
2024-09-30 19:58:29.209 32660-903   WM-GreedyScheduler      D  Cancelling work ID dcef9a49-2e84-40f9-bf84-1f3b12a5c47c
2024-09-30 19:58:29.212 32660-903   WM-NetworkStateTracker  D  Unregistering network callback

What strikes me is that in the former, RescheduleReceiver is not enabled (it is skipped):

WM-PackageManagerHelper D  Skipping component enablement for androidx.work.impl.background.systemalarm.RescheduleReceiver

While in the latter it is enabled:

WM-PackageManagerHelper D  androidx.work.impl.background.systemalarm.RescheduleReceiver enabled

I guess that's what triggers the second onUpdate in the latter. It's not clear to me why this has changed. Although it seems to me that this is now the correct behaviour (even if it's unexpected behaviour to many/most), since this is the first work being scheduled, so it should be enabling the RescheduleReceiver?

Although it's a pain in the neck because in this case we're always going to get a double trigger of onUpdate when adding the first widget and setting up the first work via WorkManager?

What is still confusing me is why the second trigger of onUpdate messes up the initialistion of my widget (it is left in an unresponsive state, which didn't happen in earlier versions), when I'm not reacting to it, but that's likely off topic.

Message last modified on Oct 6, 2024 09:13AM

is...@google.com <is...@google.com> Oct 7, 2024 09:05AM

Status: New

yu...@google.com <yu...@google.com> #43Oct 7, 2024 03:21PM

@dr...@gmail.com can you repro the issue and record a bug report? Please attach it to the bug.

Also, can you please verify that the issue is only happening on 2.10.0-alpha02 and not 2.10.0-alpha01?

dr...@gmail.com <dr...@gmail.com> #44Oct 7, 2024 08:24PM

yu...@google.com I can't seem to repro the 2.10.0-alpha02 vs 2.10.0-alpha01 issue that is apparent in my actual app... it's really frustrating. In my attempted repro, it's the same behaviour as for the latest 2.10.0-beta01... i.e. RescheduleReceiver is being enabled when scheduling the first work, triggering onUpdate again... which I think is "expected behaviour" even if it's not very "nice behaviour". I think this is part of the issue... when one component has an effect on another unrelated component, it feels like there are hidden forces acting that aren't entirely transparent to the developer.

Message last modified on Oct 7, 2024 08:32PM

lb...@gmail.com <lb...@gmail.com> #45Oct 7, 2024 10:25PM

Comment has been deleted.

Message last modified on Oct 7, 2024 10:27PM

lb...@gmail.com <lb...@gmail.com> #46Oct 7, 2024 10:35PM

@43 I can still reproduce the issue that you've marked as duplicate to the current one...

https://issuetracker.google.com/issues/180436098#comment8

Please try the sample I've provided there, and the steps I've shown on video:

Put the app widget.
Test that it works fine using the button of background-thread, as it increases the counter each time.
Now test using the other button, of using a Worker to update the widget, which causes an update twice (bug).

Also please fix Android Studio itself. Doesn't make sense that a project that was created just 3 years ago can't be opened normally. It didn't even give me a proper message of what's wrong and how to fix. I had to create a new project and copy the code to there. Android Studio always had serious backward compatibility issues.

At least you didn't remove my files from there as you often do.

Message last modified on Oct 7, 2024 10:36PM

dr...@gmail.com <dr...@gmail.com> #47Oct 8, 2024 08:26AM

#46 I don't think that anyone is denying that this unwanted/unexpected triggering of onUpdate() happens (it is well explained by commonsware here), it's just a question of whether the library maintainers consider this to be logical and acceptable behaviour. This particular issuetracker issue is entitled "Disabling component leads to AppWidgetProvider.onUpdate call" but of course this also happens when the component is enabled (when the first work is scheduled). This for me is more problematic than what happens when the component is disabled. It's not problematic in the sense that I can't deal with it, now that I understand what is going on, but it just seems so unnecessary to put the burden on the developer to put in extra checks or hacky workarounds to ensure that we don't react to the onUpdate() that is triggered just by scheduling a work with WorkManager.

It is completely illogical that merely scheduling a work (any work) should trigger your widgets to update (any widgets, even completely unrelated to the scheduled work). Because it is illogical, it is surely unexpected (to the user of the library)? Sure, with the help of the explanation from commonsware (and others) we can understand the underlying mechanisms and why this happens, but it's still difficult to comprehend why it makes any sense for there to be this causal link between WorkManager and AppWidgetProvider.

I struggle to believe that having the RescheduleReceiver always registered to listen for ACTION_BOOT_COMPLETED (even when there is no work to deal with on a reboot) will really impact battery life in a meaningful way (see #12)... how much extra battery will it really use for the RescheduleReceiver to do its stuff after a reboot, particularly if it can quickly figure out that there is no work to reschedule? And it's not as if the device is rebooting every 5 minutes anyway, so if there is a tiny increase in battery usage it only happens once in a while. I would expect that many developers will in any case just take the easy route and put in the hacky workaround (to schedule a "keep alive" work to avoid any unwanted triggering), so this will be happening anyway... why not at least make it an option in the API (even if the default is the current behaviour)?

The alternative is to create some logic in onUpdate() to determine (or guess) whether or not we should be reacting to it... but how do we really know (as said in #17)... so far as I understand it's not possible to determine why the onUpdate() was triggered... if we know for sure that it's in response to PACKAGE_CHANGED then perhaps we can ignore it... but we can't... and how else do we know whether this is a critical request from the launcher asking widgets to update themselves (because otherwise they will be left in an unconfigured state) or whether it is just an unwanted trigger resulting from having just scheduled a work with WorkManager? Just because the update happens within 10 ms of scheduling a work doesn't mean that WorkManager actually caused it... we can't really make that assumption?

Hence the only sure way of dealing with this is to implement the hacky workaround of #16, as suggested by the library maintainer. So why not just make this the default, or provide an option?

Message last modified on Oct 8, 2024 08:41AM

lb...@gmail.com <lb...@gmail.com> #48Oct 8, 2024 08:49AM

@47 It's not on the first work alone. It's on all. Also, I can't think of any reason that this library should affect app-widgets . They are not related at all.

dr...@gmail.com <dr...@gmail.com> #49Oct 8, 2024 09:00AM

#48 yes, true. In my case I'm always enqueuing a periodic work (to update the widget on an ongoing basis), and once there is at least one periodic work enqueued then there will be no more unwanted triggering of onUpdate() by WorkManager flip-flopping the RescheduleReceiver on and off... so for me it's the "first work" but yes you have a point.

(And BTW I also agree with your gripe about it being really difficult to open up a project in Android Studio from even a couple of years ago... I too am met with a whole ton of strange error messages that are difficult to decipher and even more difficult to know how to overcome... I thought it was just me.)

Message last modified on Oct 8, 2024 09:02AM

Issue 115575872

Description

Issue summary

Comments

ki...@gmail.com <ki...@gmail.com> #2Sep 13, 2018 11:28AM

az...@gmail.com <az...@gmail.com> #3Sep 13, 2018 11:39AM

ra...@google.com <ra...@google.com> Sep 19, 2018 11:33AM

ra...@google.com <ra...@google.com> #4Sep 19, 2018 05:44PM

ki...@gmail.com <ki...@gmail.com> #5Sep 20, 2018 09:13AM

ra...@google.com <ra...@google.com> #6Sep 20, 2018 05:15PM

[Deleted User] <[Deleted User]> #7Nov 16, 2018 03:59PM

su...@google.com <su...@google.com> #8Nov 16, 2018 07:02PM

[Deleted User] <[Deleted User]> #9Nov 20, 2018 11:55AM

su...@google.com <su...@google.com> #10Nov 20, 2018 05:58PM

ki...@gmail.com <ki...@gmail.com> #11Nov 20, 2018 07:01PM

su...@google.com <su...@google.com> #12Nov 20, 2018 07:36PM

ki...@gmail.com <ki...@gmail.com> #13Nov 20, 2018 07:46PM

ra...@google.com <ra...@google.com> #14Nov 20, 2018 08:39PM

er...@googlemail.com <er...@googlemail.com> #15Jan 8, 2020 05:56PM

ra...@google.com <ra...@google.com> #16Jan 8, 2020 06:12PM

er...@googlemail.com <er...@googlemail.com> #17Jan 8, 2020 06:15PM

lb...@gmail.com <lb...@gmail.com> #18Feb 16, 2021 10:46PM

lb...@gmail.com <lb...@gmail.com> #19Feb 17, 2021 01:55AM

dm...@gmail.com <dm...@gmail.com> #20Sep 13, 2021 01:28PM

dm...@gmail.com <dm...@gmail.com> #21Sep 13, 2021 01:32PM

st...@gmail.com <st...@gmail.com> #22Jan 10, 2022 07:52PM

sz...@gmail.com <sz...@gmail.com> #23Jan 27, 2022 09:42AM

ma...@gmail.com <ma...@gmail.com> #24Jan 31, 2022 08:49PM

to...@gmail.com <to...@gmail.com> #25Mar 11, 2022 11:41AM

va...@gmail.com <va...@gmail.com> #26Mar 11, 2022 04:03PM

st...@gmail.com <st...@gmail.com> #27Mar 11, 2022 05:23PM

ra...@google.com <ra...@google.com> #28Mar 15, 2022 04:50PM

lb...@gmail.com <lb...@gmail.com> #29Mar 15, 2022 04:59PM

va...@gmail.com <va...@gmail.com> #30Mar 16, 2022 12:34AM

lb...@gmail.com <lb...@gmail.com> #31Mar 16, 2022 12:47AM

va...@gmail.com <va...@gmail.com> #32Mar 16, 2022 12:49AM

lb...@gmail.com <lb...@gmail.com> #33Mar 16, 2022 12:53AM

[Deleted User] <[Deleted User]> #34Mar 18, 2022 07:10AM

v....@gmail.com <v....@gmail.com> #35Jun 8, 2022 10:40PM

dj...@gmail.com <dj...@gmail.com> #36Aug 11, 2022 03:24PM

ap...@google.com <ap...@google.com> #37Apr 3, 2023 10:53PM

lb...@gmail.com <lb...@gmail.com> #38Apr 3, 2023 11:39PM

sh...@google.com <sh...@google.com> #39May 11, 2023 10:24PM

lb...@gmail.com <lb...@gmail.com> #40May 11, 2023 11:52PM

ta...@getnomad.app <ta...@getnomad.app> #41Dec 19, 2023 04:08AM

dr...@gmail.com <dr...@gmail.com> #42Oct 5, 2024 09:12AM

is...@google.com <is...@google.com> Oct 7, 2024 09:05AM

yu...@google.com <yu...@google.com> #43Oct 7, 2024 03:21PM

dr...@gmail.com <dr...@gmail.com> #44Oct 7, 2024 08:24PM

lb...@gmail.com <lb...@gmail.com> #45Oct 7, 2024 10:25PM

lb...@gmail.com <lb...@gmail.com> #46Oct 7, 2024 10:35PM

dr...@gmail.com <dr...@gmail.com> #47Oct 8, 2024 08:26AM

lb...@gmail.com <lb...@gmail.com> #48Oct 8, 2024 08:49AM

dr...@gmail.com <dr...@gmail.com> #49Oct 8, 2024 09:00AM

Add comment

Issue metadata