Leakcanary: Clarify what "excluded leaks" are about
Developers new to LeakCanary are sometimes surprised by what "excluded" means, it's not immediately obvious, and they don't know what to do with it.
There's probably some tiny adjustments we can make to UX / messaging to clarify.
pyricau
All 4 comments
what does it mean by the way?
I made some changes to fix a memory leak and started getting them after. If they are excluded, why are they displayed?
mateusgrb
on 6 Sep 2018
Generally, all leaks are real leaks. However, some leaks happen in the Android source code, and there isn't much we can do to fix them except wait for a new Android version that doesn't have the leak.
LeakCanary lets you set a list of exclusions. If a leak trace matches one of those exclusions, it gets marked as "excluded", which means you can safely ignore it (if, and only if, you wrote exclusions correctly). The way I think of it: "this leak is something that I can't do anything about, so I don't have to pay attention to it"
However, LeakCanary can only detect if a leak is "excluded" after it runs the analysis, which means that even when you ignore a leak you'll still get the VM to freeze and the notification about the analysis. So there's still a cost to it in dev, and it's better to find a way to fix the leak if you can. Initially we were hidden the excluded leaks but then people would complain that they'd see the VM freeze and couldn't find the leak afterwards.
If you've got several activities / fragment matching an exclusion that you added, you should double check that this isn't an actual real leak in app code.
pyricau
on 16 Oct 2018
I filed this issue twice, so closing the other and copy pasting here what I wrote:
Developers typically aren't sure what to do with excluded leaks, so we should think about better ways (in notifications / leak string / leak UI) to convey what this is / what to do.
Typically they can:
Ignore those
Use a more recent Android version
Figure out a hacky way to make the leak go away
pyricau
on 10 Jan 2019
We've changed the words, instead of "excluded" these are known as "won't fix". I believe this will better convey that those are indeed leaks.
pyricau
on 5 May 2019
Related issues
pyricau
路
4Comments
runningcode
路
7Comments
divyenduz
路
6Comments
basti-shi031
路
3Comments
BraisGabin
路
6Comments
Most helpful comment
Generally, all leaks are real leaks. However, some leaks happen in the Android source code, and there isn't much we can do to fix them except wait for a new Android version that doesn't have the leak.
LeakCanary lets you set a list of exclusions. If a leak trace matches one of those exclusions, it gets marked as "excluded", which means you can safely ignore it (if, and only if, you wrote exclusions correctly). The way I think of it: "this leak is something that I can't do anything about, so I don't have to pay attention to it"
However, LeakCanary can only detect if a leak is "excluded" after it runs the analysis, which means that even when you ignore a leak you'll still get the VM to freeze and the notification about the analysis. So there's still a cost to it in dev, and it's better to find a way to fix the leak if you can. Initially we were hidden the excluded leaks but then people would complain that they'd see the VM freeze and couldn't find the leak afterwards.
If you've got several activities / fragment matching an exclusion that you added, you should double check that this isn't an actual real leak in app code.