How do you find Android memory leaks?

Direct answer

What a strong answer covers

How it works

An Android leak is an object kept reachable after its lifecycle ended, most often an Activity or Fragment held by something that lives longer: a static field, a singleton listener, a Handler with pending messages, a coroutine still running, or a View referenced from a ViewModel. LeakCanary watches destroyed objects and reports the shortest strong reference chain from a GC root when one is retained. For leaks it does not catch, a heap dump in Android Studio’s profiler filtered by Activity instances after several navigations shows what should be gone but is not.

Example

After rotating a screen ten times the profiler showed ten instances of MapActivity; the reference chain led to a location callback registered on an application-wide LocationManager and never unregistered. Removing the callback in onStop fixed the leak, and a LeakCanary run in the debug build now fails CI if the Activity is retained again.

Common mistakes

• Registering a listener on a long-lived object in onCreate and never removing it.
• Storing a View or Context in a companion object for convenience.
• Dismissing LeakCanary reports as noise instead of reading the reference chain.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.