Version used: androidx.startup:startup-runtime:1.1.1, androidx.work:work-runtime:2.8.1

Devices/Android versions reproduced on: 13, 14

The startup system allows you to disable certain Initializers using the AndroidManifest. Disabling WorkManagerInitializer and implementing Configuration.Provider.getWorkManagerConfiguration is recommended practice e.g. when you want to use Hilt for WorkManagers: https://developer.android.com/training/dependency-injection/hilt-jetpack#workmanager

However, if you need to use WorkManager in your own custom Initializer, documentation suggests to let your Initializer depend on WorkManagerInitializer: https://developer.android.com/topic/libraries/app-startup#startup-initialize

Now the latter will prevent the first mechanism from working, because your custom Initializer will pull in WorkManagerInitializer even though it is removed from AppStartup. This becomes especially dangerous and will lead to unexpected behaviour, if you pull in an external library which provides a Initializer depending on WorkManagerInitializer. The external library will break your existing app without getting a compile error. See Airship for an example of this problem: https://github.com/urbanairship/android-library/issues/202#issuecomment-1816426396