In my application, I'm careful not to make heap allocations in the main render loop, to prevent the garbage collector from having to do its thing.
After making a series of changes to my application, I suddenly see the garbage collector getting invoked every second or two, and it is freeing up around 400k of memory per invocation.
I look back at the changes that I made, and I don't have any explicit allocations happening on the render thread. So I run ddms and use the "Allocation Tracker" tool, but there are no allocations happening, other than the normal ones that are related to running ddms. And certainly not enough allocations shown for the 400k bytes that are apparently being garbage collected every second or so
(I had already found the solution but am posting the question+answer for other's benefit)
As it turns out, I was able to track the problem down to calling the .values() method of a enum class, which allocates a new array on every call. But for some reason, those allocations don't show up in ddms's allocation tracker, so it makes it rather difficult to track down.
Luckily, I was able to use git bisect to find the specific change that introduced the issue, and then tracked it down to the exact problem in that change.
Edit:
After some additional testing, it seems that cloning an array in general doesn't show up in the allocation tracker.
Additional Info:
This seems to be an issue in Honeycomb and below, when cloning an object. It will be fixed in ICS. (http://code.google.com/p/android/issues/detail?id=19831)
Please provide info about the kind of garbage colletor.
Bitmap allocation, meaning the actual bitmap pixels(not bitmap information which is very small) is allocated into the heap, BUT not visible to any allocation tracker tool for android version below 3.0 (Honeycomp). So if you are loading bitmap information GC extrernal allocation will be called.