Home/ Questions/Q 9182391
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T18:32:58+00:00

In a simplified version of my app, I have two activities, A and B.

  • 0

In a simplified version of my app, I have two activities, A and B. Actvity A starts B, and after some work B calls finish(). Using the Memory Analyzer Tool on most devices (Galaxy Nexus running 4.2, Droid 4 running 4.0.4, and Droid 2 running 2.3.4) shows no trace of activity B, which is what I expected.

But on Samsung S3 running 4.1.1, MAT shows activity B objects still around, due to paths to the following GC roots (weak/soft references excluded):

Class Name                                                        | Shallow Heap | Retained Heap
-------------------------------------------------------------------------------------------------
com.myCo.myApp.ActivityB  @ 0x42720818                            |          264 |         3,280
|- <Java Local> java.lang.Thread @ 0x4271cf60  Thread-21941 Thread|           80 |        52,264
|- mOuterContext android.app.ContextImpl @ 0x426adf68             |          104 |           784
    |  '- mContext android.media.AudioManager @ 0x428e49a0        |           48 |           152
-------------------------------------------------------------------------------------------------

Every time I start and stop activity B, MAT shows another instance of activity B’s memory footprint. And the more I open/close activity B, the bigger the memory footprint reported in logcat. Forcing a GC through MAT does not remove the references to activity B memory.

I have three questions.

  1. Why is the memory/GC behavior different across the different devices?

  2. On S3, will the OS eventually come back and GC the stranded activity B objects (in other words, should I not worry about it because Android will clean it up before a crash)?

  3. If not, where do the Thread and AudioManager references come from, and how would I clear them?

Thanks to any experienced “leak hunters” out there!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    UPDATE: In order to see if the “stranded” memory left by activity B is in fact a problem, I created a loop between activities A and B:

    --- A calls startActivityForResult() on B
--- B calls finish()
--- onActivityResult() in A calls B again, etc...

    I let it fly for about 15k iterations, and the program did not crash. So even though the JVM on this phone and OS version (Samsung S3, 4.1.1) leaves references to class B in memory, even after activity B calls finish(), it appears there is a later clean up of some kind, as the number of references to the B class did not monotonically increase during the test.

    In fact, I generated several heap dumps during the test and never saw more than about 100 instances of the B class — as opposed to the 15k I would expect to see if there were no other clean up. GC statements in the logcat also showed memory use going both up & down, in spite of the large number of invocations of activity B.

    My conclusion is that I should not worry about the existence of class B references in the heap dump after finish() calls, because it appears that the JVM used on this phone/Android version does some kind of deferred clean up.

    Note: This is my inference based on the test I ran, so if anyone knows differently please share. Thanks!

    • 0