Android: using heap before and after HONEYCOMB due to bitmaps?

Question

I am developing a graphical application for Android 2.2 and higher.

I know that starting with Honeycomb, bitmaps are saved to VM_HEAP instead of their own bitmap heap.

Does this affect the memory usage of my application? I mean, for example, if my application for pre-cell devices uses X MB of the VM heap and has Y MB bitmaps (stored in the native heap), then I hope that it does not start using X + Y MB from the VM heap if It is installed on a cellular or new device.

This does not sound logical. Instead, I assume that the size of the bitmap is counted against the limits of the virtual machine, even before Honeycomb, otherwise why would the "size of the bitmap exceed the VM budget"? Thus, they are stored on their native heap, but are still considered with the maximum size of VM_HEAP).

Answer 1

I was also worried, but I received a response from Google in the meantime, which confirmed my following assumption:

"This does not look like logic. Instead, I assume that the size of the bitmap is calculated against the limits of the virtual machine even before Honeycomb, otherwise why would the" size of the bitmap exceed the budget of VM "? Therefore, they are stored on their native heap but still calculated against the maximum file size VM_HEAP).

Reply from Romain Guy (Android Framework Engineer):

"That's right. Your application will use the same amount of memory as before and after Honeycomb."

Answer 2

AFAIK He was changed in the comb. Raster images are now stored in your dalvik heap (VM_HEAP), rather than the native heap, as in previous versions. (Perhaps because they no longer wanted to depend on the SKia GC)

Now you need to take care of more efficient management of bitmap images, since bitmaps that work well on 2.2 can give an OOM exception in 3.0, since the same image occupies more pixels on the tablet (it may not apply to 4.0, I'm not sure).