How to tell if an Android app is actually leaking memory?
<p>Whilst developing an application, I noticed that it eventually crashed because the JVM could not allocate any more memory. Using the the adb shell dumpsys meminfo command, I could see that the allocated native heap grew whilst switching activities until it approached 16M, when it crashed. I believe I've now corrected the code to stop this happening, but I notice that the figures returned by ..meminfo vary a bit and in general seem to rise slightly now.</p>

<p>Basically I'm not sure whether they should return to the same values when I start and stop an application. I have these figures and I'm not sure whether they signify that I have a memory leak or not:</p>

<p>At home screen, application in memory (PID seen in DDMS), but not running</p>

<p>adb shell dumpsys meminfo (relevant PID) gives:</p>

<pre><code>                    native   dalvik    other    total
            size:     5248     4039      N/A     9287
       allocated:     5227     3297      N/A     8524
            free:       12      742      N/A      754
           (Pss):     2183     3534     1726     7443
  (shared dirty):     1976     4640      876     7492
    (priv dirty):     2040     1664      940     4644
</code></pre>

<p>Application started from home screen, acivities started were :</p>

<p>splash screen -> select mode -> Activity 1, then all backed out using the back button,
till back at home screen</p>

<p>meminfo now:</p>

<pre><code>                    native   dalvik    other    total
            size:     5572     4231      N/A     9803
       allocated:     5497     3153      N/A     8650
            free:       74     1078      N/A     1152
           (Pss):     2479     3614     1742     7835
  (shared dirty):     1976     4632      876     7484
    (priv dirty):     2336     1740      956     5032
</code></pre>

<p>process repeated: </p>

<pre><code>                    native   dalvik    other    total
            size:     5696     4231      N/A     9927
       allocated:     5211     2949      N/A     8160
            free:      392     1282      N/A     1674
           (Pss):     2515     3713     1742     7970
  (shared dirty):     1976     4632      876     7484
    (priv dirty):     2372     1840      956     5168
</code></pre>

<p>Eclipse Memory Analyzer Tool (which I don't find all that informative) reports on the following
'leak suspects':</p>

<pre><code>3,143 instances of "java.lang.Class", loaded by "&lt;system class loader&gt;" occupy 736,760 (35.69%) bytes. 

Biggest instances:

class com.ibm.icu4jni.util.Resources$DefaultTimeZones @ 0x40158fe0 - 165,488 (8.02%) bytes. 
class android.text.Html$HtmlParser @ 0x400eebd8 - 126,592 (6.13%) bytes. 
class com.google.googlenav.proto.GmmMessageTypes @ 0x43d183d8 - 56,944 (2.76%) bytes. 
class org.apache.harmony.security.fortress.Services @ 0x40071430 - 51,456 (2.49%) bytes. 
class android.content.res.Resources @ 0x4004df38 - 33,584 (1.63%) bytes. 
class android.text.AutoText @ 0x400f23c8 - 31,344 (1.52%) bytes. 



Keywords
java.lang.Class


Details »
  Problem Suspect 2
8,067 instances of "java.lang.String", loaded by "&lt;system class loader&gt;" occupy 497,304 (24.09%) bytes. 

Keywords
java.lang.String


Details »
  Problem Suspect 3
54 instances of "org.bouncycastle.jce.provider.X509CertificateObject", loaded by "&lt;system class loader&gt;" occupy 256,024 (12.40%) bytes. These instances are referenced from one instance of "java.util.HashMap$HashMapEntry[]", loaded by "&lt;system class loader&gt;"

Keywords
org.bouncycastle.jce.provider.X509CertificateObject
java.util.HashMap$HashMapEntry[]
</code></pre>

<p>All comments will be gratefully received</p>
