# Leak detection: Android Studio vs LeakCanary ⚔

DevFeed: [Leak detection: Android Studio vs LeakCanary ⚔](<https://devfeed.tech/articles/leak-detection-android-studio-vs-leakcanary-25861.md>)

Original publisher: [Read original article](<https://dev.to/pyricau/leak-detection-android-studio-vs-leakcanary-35j5>)

Author: Py ⚔

Published: 2020-10-30T00:13:40Z

Content type: tutorial

Language: en

Sources: [Py ⚔](<https://devfeed.tech/sources/py.md>)

Topics: [Android Studio](<https://devfeed.tech/topics/android-studio.md>), [Memory Leaks](<https://devfeed.tech/topics/memory-leaks.md>), [Android](<https://devfeed.tech/topics/android.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-studio](<https://devfeed.tech/tags/android-studio.md>), [coding](<https://devfeed.tech/tags/coding.md>), [community](<https://devfeed.tech/tags/community.md>), [development](<https://devfeed.tech/tags/development.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [false-positive](<https://devfeed.tech/tags/false-positive.md>), [inclusive](<https://devfeed.tech/tags/inclusive.md>), [leak](<https://devfeed.tech/tags/leak.md>), [leakcanary](<https://devfeed.tech/tags/leakcanary.md>), [memory](<https://devfeed.tech/tags/memory.md>), [memory-leaks](<https://devfeed.tech/tags/memory-leaks.md>), [software](<https://devfeed.tech/tags/software.md>)

## AI overview

The article compares Android Studio's Activity/Fragment leak filtering with LeakCanary's lifecycle-based detection. It explains that Android Studio may flag newly created or cached Fragments as potential leaks, while LeakCanary watches destroyed objects and checks whether they remain retained after garbage collection.

## Source excerpt

I recently came across this comment in a post: The thing really annoying about LeakCanary or Android Studio, most of the time leaks identified by LeakCanary do not appear in Profiler/Memory/memory leaks, I wonder if LeakCanary is showing false positives or Android Studio is missing positives. That's a good question, let's dig into code and figure this out! False positive leaks in Android Studio Before answering the question, we need to talk about where the idea of false positive leaks comes from: Android Studio. That warning was originally a longer description: Activity and Fragment instances that might be causing memory leaks. For Activities, these are instances that have been destroyed but are still being referenced. For Fragments, these are instances that do not have a valid FragmentManager but are still being referenced. Note, these instance might include Fragments that were created but are not yet being utilized. The documentation provides more insights on false positive leaks: In certain situations, such as the following, the filter might yield false positives: A Fragment is created but has not yet been used. A Fragment is being cached but not as part of a FragmentTransaction. The phrasing is vague but it looks like false positive leaks only applies to Fragments. Android Studio leak filtering Android Studio dumps and analyzes the heap when you press the Dump Heap icon. Leaking instances are displayed by enabling the "Activity/Fragment Leaks" filter, which updates the bottom panel to only show leaking instances. The filtering is performed by ActivityFragmentLeakInstanceFilter: const val FRAGFMENT_MANAGER_FIELD_NAME = "mFragmentManager" /** * A Fragment instance is determined to be potentially leaked if * its mFragmentManager field is null. This indicates that the * instance is in its initial state. Note that this can mean that * the instance has been destroyed, or just starting to be * initialized but before being attached to an activity. The * latter gives us