Android VM Won't let us allocate xx bytes

Question

I'm working on a android game. Problem starts when I try to use 3 images for background. Images are 1280x720px and 100kb large. The images are really not that big, so I'm bit confused why they should cause memory problem.

Note: Screen resolution is 800x400 so I cant really resize image by factor 2 as it is suggested on android developer Note: I'm using HTC desire phone (here crash comes), I've also tried it on Samsung Galaxy S1 and on Samsung it works OK.

I've analysed memory in DDMS and what is strange is I found that Heap is only 3.5mb large. If I check rt.MaxMemory() it says I have around 25mb of space per app.

What comes to my mind is that heap isn't "updating" fast enough to accommodate for larger photos/apps, so it crashes before it can load images despite being so small. Is there any way to manualy set heap size, or at least tell it to enlarge?

Here is code where I load images:

        Bitmap floorFront = BitmapFactory.decodeResource(host.getResources(), R.drawable.floor1);
        floorFront = Bitmap.createScaledBitmap(floorFront,host.realWidth,host.realHeight, true);
        floorFront = Bitmap.createBitmap(floorFront, 0, host.realHeight/2, host.realWidth, host.realHeight/2);
        host.addInstance(new Background(0,host.realHeight/2,host,floorFront,1));

        Bitmap floorBack = BitmapFactory.decodeResource(host.getResources(), R.drawable.sand);
        floorBack = Bitmap.createScaledBitmap(floorBack,host.realWidth,host.realHeight, true);
        floorBack = Bitmap.createBitmap(floorBack, 0, host.realHeight/2, host.realWidth, host.realHeight/2);
        host.addInstance(new Background(0,host.realHeight/2,host,floorBack,4));

        Bitmap floorRock = BitmapFactory.decodeResource(host.getResources(), R.drawable.foreground);
        floorRock = Bitmap.createScaledBitmap(floorRock,host.realWidth,host.realHeight, true);
        floorRock = Bitmap.createBitmap(floorRock, 0, host.realHeight/2, host.realWidth, host.realHeight/2);
        host.addInstance(new Background(0,host.realHeight/2,host,floorRock,0));

Here is exact error from LogCat:

 maxMemory:25165824
 memoryClass:24
 6144000-byte external allocation too large for tgis process.
 Out of memory: Heap Size=4739KB, Allocated=2399KB, Bitmap Size=18668KB
 VM won't let use allocate 6144000bytes

EDIT: Now that you said it makes sense that bitmaps use “raw” size of image and not compressed. And after some research it seems that on android 2.2 and 2.3 bitmaps are not stored in heap therefore heap doesn’t increase after image is loaded.

I have one more question. We use those 3 images for background. We will now resize them a bit in vertical direction, but in horizontal we still kind of need them as they are. So the image will still be around 100x720px. The problem why we need 3 images is, so we can draw them separately and get layers effect (we can draw something between 2 images). What would be the best way to implement this to get desirable effect with as little of memory to use as possible?

Background: Middle: Foreground

Note: This are just static backgrounds, animation happens around and between them.

Communal

How much memory is used if you create only 1 of the 3? – Unpriced

for 1 it is around 2.5mb, if I open 2 or 3 it crashes. – Communal

Where does the 18Mb 'bitmap size' happen? That's not 3x of 2.5 – Unpriced

It hapens at 3rd line of "cluster": Bitmap.createBitmap... That's the problem, I don't understand how it can come near 3MB, but even if it would be 3MB that is 8times smaller than maximum size of HTC desire. – Communal

Answer 1

I'm not sure where you get that a 1280 x 720 pixel bitmap is 100KB. It's really several megabytes. In bytes it is 1280 * 720 * however many bytes per pixel, usually 4 for images with transparency, or 2 for images without. It's a huge amount of data for a cell phone to load. Maybe you are quoting the size of a compressed image format version such as PNG.

Some tips to deal with memory usage problems:

Use Bitmap.Config.RGB_565 input format on your factory if you don't have any transparency. This saves space versus ARGB_8888.

Set largeHeap to true on the application element in your AndroidManifest.xml.

Make sure your bitmaps are not being scaled automatically based on devices density class. Place them in drawable-nodpi, for example, or disable the automatic scaling programatically, or provide a different bitmap for each density class in multiple drawable folders. If your bitmap is only in the drawable folder, it is going to get scaled 2x on XHDPI devices.

Recycle bitmaps you are not using, e.g.:

Bitmap floorFront = BitmapFactory.decodeResource(host.getResources(), R.drawable.floor1);
Bitmap floorFrontScaled = Bitmap.createScaledBitmap(floorFront,host.realWidth,host.realHeight, true);
floorFront.recycle();
floorFront = null;

Bitmap floorFrontCropped = Bitmap.createBitmap(floorFrontScaled, 0, host.realHeight/2, host.realWidth, host.realHeight/2);
host.addInstance(new Background(0,host.realHeight/2,host,floorFrontCropped,1));

You can also manually run System.gc() at times. The system is supposed to do that for you before returning an OutOfMemoryError, but it doesn't with bitmaps in Android because they have memory allocated outside Java.

Note that when you read in a Bitmap, you can actually check if the size you need it at is a whole number divisor less than its size, then specify the factory should skip over pixels when loading. This can help on smaller resolution devices, which have correspondingly smaller memory limits.

If you are not moving these background images separately, then draw them all to a single bitmap and use that instead of three at once.

Khedive

Setting android:largeHeap in the manifest does not "reduce memory usage". It requests that this application have more heap space, to the detriment of other apps (and perhaps the user). While it is a valid technique, it should be a technique of last resort, and one used only for apps that can justify this behavior to the user. – Ie

Yes, I know what it does. I corrected the heading text for the tips, thanks. Honestly, OOME crashes on Android are rampant in my crash reporting tools due to the garbage collector not tracking this stuff, so really any workaround is best for users at this point. This looks like a game with a parallax scrolling background anyway, and gamers expect to push their hardware to the limit. – Khedive

Thanks, it is clear now where memory error comes from. Do you have any more suggestions on how to solve the problem? I edited my first post. – Communal

Honestly, in many of my more complex apps that don't use OpenGL or some mature technology and have to use Google's crashy Bitmap/View crap, I'm changing anything that is dynamically scaled into fixed sizes per density class. So if you have a score bar, for example, size it to 48dp (and provide a pre-sized version for each density class in drawable-ldpi, drawable-mdpi, etc.) instead of sizing it to 1/5th the screen (by layout_weight or whatever) or some other dynamic size. This is sort of a last resort after you add immediate manual recycling and working with one Bitmap at a time, though. – Khedive

Someone in a related reddit thread pointed out some additional tips, setting BitmapFactory.Options#inPurgeable to allow the image to be cleared out instead of the app crashing, and also checking available memory and reducing sizes based on that: reddit.com/r/androiddev/comments/11a5sn/… – Khedive

@LanceNanek as of Google docs "(inPurgeable) This field was deprecated in API level 21. As of LOLLIPOP, this is ignored." – Zurek

Ah, yes, the above is from years ago. A lot has changed. If you read the docs you'll see: > As of Android 3.0 (API level 11), the pixel data is stored on the Dalvik heap along with the associated bitmap. [ developer.android.com/training/displaying-bitmaps/… ] So dealing with bitmaps on android isn't as bad as it used to be. – Khedive