Saturday, 5 November 2011

Android - track down memory leaks

My current Android application project is starting to make sense. Unfortunately it crasches after a few levels of playing due to java.lang.OutOfMemoryError. Up to that point I hadn't put much thinking into the memory model of Android applications and simply consumed memory without hesitations. I've now been forced to rewrite some critical parts of the application and i thought I'll write a few words to remember the most useful tools I came across.

First of all, Android apps have small heaps. And with different sizes, it's up to the vendor of the device to decide. Here's a few numbers I came across:

  • G1 = 16 Mb
  • Droid = 24 Mb
  • Nexus One = 32 Mb
  • Xoom = 48 Mb
  • GalaxyTab = 64 Mb

So you see that allocated heaps are far from using the entire RAM of the devices since no application should be able to clog the system. The natural approach to solving a memory problem would be to increase the heap but that is not so easy. If you have a rooted phone you may edit

and set the heap size via

Or, if you're running on a tablet (3.x) Android version there is a manifest setting to ask for a large heap

<application android:label="@string/app_name" android:hardwareAccelerated="true" android:largeHeap="true" android:debuggable="true">
but that is no guarantee and you will instead be punished with longer GC cycle times.

On the other hand, changing the VM heap size in your emulator is easy, and could be a good thing in order to verify that your app works on devices with smaller heaps. To do that, fire up your Android SDK and AVD Manager and click edit on your virtual device. Under hardware, there is a setting Max VM application heap size.

So the conclusion is that you have to live with small heaps and limited memory. How to get an estimate of  your consumed memory and how much there is available then?
Run your application in the emulator or connect your real device via USB and use the Android Debug Bridge (adb). It's located in your Android SDK tools folder.

To dump memory info for all your running applications use
$>adb shell dumpsys meminfo

or for your specific application

$>adb shell dumpsys meminfo

Applications Memory Usage (kB):
Uptime: 8979886 Realtime: 8979886

** MEMINFO in pid 1073 [] **
                    native   dalvik    other    total
            size:    24648    10119      N/A    34767
       allocated:    10869     7335      N/A    18204
            free:        2     2784      N/A     2786
           (Pss):     2857     8568     9385    20810
  (shared dirty):     1508     4092     2556     8156
    (priv dirty):     2656     6020     7732    16408

           Views:        0        ViewRoots:        0
     AppContexts:        0       Activities:        0
          Assets:        2    AssetManagers:        2
   Local Binders:        6    Proxy Binders:       10
Death Recipients:        0
 OpenSSL Sockets:        0

            heap:        0       memoryUsed:        0
pageCacheOverflo:        0  largestMemAlloc:        0

To understand this table we must know that you have a managed heap, dalvik, and a native heap. For example some graphics are stored in native heap. But important, it is the sum of these heaps that can not exceed the VM heap size. so you can't fool the runtime by putting more stuff in either native or managed heap. So to me, the most important numbers are the number under dalvik and total above. The dalvik heap is the managed VM heap and the native numbers are memory allocated by native libraries (malloc).
You'll probably see these numbers fluctating each time you run the command, that is because objects are allocated by the runtime all the time but GCs are not run particularly often. So, in order to know that you really have garbage collected all unused objects you must either wait for the Android debug log in logcat to say something like
GC_FOR_MALLOC or GC_EXTERNAL_MALLOC or similar to that which indicates that the GC has been invoked. Still, this does not mean that all unused memory has been released since the inner workings of the GC might not have done a complete sweep.

You can of course ask for a GC programmatically by System.gc();
But that is never a good option. You should have trust in the VM to garbage collect for you. If you for example want to allocate a large memory chunk the gc will be invoked if necessary.

You can force a gc using the Dalvik Debug Monitor (DDMS). Either start it from Eclipse or from the ddms tool in the Android SDK installation folders.

If you can't see your process right away, go to menu Actions and Reset adb. After that you can turn on heap updates via the green icon Show heap updates. To force a GC, click on Cause GC.

If you wish to monitor the memory usage programmatically there are a few APIs you can use.

