Develop Reference

What does it mean if totalMemory is small, but totalPss is very huge?

We have a problem with our app. Over time we have noticed that the totalPss value gets very large (depending on the device, it will be 300-700Mb):
int pid = android.os.Process.myPid();
int pids[] = new int[1];
pids[0] = pid;
android.os.Debug.MemoryInfo[] memoryInfoArray = activityManager.getProcessMemoryInfo(pids);
if (memoryInfoArray.length > 0)
{
android.os.Debug.MemoryInfo thisProcessMemoryInfo = memoryInfoArray[0];
Log.d("totalPss", thisProcessMemoryInfo.getTotalPss()+"");
}
Here is a graph showing results from a typical run:
But, at the same time, the totalMemory value never gets very large (40-50Mb at max, but falls to 10Mb after GC).
Log.d("totalMem", Runtime.getRuntime().totalMemory()+"");
Here is a graph showing that from the same run as above (please ignore the units, it is actually in bytes):
getMemoryClass for this device indicates that we have 192Mb available for the app:
Log.d("getMemoryClass", activityManager.getMemoryClass()+"");
Our memory usage pattern is to make a number of large allocations over time which are frequently released. After a long time of this, a large allocation will fail which typically causes the app to fail.
It seems like we are probably having fragmentation, does this seem correct? Can we resolve this by using the largeHeap attribute (my intuition is that it would not)? Are there any tools to help diagnose this more certainly?

Possible bug in dalvik of Android 2.x during Bitmap allocation?

The phenomenon: First do allocation some big memory blocks in the Java side until we catche OutOfMemoryError, then free them all. Now, weird things happen: load even a small picture(e.g. width:200, height:200) by BitmapFactory.decodeXXX(decodeResource, decodeFile, ...) will throw an OutOfMemoryError! But its OK to alloc any pure Java big Object(e.g. new byte[2*1024*1024]) now!
Verifying: I wrote some simple codes to verify the problem that can download here, press "Alloc" button many times and you will got an OOF Error, then press "Free All", now the environment is set up. Now you can press "LoadBitmap" and you will see its not work on most of Android 2.x phone.(But in the emulator its just OK, odd)
Digging deeper: I try to dig into some dalvik code to find out why, and find a possible bug in function externalAllocPossible in HeapSource.c which called by dvmTrackExternalAllocation who print the "xxx-byte external allocation too large for this process" messages in LogCat.
In externalAllocPossible it simply wrote:
if (currentHeapSize + hs->externalBytesAllocated + n <=
heap->absoluteMaxSize)
{
return true;
}
return false;
Which means once if the native Bitmap allocation size plus the currentHeapSize(NOT the actually allocated size as shown below, in this case, it's keeping the max size of the heap we bumped up but then freed them all) exceeds the limits, native Bitmap allocation will always fail, but the currentHeapSize in Java seems NOT decrease even when 91.3% Java objects' memory have been freed(set to null and trigger GC)!
Is there anybody else met this problem too?

I think this is correct. Its forcing the entire app (Java+native) take no more than a certain amount of memory from the OS. To do this it has to use the current heap size, because that amount of memory is still allocated to the app (it is not returned to the OS when freed by GC, only returned to the application's memory pool).
At any rate, 2.x is long dead so they're not going to fix it there. They did change how bitmaps store their memory in 3.x and 4.x. Your best bet is to allocate all the bitmaps you use first, then allocate those large structures. Or better yet- throw those large structures into a fixed size LRUCache, and don't use the grow until out of memory idea, instead load new data only when needed.

The class Bitmap has the recycle() method, described as:
Free the native object associated with this bitmap...
The reason behind this method is that there are two heaps: the Java heap and the heap used by native code. The GC only sees the Java heap sizes; for GC, a bitmap may look as a small object because it's size on the Java heap is small, despite the fact that it references a large memory block in the native heap.

Grow Heap problems in Android

I got problems about grow heap which I have 2 questions to ask.
First, How can I suppose to check current grow heap in my devices?
Second, How can I decrease my grow heap size to prevent out of memory error?

Do you mean you want to check the total size of the heap your application can use? Or how much free memory is left in the heap?
To see the total size of the heap you could call
Runtime rt = Runtime.getRuntime();
long maxMemory = rt.maxMemory();
Log.v("onCreate", "maxMemory:" + Long.toString(maxMemory));
This will tell you how much memory in bytes your app is allowed to use (source)
To find out how much is left you could do the following
When are you getting out of memory errors? A starting point could be to override onLowMemory() method...

Memory metrics in android apps

I wrote Android application and it have some strange problems with Out Of Memory exception, which appears randomly. Yes, I know that problems with OOM exception usually because of images, and I used all what I can to avoid this problem.
The only way I could think to find the place where spend the memory is putting the logs with information about memory everywhere. But I really confused about which values ​​do I need.
I used next values:
Runtime.getRuntime().maxMemory()
Runtime.getRuntime().freeMemory()
Runtime.getRuntime().totalMemory()
Debug.getNativeHeapAllocatedSize()
Debug.getNativeHeapFreeSize()
Debug.getNativeHeapSize()
And before OOM exception I have next values:
maxMemory: 57344K
freeMemory: 9581K
totalMemory: 22407K
NativeHeapAllocatedSize: 34853K
NativeHeapFreeSize: 302K
NativeHeapSize: 40060K
lowMemory false
In this question Android Bitmap Limit - Preventing java.lang.OutOfMemory I see that used compeering ((reqsize + Debug.getNativeHeapAllocatedSize() + heapPad) >= Runtime.getRuntime().maxMemory()) ant in this blog some strange information:
Debug.getNativeHeapFreeSize(); The free size is the amount of memory
from the heap that is not being used, because of fragmentation or
provision.
Also I can not understand haw can be OOM exception if (totalMemory: 22407K) much less than (maxMemory: 57344K).
Please help me understand how use this values.

View ddms heap size

In relation to this topic Android: OutofMemoryError....
How Can you see the heap size on ddms (Eclipse)? I can only track allocations and it doesn't show nothing

You can try from code native heap allocation : Debug.getNativeHeapAllocatedSize()

this shows max heap memory of device
Runtime rt = Runtime.getRuntime();
long maxMemory = rt.maxMemory();
this is for heap required by your app
Runtime rt = Runtime.getRuntime();
long maxMemory = rt.maxMemory();