Why does my code leak when switching activities?

Question

I have written a mapping application which can either use Google Maps or Open Street Map as a tile provider. The Google and OSM maps are displayed in separate activities. After the splash screen a select mode activity is entered. From this screen the user can either choose the Google or OSM activty via a button.

I'd like to be able to switch between Google and OSM via a button in each mapping activity. When I code the click handler for each of the mapping activities, I have in each:

i = new Intent("com.me.otheractivity");
finish();
startActivity(i);

I have no service connection, or inner classes for overlays etc. anywhere in the code. When I traverse from Select->Google-> Select(via back button) -> OSM , all is fine in terms of allocated heap.

If I go directly from one mapping activity to the other repeatedly, then the allocated heap grows and eventually crashes at 16M. Obviously it must be leaking somewhere via this route.

I'm logging every onCreate, Start, Resume, Pause, Stop and Destroy in all 3 activities. If I use the back button route I have the log:

Select Activity -> Google Activity -> OSM Activity (direct via button in Google Activity)

Select Activity Pause 
Google Activity Create
Google Activity Start 
Google Activity Resume
Select Activity Stop 
Google Activity Pause 
Open SM Activity Create 
Open SM Activity Start 
Open SM Activity Resume 
Google Activity Stop 
Google Activity Destroy

Going via back button, I get

Select Activity -> Google Activity -> Select Activity -> OSM (via back button)

Select Activity Pause 
Google Activity Create 
Google Activity Start
Google Activity Resume 
Select Activity Stop
Google Activity Pause 
Select Activity Start 
Select Activity Resume 
Google Activity Stop 
Google Activity Destroy
Select Activity Pause
Open SM Activity Create
Open SM Activity Start
Open SM Activity Resume
Select Activity Stop 

In the first example the Google Activity is not stopped or destroyed until after the OSM one is created, started and resumed. Is this significant regarding the leak?

I set to null all timers, handlers and overlays in the onPauses. (Combining the two views in one activity is not really an option owing to the differences between the Google maps.jar and osmdroid.jar)

Is anything wrong with the code in my click handlers?

All suggestions will be gratefully received.

EDIT 26th Feb

Further to my original post - the salient point for me is :

Why is it necessary for the onDestroy in one activity to run before the onResume in the second activity for the memory usage to stop growing?

If the onResume in activity B runs before the onDestroy in activity A, then I see that the number of activities on the history stack (as reported by adb shell dumpsys meminfo) increase by one each time. No amount of forced GC either in the code or via DDMS will take them off the stack.

I've since modified my code so that the clickhandler just calls finish(). In the onDestroy I call the startActivity(). This briefly returns the screen to the select mode activity before running the other activity. Under these circumstances obviously the onDestroy() in A runs before the onResume() in B and neither the history stack or heap usage grow.

I just don't get it.

Answer 1

I would heavily recommend using the Eclipse MAT (Memory analyzer) tool against all android apps you plan to release.

I have noticed apps I have worked on ending up with memory leaks from patterns a standard java developer knows would not create a memory leak.

Use the MAT tool to trace the dependencies causing leaks and either rework that code or in worst case scenarios I have resorted to reflection to break the dependency and allow it to release.

Answer 2

You may be suffering from the same memory leak issue asked a few minutes in front of you here

Answer 3

It relates to your code, as Octavian Damiean said, we need more information to help. I've tried your case with 3 simple Activities, no leak occurs. Every Activity instance destroyed can be successfully GCed. That means either there's a flaw in your application, or there's a flaw in the framework revealed by your application. In either case we need more than the descriptions you've provided.

But as you already know you're leaking "GoogleActivity" and "OpenSMActivity", MAT can be helpful.

Dump hprof file, click "Open Query Browser" (left to the search button) and then "Merge Shortest Paths to GC Roots" -> "exclude all phantom/weak/soft etc. references". Fill in the full class name of leaking Activity and finish. Then you'll see who's holding your Activity.