Sample application, memory leaks found by LeakCanary
See original GitHub issueIssue Type
[ X] Bug
Description and/or steps/code to reproduce the problem
I was using the demo application and noticed that LinearLayout
is leaked when calling a sample and moving back to the ListView. I added screenshots from three different cases below.
Environment
If it’s a bug, version(s) of android this affects:
All
Version of osmdroid the issue relates to:
6.1.5
Issue Analytics
- State:
- Created 4 years ago
- Comments:15 (5 by maintainers)
Top Results From Across the Web
Handling Memory Leaks in Android Using LeakCanary
This tutorial will help the reader understand how to use LeakCanary to detect memory leaks in Android applications.
Read more >Fixing a memory leak - LeakCanary
A memory leak is a programming error that causes an application to keep a reference to an object that is no longer needed....
Read more >LeakCanary: Detect all memory leaks! - Medium
LeakCanary is an Open Source Java library to detect memory leaks in your debug builds. Let's look at a cat example: class Cat...
Read more >Finding Memory Leaks with Leak Canary
If memory leaks are detected, Leak Canary builds a notification. You can click on the notification to see more information about the detected...
Read more >Detect memory leaks in your instrumentation tests using ...
I wrote (stole from the LeakCanary sample app) this Activity which leaks memory when pressing the “Leak” button. The code is in Java...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
So far so good. The solution seems to be:
Fragment
s, theView
s must benull
ed inonDestroyView
(which is already the case inBaseSampleFragment
because of an old memory leak issue #335)super
statement last inonDestroyView
As there are about 140
Fragment
s in the demo app, the fix is not going to be instant (though it’s easy). I’m working on it.Life is short: I limited the fix to the main
Fragment
s. If we find fragments related memory leaks, now we now how to deal with them. Fixed by #1487.