IssueTracker

Can you give us the sample app or code that's exhibiting this problem?

See sample app linked in https://issuetracker.google.com/issues/134197846#comment52

In MyWorker.java, set `useInitialDelayForPeriodic` to `true`

Your examples have an initial delay + a flex time.
So the first instance will be closer to ~30 mins, because you want the periodic work to only be eligible at the end of initial delay + beginning of the flex window.

No, when `useInitialDelayForPeriodic` is set to `true`, I'm not using a flexInterval... check the code.

Sorry, i might have misread that part of the source code.

> BUT I'm not finding that.  Let's say that "interval" of the periodic work is 15 mins, and I set an "initial delay" also of 15 mins, and I set this going when the user hits the button.  I find that the immediate work is performed at 0 mins (triggered explicitly, not by WorkManager, so that's as expected), then at 15 mins NOTHING happens, and only at 30 mins does the first periodic work actually run.
What do you mean when you say - triggered work explicitly ? [ "I find that the immediate work is performed at 0 mins (triggered explicitly, not by WorkManager, so that's as expected)" ]

Which part of the source code are you referring to ?

MyWorker.java:

    static void schedulePeriodicWork(Context context, int appWidgetId, String trigger) {

        Log.d(TAG, "schedulePeriodicWork for " + appWidgetId);

        // do an immediate update, with periodic work kicking in later (subject to Doze etc)
        doSomeWork(context, appWidgetId);

^^^^^^
this bit is where I call doSomeWork() directly, when scheduling the periodic work, to get a guaranteed immediate execution of the first work.

Yeah.. I realized that's the part of the code that you were talking about. Your source code also had OneTimeWorkRequest's being created (but was not being called by anyone) - so was confused.

Yeah sorry the OneTimeWorkRequest stuff was there as one way of getting the immediate work done, and mostly it's OK, but certainly for some devices in particular the device delays quite some time before running the work, so it's not immediate enough.

We introduce some drift due to the way we reschedule ENQUEUED work on init (on process death).
I will fix this.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 39859499e6c1d1502f8dc764360b55a62eaba233
Author: Rahul Ravikumar <rahulrav@google.com>
Date:   Mon Jun 17 16:28:19 2019

    Fix for drifts in WorkRequests with periodStartTime = 0
   
    * When we have WorkRequests with initial delays (and periodStartTime = 0)
    and a process death occurs - we would previously look at all WorkSpecs
    in ENQUEUED state and reschedule them.
   
    * This would cause a drift for WorkSpecs with periodStartTime = 0,
    because they would be scheduled relative to System.currentTimeInMillis().
   
    * To fix this we move the cleanup step into ForceStopRunnable, given it is the
    first Runnable being executed in the TaskExecutor. This way we can also
    more accureately target WorkSpecs that were previously RUNNING rather than
    having to reschedule all WorkSpecs that were ENQUEUED.
   
    Fixes: b/135272196
    Test: Existing unit tests in ForceStopRunnableTests, updated tests in WorkManagerImplTest.
    Change-Id: I0fb5477c70a43b751fec1e0c5d9901188e2396f4

M       work/workmanager/src/androidTest/java/androidx/work/impl/WorkManagerImplTest.java
M       work/workmanager/src/androidTest/java/androidx/work/impl/utils/ForceStopRunnableTest.java
M       work/workmanager/src/main/java/androidx/work/impl/WorkDatabase.java
M       work/workmanager/src/main/java/androidx/work/impl/model/WorkSpecDao.java
M       work/workmanager/src/main/java/androidx/work/impl/utils/ForceStopRunnable.java

https://android-review.googlesource.com/984508
https://goto.google.com/android-sha1/39859499e6c1d1502f8dc764360b55a62eaba233

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

commit 169254301b8aad0454c253a65abff7bf174ba164
Author: Clara Fok <clarafok@google.com>
Date:   Tue May 09 11:11:42 2023

    Bump compose version in navigation-compose
   
    Bump from 1.0.1 to ToT project dependency. Project dependency because compose is currently in alpha.
   
    Test: n/a
    Bug: 197140101
    Relnote: "navigation-compose has bumped compose dependency to use latest compose dependency"
    Change-Id: Ide442548636637c2b75d46ef99c9913b0ebb60b8

M       navigation/navigation-compose/build.gradle

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