ActivityManager.getMemoryInfo() can be used to get an idea of how the memory situation is for the whole Android system. If running low on the gauges you can expect background processes to be killed off soon.

To start inspecting your process in particular use the Debug APIs There's an excellent explanation of the data you can retrieve from this here

For example, to see how much memory is allocated in the native heap, use:

So back to DDMS. This tool can also create heap dumps which are particulary useful when tracing down memory leaks. To dump the heap, click on the icon Dump HPROF file. There are many tools for analyzing heap dumps but the one I'm most familiar is the Eclipse Memory Analyzer (MAT). Download it from

MAT can't handle the DDMS heap dumps right away, but there is a converter tool in the Android SDK.
So simply run this command.

C:\Temp\hprof>hprof-conv rawdump.hprof converteddump.hprof

Then you can open the converted heap dump in MAT. An important concept here is retained size. The retained size of an object found in the heap is how much memory could be freed if this object could be garbage collected. That includes the object itself, but also child objects which no other objects outside of the retained set has references to.

MAT gives you an overview of where your memory is allocated and has some good tooling on finding suspicious allocations that could be memory leaks.

So to find my memory leak, I used the dominator tree tab which sorts the allocated objects by retained heap
and I soon discovered that the GLRendered object held far too many references to a large 512x512 texture.

The tool becomes even more valuable when the leaking objects are small but many. The dominator tree tell you right away that you have a single object holding a much larger retained heap than you would expect it to.

