IssueTracker

Which version is this fixed in? Using android.arch.work:work-runtime-ktx:1.0.0-alpha08, I am still seeing repeated work executed when the scheduler is initialised in application onCreate.

Managed to work around it by creating a OneTimeWorkRequestBuilder delegate that calls through to WorkManager.getInstance().enqueueUniquePeriodicWork(), but seems sub-optimal..

Is your app being force-stopped prior to this?  Can you please provide some sample code that reproduces the problem?

Yes it would have been force-stopping on repeated Run 'app' triggers from Android Studio (v3.1.4).
Here is the sample code we tried:
package com.example.test.workmanagertest

import android.app.Application
import android.util.Log
import androidx.work.Constraints
import androidx.work.NetworkType
import androidx.work.PeriodicWorkRequestBuilder
import androidx.work.WorkManager
import androidx.work.Worker
import java.util.concurrent.TimeUnit

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        scheduleSomeWork()
    }

    fun scheduleSomeWork() {
        Log.i("WorkManagerTest", "Scheduling some work")
        val workRequestBuilder =
                PeriodicWorkRequestBuilder<MyWorker>(10, TimeUnit.HOURS)
        val constraints = Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build()
        workRequestBuilder.setConstraints(constraints)
        val work = workRequestBuilder.build()
        WorkManager.getInstance().enqueue(work)
        Log.i("WorkManagerTest", "Work scheduled")
    }
}

class MyWorker : Worker() {
    override fun doWork(): Result {
        Log.i("WorkManagerTest.Worker", "I'm working")
        return Result.SUCCESS
    }
}

If I run it on an emulator (Android 8.0.0) N times, I can see "I'm working" in the log N times. What's interesting is that it doesn't happen every time (e.g. 2nd execution only logged once, 3rd execution logged 3 times, 4th and 5th executions only logged once, 6th execution logged 6 times, you get the idea..)

Running on a real Pixel XL device Android 9, behaviour was slightly different but equally broken. I could not replicate it by simply hitting the green play button in AS (ran it 8 times). Before the 9th re-execution, I turned on the device screen, tapped the device home key to background the app and then hit play again in AS:

09-11 05:44:50.350 8034-8060/? I/WorkManagerTest.Worker: I'm working
09-11 05:44:50.355 8034-8059/? I/WorkManagerTest.Worker: I'm working
09-11 05:44:50.358 8034-8061/? I/WorkManagerTest.Worker: I'm working
09-11 05:44:50.423 8034-8059/? I/WorkManagerTest.Worker: I'm working
09-11 05:44:50.424 8034-8060/? I/WorkManagerTest.Worker: I'm working
09-11 05:44:50.460 8034-8061/? I/WorkManagerTest.Worker: I'm working
09-11 05:44:50.463 8034-8060/? I/WorkManagerTest.Worker: I'm working
09-11 05:44:50.468 8034-8059/? I/WorkManagerTest.Worker: I'm working
09-11 05:44:50.517 8034-8060/? I/WorkManagerTest.Worker: I'm working
09-11 05:44:50.522 8034-8061/? I/WorkManagerTest.Worker: I'm working

This is a barebones sample with hello world MainActivity.kt and associated LinearLayout
App build.gradle for full reference:

apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'
apply plugin: 'kotlin-android-extensions'

android {
    compileSdkVersion 28
    defaultConfig {
        applicationId "com.example.test.workmanagertest"
        minSdkVersion 23
        targetSdkVersion 25
        versionCode 1
        versionName "1.0"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation"org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
    implementation 'com.android.support:appcompat-v7:27.1.1'
    implementation 'android.arch.work:work-runtime-ktx:1.0.0-alpha08'
}


(ext.kotlin_version = '1.2.60' FYI )

I believe what you're seeing is intended.  You are enqueuing N periodic jobs.  There is nothing unique about them (did you mean to use enqueueUniqueWork?).  So there are N periodic jobs running in parallel.

The reason they run when the app is launched is that you are effectively force-stopping your app by using Android Studio relaunches.  You aren't just launching the app, you are force-stopping it (and possibly replacing the APK) and then launching it.  After WorkManager figures out it's been force-stopped, it makes sure to re-enqueue the tasks.  This means periodic work will run again.