Default `delay` behavior on Android creates additional threads when using external dispatchers

[adamp]

When delay is called using an externally-defined dispatcher that does not implement the internal Delay interface, it uses a default fallback implementation that can cause an additional thread to be created. Some Android apps strictly audit threads created by their library dependencies and have raised this as an issue when using Jetpack Compose, which defines its own UI dispatcher and both promotes using the delay API and uses it internally.

On Android, apps always have a main thread running an event loop that could be used in place of creating an additional thread to time the delay, which could make Dispatchers.Main a suitable choice for performing the default delay on Android when a compatible/known dispatcher is not found.

[elizarov]

Indeed, we could design & implement a pluggable implementation for a default delay mechanism that kotlinx-coroutines-android module could implement on top of Android's main thread.

[qwwdfsad]

To opt-out from this behaviour, a temporary system property kotlinx.coroutines.main.delay can be set to false

[tanmatra]

Shouldn't variables declarations be swapped? See #3044.
Currently DefaultDelay is assigned before defaultMainDelayOptIn is assigned (and is initially false).

internal actual val DefaultDelay: Delay = initializeDefaultDelay()

private val defaultMainDelayOptIn = systemProp("kotlinx.coroutines.main.delay", true)

private fun initializeDefaultDelay(): Delay {
    // Opt-out flag
    if (!defaultMainDelayOptIn) return DefaultExecutor
    ...
}

[qwwdfsad]

Right, this is the bug with the cyclic initialization