Android Memory Leaks: Causes and Solutions

Garbage collection frees objects nothing references any more. A leak happens when something long-lived (a singleton, a static field, a running coroutine, a registered listener) keeps a reference to something short-lived, like an Activity that has already been destroyed. Every rotation can then add another dead Activity to memory.

How a leak happens

Common causes and fixes

The Fragment binding leak

class ProfileFragment : Fragment(R.layout.fragment_profile) {
    private var _binding: FragmentProfileBinding? = null
    private val binding get() = _binding!!      // only valid between onViewCreated and onDestroyView

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        _binding = FragmentProfileBinding.bind(view)
    }

    override fun onDestroyView() {
        super.onDestroyView()
        _binding = null                           // the Fragment may outlive its View (back stack)
    }
}

Finding leaks with LeakCanary

dependencies {
    debugImplementation("com.squareup.leakcanary:leakcanary-android:<version>")   // debug builds only
}

LeakCanary watches destroyed Activities, Fragments, Views and ViewModels. When one isn't collected, it dumps the heap, analyses it, and shows the leak trace: the reference chain from a GC root to the leaked object. Read it bottom-up to find the reference that shouldn't exist.

Investigating with Android Studio

1. Open the Profiler and choose memory tracking for your app.
2. Reproduce the suspected leak, for example by rotating several times or opening and closing a screen.
3. Force garbage collection, then capture a heap dump.
4. Filter by your Activity class. More instances than expected indicate a leak, and Android Studio can highlight leaked Activities and Fragments.
5. Inspect the references of a leaked instance to find the GC root path.

Memory problems that aren't leaks

• Large bitmaps: decoding full-resolution images for thumbnails. Use an image library that downsamples.
• Unbounded caches: in-memory lists that grow forever. Use LruCache with limits.
• Holding large data in UI state: page it with Paging, or keep it in the database.

Real investigations

Prevention habits

• Use lifecycle-aware components and scopes (viewModelScope, repeatOnLifecycle, DisposableEffect).
• Inject the application context with Hilt's @ApplicationContext into long-lived objects.
• Keep LeakCanary in debug builds and treat its reports as bugs.
• Compose reduces many View-related leaks, but listeners and contexts can still leak.

Frequently asked questions

Conclusion

Memory leaks are reference paths from long-lived roots to dead objects, usually Activities, Fragments' Views or Contexts. Detect them with LeakCanary and heap dumps, fix the offending reference, and prevent them with lifecycle-aware scopes and application context.

Next step: tackle the other major stability issue in ANR Errors Explained.