title: How to tell if an Android app is actually leaking memory?
body: <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>