How to tell if an Android app is actually leaking memory? -

whilst developing application, noticed crashed because jvm not allocate more memory. using the adb shell dumpsys meminfo command, see allocated native heap grew whilst switching activities until approached 16m, when crashed. believe i've corrected code stop happening, notice figures returned ..meminfo vary bit , in general seem rise now.

basically i'm not sure whether should return same values when start , stop application. have these figures , i'm not sure whether signify have memory leak or not:

at home screen, application in memory (pid seen in ddms), not running

adb shell dumpsys meminfo (relevant pid) gives:

                    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 

application started home screen, acivities started :

splash screen -> select mode -> activity 1, backed out using button, till @ home screen

meminfo now:

                    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 

process repeated:

                    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 

eclipse memory analyzer tool (which don't find informative) reports on following 'leak suspects':

3,143 instances of "java.lang.class", loaded "<system class loader>" 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 "<system class loader>" occupy 497,304 (24.09%) bytes.   keywords java.lang.string   details »   problem suspect 3 54 instances of "org.bouncycastle.jce.provider.x509certificateobject", loaded "<system class loader>" occupy 256,024 (12.40%) bytes. these instances referenced 1 instance of "java.util.hashmap$hashmapentry[]", loaded "<system class loader>"  keywords org.bouncycastle.jce.provider.x509certificateobject java.util.hashmap$hashmapentry[] 

all comments gratefully received

in mat, i've never encountered "leak suspect" leak. looking objects being retained after gc sweep shouldn't be.

for example, suppose have dashboard activity can launch activities , b. launch dashboard, launch activity a, press button, launch activity b, , press button.

using eclipse debug view, can force gc collection event via "cause gc" button. now, click "dump hprof file" button , launch mat. click on "dominator tree" link.

at point, expect memory associated activities & b have been collected garbage unless there error in code. typically, qualify 'memory leak' in app.

this occurs due retained contexts, can eat lot of memory since contexts represent large components (activities, services, etc.).

anything looks suspicious in dominator tree can investigated via "path gc roots" -> "exclude weak references" option (available via right-click menu). path2gc roots view easiest way find objects holding references objects such can't released.

once find unexpected references being retained can take more digging through code understand why . if has system/os component, grepcode friend :)