True. Launching a long-running coroutine from everywhere will retain objects that it references until it’s finished or cancelled.

That’s why it’s advisable to use viewModelScope when inside ViewModel and lifecycleScope in activities and fragments. Because they know how to cancel those jobs.

https://developer.android.com/topic/libraries/architecture/coroutines

But if you don’t reference your activity or context (which is actually the activity itself) they won’t leak.

   CoroutineScope(SupervisorJob())
            .launch { 
                // activity.getString(R.string.something) // Memory leak!
                applicationContext.getString(R.string.something) // Memory leak on applicationContext but not on activity. That's fine.

            }
. . .
   }

Or at least that’s how I’d expect it to work. But there seems to be an unexpected behavior when you do withContext(NonCancellable) inside there. See https://github.com/Kotlin/kotlinx.coroutines/issues/1061.

In short, write it so there’s no references to Activity and other objects that reference Activity, as is good practice. Otherwise expect things to leak. I’d say the same if you reference any viewmodel objects inside a coroutine.

I’ve seen tutorials where writing to Room performed in a coroutine launched using viewModelScope, so it’s cancelled when ViewModel is destroyed. But I want data to be written in any case. So I want to launch this coroutine in a scope that doesn’t depend on Activity’s lifecycle.

class MyApplication : Application() {
  val applicationScope = CoroutineScope(SupervisorJob())
}

Is it true that if I launch a long-running coroutine in ViewModel using this scope ViewModel won’t be allowed to be garbage collected until the coroutine is finished even if Activity is destroyed?