Woo-hoo! Now you know what is happening with your app’s memory usage when you see one of those OOM exception. But, you don’t know where to find the source. Let alone, how to fix it.

Tracking down memory issues can be a pain in the neck. Here are a few strategies that will help you as you pursue the noble craft of Android-igami.

Sample project

There are code snippets and screenshots of what I’m working on sprinkled throughout this post. These will come from a single sample project, and if you prefer to see things in their entirety before being divided into little pieces, I provided that sample project to download here.

  • Yes, it uses Eclipse. Sorry to all you cutting edge folks working with the still beta Android Studio.
  • Structure: One activity, with a fragment. You’ll see an image that turns on and off every 5 seconds.
  • We’re using a singleton manager to keep time for us, and notify the Fragment when it’s time to switch the image on or off.

For those keeping score at home, this project has one A-level memory leak: the type of leak that no developer should ever allow into their code. And I’m not going to tell you where it is. But, that’s the purpose of this experiment! So let’s take a look at where it goes wrong.


  1. Open the DDMS1 Perspective in Eclipse (It should be found somewhere around the Window->Open Perspective->Other popup dialog).
  2. Highlight the process you wish to profile (most real devices will only show “debug”-signed processes, so you’d only see it on a real device if you built and installed from adb).
  3. Tap the little green “disk” icon (circled in above image), named “Update Heap.”
  4. Make sure you open the Heap panel on the right side of the screen.
  5. Tap the “Cause GC” button2.

This will put some numbers in that chart. The one we should focus on is “Allocated,” which shows you how much memory the Dalvik VM currently has given your app. This can stretch and shrink a bit, but there’s an upper limit (the size of which depends on the device). If you exceed the upper limit, you pop out an OOM and the app crashes.

This is a great tool to keep an eye on while you develop, since it shows a live snapshot of the system after any garbage collection cycle. If you ever notice the allocated memory gradually increasing without ever letting anything go, that’s a good indication that you might have a memory leak.3


There are some acronyms for you, huh?

“MAT,” the Eclipse Memory Analyzer tool, can read a file that your virtual machine generates (Remember that one we talked about in the last post? It’s called Dalvik). That file, called a “heap dump,” represents the set of all objects currently stored on your process’s heap4. That means you can actually poke around the metadata of the objects you’re using during runtime.

What you’ll need:

  • Eclipse (the Google provided “ADT” version works well here).
  • MAT.
  • If you’re not using the DDMS plugin, you’ll need to manually convert the Dalvik profile into an .hprof file.

Plot a course

Run the MemoryLeek project on an emulator5. You should see a white screen with a slowly blinking image. Rotate the emulator ten or so times (either 7 on the numpad or Cntrl+F12). Now, return to Eclipse, and open the DDMS perspective once again. This time, we’re aiming for the green disc icon with an arrow attached — indicating you want to generate a heap dump. Go ahead and click it, and you should see a statement in the Android log that looks like:

昵    称: