IssueTracker

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

commit 93dc6213fe2e74aa9c9d3dcdb4551c6ad3a85ba4
Author: sanura <sanura@google.com>
Date:   Thu Mar 16 01:59:33 2023

    Add private initViewTreeOwners() to AppCompatDialog
   
    Ensure that AppCompatDialog also sets initial view
    tree owners, since it does not call through to
    super.setContentView(), which would set them via
    ComponentDialog.
   
    RelNote: "`AppCompatDialog` now correctly sets the `LifecycleOwner`, `SavedStateRegistryOwner`, and `OnBackPressedDispatcherOwner` on the dialog's decor view via the ViewTree APIs, fixing issues when hosting a ComposeView within an AppCompatDialog. AppCompat now depends on Activity 1.7.0."
    Bug: 261314581
    Test: AppComptaDialogTest
    Change-Id: Ib28abb12cc3c617b9ffed9e1450e48308dc7c3df

M       appcompat/appcompat/build.gradle
A       appcompat/appcompat/src/androidTest/java/androidx/appcompat/app/AppCompatDialogTest.kt
M       appcompat/appcompat/src/main/java/androidx/appcompat/app/AppCompatDialog.java

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

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

commit 6b7a0f963d43aa6a06b461d62743ed81adddce40
Author: sanura <sanura@google.com>
Date:   Thu Mar 16 23:01:38 2023

    Open up initViewTreeOwners() API for ComponentDialog and ComponentActivity
   
    Making initViewTreeOwners() a public API in ComponentDialog
    and ComponentActivity so it can be used by AppCompat.
   
    RelNote: "`ComponentDialog` and `ComponentActivity` now
    contain public API `initViewTreeOwners()` to be used to
    initialize all view tree owners before setting the
    content view."
    Bug: 261314581
    Test: all tests pass
   
    Change-Id: Ibdce0a994b0daddc090e4ff58583ccba71612870

M       activity/activity/api/current.txt
M       activity/activity/api/public_plus_experimental_current.txt
M       activity/activity/api/restricted_current.txt
M       activity/activity/src/main/java/androidx/activity/ComponentActivity.java
M       activity/activity/src/main/java/androidx/activity/ComponentDialog.kt

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

Coco73g11@gmail.com

Galaxy 3571881034
199001

On Wed, Mar 29, 2023, 11:36 PM <buganizer-system@google.com> wrote:

Ok, I found something odd. Seems like  setRequiredNetworkType(NetworkType.UNMETERED) causes this for some reason. I'm going to update the sample so you can review this again. Please, reopen this since it's not intended behavior.

This happens on a fresh install with KEEP instead of REPLACE if the constraints have setRequiredNetworkType(NetworkType.UNMETERED). I've updated the sample

"And shouldn't the behaviour be consistent across all Android versions?"
The behavior is actually consistent. Once your worker starts running, if we get a call to enqueueUniquePeriodicWork a new work request and with ExistingPeriodicWorkPolicy.REPLACE we will stop existing work.
If your Worker was not running, then there is nothing to cancel. This is just a matter of timing.

I'm not arguing against the expected behavior of ExistingPeriodicWorkPolicy.REPLACE, since that's working as intended. But this is happening only when setRequiredNetworkType(NetworkType.UNMETERED) is used while having ExistingPeriodicWorkPolicy.KEEP.

Can you send us an updated sample ?

Looks like you have updated the sample, let me take another look.

Yes, I've updated the sample on github. Thanks for taking another look.

I looked at your code. Looks like the constraints are being unmet after the work starts in some cases.
So essentially, your worker starts, and mid-way the constraints are unmet. At this point because your Worker may not recover gracefully, we cancel and reschedule work. This happens for all your workers actually (if you turn on verbose logging you can see that).
This too is expected.

We have exactly the same issue in a major app - so that even SDK versions < 23 make up a six figure number of installs. We use WorkManager to synchronize data from an api - this should only happen every couple of minutes and due to this issue, it leads to multiple api calls per seconds on those older Android versions, generating an "expensive" load on our cloud-based infrastructure.

Re: #13/14: We're looking at it some more.

#15: File a separate bug, with sample code or a sample app.  The issue is vague enough that there could be something completely different happening.

#14: Even with verbose logging selected, I only see TestWorkerA being cancelled. The other workers are still successful.

I can confirm the root cause is exactly the same here as in our app:

 java.util.concurrent.CancellationException: Task was cancelled.
        at androidx.work.impl.utils.futures.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:1184)
        at androidx.work.impl.utils.futures.AbstractFuture.getDoneValue(AbstractFuture.java:514)
        at androidx.work.impl.utils.futures.AbstractFuture.get(AbstractFuture.java:475)
        at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:245)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
        at java.lang.Thread.run(Thread.java:841)

In our case:

 fun scheduleHighlightsSync() {
        val request = PeriodicWorkRequest.Builder(SyncHighlightsWorker::class.java, 1, TimeUnit.HOURS)
                .setConstraints(Constraints.Builder()
                        .setRequiredNetworkType(NetworkType.CONNECTED)
                        .setRequiresBatteryNotLow(true)
                        .build())
                .build()
        WorkManager.getInstance().enqueueUniquePeriodicWork(SYNC_HIGHLIGHTS,
                ExistingPeriodicWorkPolicy.KEEP, request)
    }

according to the logs TimeUnit.HOURS is ignored and we get them several times per second on SDK < 23

01-09 18:36:22.440 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerA: I did some work
01-09 18:36:22.450 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerB: I did some work
01-09 18:36:22.740 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerC: I did some work
01-09 18:36:22.750 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerD: I did some work
01-09 18:36:23.050 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerE: I did some work
01-09 18:36:52.350 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerA: I did some work
01-09 18:36:52.360 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerB: I did some work
01-09 18:36:52.650 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerC: I did some work
01-09 18:36:52.650 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerD: I did some work
01-09 18:36:52.950 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerE: I did some work
01-09 18:37:22.350 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerA: I did some work
01-09 18:37:22.380 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerB: I did some work
01-09 18:37:22.660 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerC: I did some work
01-09 18:37:22.680 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerD: I did some work
01-09 18:37:22.960 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerE: I did some work
01-09 18:38:22.350 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerA: I did some work
01-09 18:38:22.390 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerB: I did some work
01-09 18:38:22.660 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerC: I did some work
01-09 18:38:22.690 12508-12528/com.github.rubensousa.workkitkatbug D/TestWorkerD: I did some work
01-09 18:38:22.950 12508-12529/com.github.rubensousa.workkitkatbug D/TestWorkerE: I did some work


Logs when all workers are affected. Even though Result.sucess() was returned, due to this issue, WorkManager keeps retrying them. You can see the exponential backoff starting at 30 sec and going to 1 min, 2 min, 4 min etc

Yes, definitely not 15 minutes as in your github example project.

I think if this issue can not be solved quickly, https://developer.android.com/topic/libraries/architecture/workmanager/ needs a big warning message for SDK < 23 - at least for periodic jobs

A fix should be available in the next beta.

Thanks!!! Is there a time estimate for the next beta ?

#23: Thank you so much for taking another look and solving the issue :)

#24: Most likely next week.