LeakCanary: memory leak detection built for Android devs

What is LeakCanary?

LeakCanary is an open-source Android library from Square that detects memory leaks while you're developing an app, not after it ships. It hooks into the Android lifecycle to watch objects — a destroyed Activity, a cleared Fragment — that the garbage collector should reclaim. When one lingers, LeakCanary dumps the heap and traces the reference chain from a GC root down to the object that's stuck.

Key features of LeakCanary

• ✓Automatic detection of retained Activity, Fragment, and View instances while you develop, no manual profiling session needed
• ✓Heap dumping and hprof analysis built in, so there's no separate analyzer to wire up
• ✓Leak trace output that shows the exact reference chain from a GC root to the leaking object
• ✓Works the same way in Kotlin and Java Android projects, since it hooks into the Android lifecycle, not the language
• ✓Apache-2.0 license, so it drops into a commercial app's debug build without a licensing conversation
• ✓Ships as a Gradle dependency — nothing to run as a separate service

When to use LeakCanary

• •Debugging an app whose memory usage keeps climbing over a long session
• •Catching a leaked Activity or Fragment right after refactoring navigation or lifecycle code
• •Running continuously during development so a leak surfaces before QA or a production crash does
• •Checking whether a third-party SDK or custom View is holding a reference past its Activity's lifecycle

Adding LeakCanary to your Android project

LeakCanary is added as a Gradle dependency to your app module — there's no account, service, or separate install step. This source doesn't include the exact dependency coordinates or current version number, so pull the precise Gradle line from the project's own docs at square.github.io/leakcanary rather than guessing at a version here. Once it's in the build, most apps need no further setup code to start seeing leak traces.

How LeakCanary works

LeakCanary watches for objects that are expected to be garbage collected — a destroyed Activity or Fragment, a cleared ViewModel, a View removed from its parent. If one of those objects is still around after enough time to be collected, LeakCanary triggers a heap dump and writes it to an hprof file. It then parses that dump and computes the shortest path from a GC root to the retained object — the leak trace — which points at the specific reference in your code keeping it alive. You see the result as a notification during development. No separate profiler session needed.

Alternatives for Android memory analysis

Frequently asked questions

The problem it solves

A memory leak in an Android app is quiet until it isn't — an app that holds onto a destroyed Activity or Fragment slowly eats available memory across a session, and the usual failure mode is a production OutOfMemoryError with a stack trace that doesn't say which object caused it. Catching that during development, before it reaches a crash report, is the specific gap LeakCanary fills: it names the reference that's leaking while you're still writing the code that leaked it.

Who should try it — and who should skip

A team shipping a production Android app in Kotlin or Java should have LeakCanary in the debug build — the setup cost is low next to the cost of chasing an OutOfMemoryError crash report with no leak trace attached. Skip it, or don't lean on it alone, if you're building a library or SDK meant to run inside someone else's app; the tool is built around your own app's development loop, not something you ship to consumers. It's also not the right tool for a broad performance or CPU regression — that's a profiler's job, not a leak detector's.

Related repositories