An injected singleton keeps an old Activity alive after rotation. Where is the scope mismatch?

Answer

Trace the retention path rather than blaming dependency injection itself. A singleton can outlive many Activity instances. A stored Activity, view, or callback capturing a view can keep one destroyed screen reachable.

Example

An application-wide file locator can use an application context:

Copy code@Singleton
class DownloadPaths @Inject constructor(
    @ApplicationContext private val context: Context
) {
    fun lessonFile(name: String): File =
        File(context.filesDir, name)
}

Assume name is an internally generated safe filename. This dependency needs app storage, not an Activity. For UI operations that truly require an Activity, use an appropriately scoped owner or pass the current host for the duration of the operation without retaining it indefinitely.

Mistake to avoid

Replacing every Activity context with application context can break themed UI and other host-dependent behavior. A weak reference can also hide ownership problems rather than fix lifecycle cleanup. Inspect registered listeners and callback captures, not just constructor parameters.

Follow-up to practise

How would you verify the repair? Repeatedly recreate and leave the screen, then inspect a heap retention path or leak report. Verify that the old instance becomes collectible and that the current screen still receives the intended callbacks.

Reference

Android Developers: Hilt component scopes and context qualifiers