OSS Tanbou
Sign in with GitHub
View on GitHubProject website

trace retained Android objects to the references causing memory leaks

OSS scale score 302.1OSS health 88Update pace 81 commits/30d
About these scores

OSS scale score is an unbounded metric that log-compresses and weights Stars, Watchers, Forks, and Contributors. Discovery score is the current OSS scale score minus the score at discovery. Update pace is commits in the last 30 days, growth momentum is the OSS scale score difference within the recent observation window, and OSS health is a 0–100 rating based on available recency, Community Health, and release data.

Stars
30,005
Primary language
Kotlin
License
Apache-2.0
Repository last updated
Oct 5, 2026
On this page

Overview

LeakCanary is a development diagnostic library that finds Android objects that were not released and shows the reference path retaining them.

Features and best fit

Based on official documentation; not hands-on tested · Content checked:

Key features

Watch objects that should be released and analyze their reference paths

LeakCanary watches Android objects such as destroyed activities, captures a heap dump when they remain retained, and reports a leak trace from a GC root to the object.

Sources: [4]

Best fit

Connect reproducible Android interactions to the retaining reference

Added as a debug dependency, it lets developers reproduce navigation on a development device and inspect notifications and traces. It fits teams that need a concrete reference path rather than a memory-growth symptom.

Sources: [3][1]

Before adoption

Treat debug-build analysis as evidence to investigate

Heap analysis takes time and storage, and not every retained object is a defect. The fixed in-repository sample uses minSdk 24, compileSdk 36, Android Gradle Plugin 9.2.1, JDK 17, and Gradle wrapper 9.6.1. Build that sample as debug and keep it separate from release artifacts.

Sources: [10][11][7]

Official sources

  1. [1]LeakCanary README at commit 1aa85dc(2026-10-05)
  2. [2]LeakCanary v3.0-alpha-9 release(2026-10-05)
  3. [3]LeakCanary getting started(2026-10-05)
  4. [4]LeakCanary fundamentals(2026-10-05)
  5. [5]LeakCanary GitHub metadata(2026-10-05)
  6. [6]LeakCanary Apache license at commit(2026-10-05)
  7. [7]LeakCanary fixed sample debug dependencies and Android configuration(2026-10-05)
  8. [8]LeakCanary fixed sample MainActivity leak actions(2026-10-05)
  9. [9]LeakCanary fixed sample button labels(2026-10-05)
  10. [10]LeakCanary fixed SDK and AGP versions(2026-10-05)
  11. [11]LeakCanary fixed Gradle wrapper(2026-10-05)
Supplemental curator note

LeakCanary fits Android teams that need to trace retained objects after navigation back to their reference paths. Keep it in debug builds and development devices, then correlate each trace with reproduction steps and code changes.

Try it in 3 steps

  1. 1

    Inspect requirements and the debug integration point

    Requires Git, JDK 17, and Android SDK 36. Check out the fixed commit and verify minSdk 24 and compileSdk 36; the build uses its Gradle 9.6.1 wrapper and Android Gradle Plugin 9.2.1.

    git clone https://github.com/square/leakcanary.git leakcanary && cd leakcanary && git checkout --detach 1aa85dc0472d6e38966a649741a7ce30f828d162 && test "$(sed -n 's/androidMinSdk = "\([0-9]*\)"/\1/p' gradle/libs.versions.toml)" = 24 && test "$(sed -n 's/androidCompileSdk = "\([0-9]*\)"/\1/p' gradle/libs.versions.toml)" = 36
  2. 2

    Build and install the in-repository debug sample

    Build and install the fixed sample that already uses debugImplementation(projects.leakcanary.leakcanaryAndroid) on a connected device or emulator; no published release dependency is added.

    ./gradlew :samples:leakcanary-android-sample:installDebug
  3. 3

    Leak and destroy MainActivity, then inspect the analysis

    In Example App, tap “Leak Activity,” then “Finish” to destroy MainActivity. Open the heap-dump notification and inspect the reference-path analysis.

    adb shell am start -n com.example.leakcanary/.MainActivity && printf '%s\n' 'On the device: tap "Leak Activity", then "Finish" to destroy MainActivity. Wait for the LeakCanary heap-dump notification, open it, and inspect the reference-path analysis.'
Check the official README

Growth

Growth trends · Last 30 days

30,005 Stars

Trend data is still being collected.

Development activity

Last 90 days · weekly

Commits (last 30 days)
81
Open PRs
15

Development activity is still being collected.

Built with

Categories and tags

Categories

Tags

GitHub data

GitHub dataView detailed GitHub data
View on GitHub

GitHub Topics

  • android
  • memory-leak
  • java
  • kotlin
  • kotlin-android
  • outofmemory
  • outofmemoryerror
  • leakcanary
  • leak-canary
  • leak-trace
Stars
30,005
Forks
3,994
Watchers
977
Open issues
115
Contributors
145
Owner type
Organization
Primary language
Kotlin
License
Apache-2.0
Repository last updated
Oct 5, 2026
Write a related article

Share a guide or use case for this OSS in Markdown. Articles are published after administrator approval.

Report incorrect information

Tell us if any listing information is incorrect or outdated.

After reading this page, do you know what to do next?