If you want to learn more, check out this speech by Patrick Dubroy on Android memory management from Google IO 2011 where he explains the Android memory model in more detail.


  1. I still dont understand how you found out about the texture reference.

    Another question i got is that MAT tells me about 4 possible memory leaks but i dont understand anything about them.

  2. Good point, so what I did was make a heap dump after say 1 minute of running the app. This for reference. Then I ran the app for some further amount of time and made a new heap dump. Opening the two dumps beside eachother it is clear that the later had allocated 3 mb more memory as texture objects. After that you must of course know your program well enough to recognise this as a bug.

  3. Giulio Piancastelli20 July 2012 at 16:02

    So I assume that if the dominators are system classes (e.g. Resources or Bitmap in an application using huge images) that's the sign there is no leak, and images needs to be scaled down, resampled, or whatever it takes to reduce their size, since that's the real cuprit.

  4. Yep very helpful i'm having an issue where i run out of memory after at least 20minutes of a "chat" channel which has images refreshing every 10seconds. I'll try as you did and take a dump early...let the program run (refreshing away...) for 10+ minutes and see what comparisons i can make between the two in MAT.

    BTW i've tried inspecting using DDMS Dump heap > Threads, Heap and allocation tracker and couldn't find anything. I assume MAT is easier to find problems??


  5. It's marvelous I didn't know about all this until the moment I saw this entry of yours. In addition to that I want to ask you a question which is extremely intriguing for me. Do you own any helpful data about how to protect your personal intellectual property from being used without your awareness about it?

  6. Thanks, everything worked out setting it up. Found link to this on StackOverflow.

  7. That's interesting! Can you please share more about it? Thank you.

    Android Application Developer India & Android Application Development Company

  8. Android is a versatile working framework that has been remarkably great due to its staggering characteristics. The majority of the Pdas in the business sector run on Android OS. Since the accomplishment of Android, parcel of Android Improvement Companies has prodded up all over. We are additionally putting great rationale to create all the more in this field.
    Develop Android Apps // Mobile
    Application Development
    // Android Application Development

  9. Hi your blog is good but it can be better. No hard feelings! This is just my personal opinion. You have to stand out among millions of online writers who are blogging like crazy, uploading articles every micro-second. There are wonderful tips for freelancers who gain by getting `online noticed’ – in other words `web visible’. Check out,Ebook cover brochure design websites. They offer the best hints on great blog writing.

  10. This comment has been removed by the author.

  11. last part really helped me. I was able to look at dominator tree, but was not able to figure out how to zero down on object which is causing it. Now I know that expanding it till the end will reveal the object name.
    Though I have one question, when you said "a single object holding a much larger retained heap than you would expect it to.", so in that image, how do you figure out where the leak was happening in your code just by looking at 'int[2342342]'? This is still a mystery to me.

  12. Good Job. Very informative blog. It's really helpful for Android Application Development company for making new apps.

  13. Android is a versatile working framework that has been remarkably great due to its staggering characteristics. The majority of the Pdas in the business sector run on Android OS. Android Application Development

  14. Thanks, Currently Android applications are running fast then others for Tablets. It is also to know about track down leaks of memory. Tanks for sharing such kind of details.
    Android Tablet Development

    Keep sharing..

  15. Interesting blog, helped to clarify many things, definitely this will be a useful article. Good work, excepting these kinds of more useful blogs and articles.
    Mobile app development Company

  16. Hey, very nice site. I came across this on Google, and I am stoked that I did. I will definitely be coming back here more often. Wish I could add to the conversation and bring a bit more to the table, but am just taking in as much info as I can at the moment. Thanks for sharing.

    Dai Software

  17. Hey, very nice site. I came across this on Google, and I am stoked that I did. I will definitely be coming back here more often. Wish I could add to the conversation and bring a bit more to the table, but am just taking in as much info as I can at the moment. Thanks for sharing.

    Mobile Application Development

  18. What does it mean by memory leak? Could you please explain more
    App Developer Dubai

  19. Thank you so much for sharing nice information and i want to read other posts also

    apps development companies in Ahmedabad
    iot companies Ahmedabad

  20. There are some design bugs in Android UI interface that might have cause the trouble.
    outsource graphic design service

  21. I really enjoyed this posting in which you share a valuable post. Thanks for sharing it. web design company in Ahmadabad.

  22. Thank you for bestowing this information which will enlighten many of us. It’s really helpful for me and the one who wants to know more about mobile app development company.

  23. thank you for the valuable post.


  24. Your post is amazed me. Your article is very much informative. You always share such a wonderful articlewhich helps us to gain knowledge .thanks for sharing such a wonderful article, It will be deinitely helpful and fruitful article. hope we will always gain from your article.

  25. Those students are eagerly waiting for SSC CGL 2019 Notification. Staff Selection Commission will announce SSC CGL notification in the month of October 2019

  26. You have shared really helpful tutorials. I like it. Thanks for sharing such a great stuff. Web Solution Winner Blog

  27. National Testing Agency is going to conduct the JEE Main 2020 Examination .the exam is conducted twice in a year in this article we are sharing all the important details for jee main 2020 click here for all the details

  28. thank you for sharing this useful information

    Cpa offers

  29. You have Top companies listed well in India. I will strongly accommodate the one company. The Company Name is Freelance To India Which provide the top quality services in Website and Mobile Application Development.

  30. Thanks, Excellent Services related company information you have shared. Web Solution Winner is The World's Most Successful Blog. We write about Technology, Business, Entertainment, Lifestyle, SEO, Travel, USA, UK, Canada. Guest Blogging Solution.

  31. Software Development Company We specialize in Blockchain development, Artificial Intelligence, DevOps, Mobile App development, Web App development and all your customised online solutions. Get best impression at online by our services, we are familiar for cost effectiveness, quality, delivery and support.

  32. Thanks for sharing such a great information with us.Keep on updating us with these types of blogs.
    professional web design company in chennai
    top 10 web designing companies in chennai

  33. You have provided a useful information about Memory Monitor of apps. We can use the Memory Monitor to detect memory leaks through the your provided steps. Anyone can also write for us about this topic.

  34. Thanks for provide great informatic and looking beautiful blog, really nice required information & the things i never imagined and i would request, wright more blog and blog post like that for us. Thanks you once agianMarriage certificate in delhi
    Marriage certificate in ghaziabad
    Marriage registration in gurgaon
    Marriage registration in noida
    special marriage act
    Marriage certificate online
    Marriage certificate in mumbai
    Marriage certificate in faridabad
    Marriage certificate in bangalore
    Marriage certificate in hyderabad thanks once again to all.