java.lang.OutOfMemoryError: bitmap size exceeds VM

I am developing an android app and as I read all around and learned for myself, I cant have a lot of images on the screen at the same time or I will get an exception.

The question is how many images or how many KB in images or how many layouts/images can I have at the same time in the screen.

I know this is not the only thing that has influence on memory, but I am looking for a number so I can plan around it.

Thanks

Daniel

Edit:

I just found this on the android dev site (http://developer.android.com/resources/articles/future-proofing.html)

Technique to Avoid, #3: Going Overboard with Layouts

Due to changes in the View rendering infrastructure, unreasonably deep (more than 10 or so) or broad (more than 30 total) View hierarchies in layouts are now likely to cause crashes. This was always a risk for excessively complex layouts, but you can think of Android 1.5 as being better than 1.1 at exposing this problem. Most developers won't need to worry about this, but if your app has very complicated layouts, you'll need to put it on a diet. You can simplify your layouts using the more advanced layout classes like FrameLayout and TableLayout.

I guess this can be my problem.

When it says 'broad' , is it saying on the last level ?

Thanks

Daniel

One of the most common errors that I found developing Android Apps is the

java.lang.OutOfMemoryError: Bitmap Size Exceeds VM Budget error.

I found this error frequently on activities using lots of bitmaps after changing orientation: the Activity is destroyed, created again and the layouts are “inflated” from the XML consuming the VM memory available for bitmaps.

Bitmaps on the previous activity layout are not properly deallocated by the garbage collector because they have crossed references to their activity. After many experiments I found a quite good solution for this problem.

First, set the id attribute on the parent view of your XML layout:

    <?xml version="1.0" encoding="utf-8"?>
    <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
     android:layout_width="fill_parent"
     android:layout_height="fill_parent"
     android:id="@+id/RootView"
     >
     ...

Then, on the onDestroy() method of your Activity, call the unbindDrawables() method passing a refence to the parent View and then do a System.gc()

    @Override
    protected void onDestroy() {
    super.onDestroy();

    unbindDrawables(findViewById(R.id.RootView));
    System.gc();
    }

    private void unbindDrawables(View view) {
        if (view.getBackground() != null) {
        view.getBackground().setCallback(null);
        }
        if (view instanceof ViewGroup) {
            for (int i = 0; i < ((ViewGroup) view).getChildCount(); i++) {
            unbindDrawables(((ViewGroup) view).getChildAt(i));
            }
        ((ViewGroup) view).removeAllViews();
        }
    }

This unbindDrawables() method explores the view tree recursively and:

Removes callbacks on all the background drawables
Removes childs on every viewgroup

This answer has 2 parts

1) its not how much images the screen has, but being carefull on cleaning everything up when finishing the activity

2) (Future-Proofing Your App)

Technique to Avoid, #3: Going Overboard with Layouts

Due to changes in the View rendering infrastructure, unreasonably deep (more than 10 or so) or broad (more than 30 total) View hierarchies in layouts are now likely to cause crashes. This was always a risk for excessively complex layouts, but you can think of Android 1.5 as being better than 1.1 at exposing this problem. Most developers won't need to worry about this, but if your app has very complicated layouts, you'll need to put it on a diet. You can simplify your layouts using the more advanced layout classes like FrameLayout and TableLayout.

Daniel

The amount of memory varies from device to device and the amount you have to play with depends on what else the system is doing at the time. Your best bet is to not even come close to running the system out of memory if you can help it. What are you doing that you need that many images on the screen?

This thing is depends on the HEAP size of phone . so if your application acquire more heap then phone provided then it may be create a problem .

the new generation android device contain .here is the list of some

HTC Wildfire (2.2.1) = 16MB.
HTC Wildfire S (2.3.5) = 20MB.
HTC Salsa (2.3.3) = 20MB.
HTC Desire (2.3.3) = 32MB.
HTC Desire S (2.3.5) = 32MB.
Samsung Galaxy S GT-I9000 (2.2) = 48MB.
Samsung Galaxy R GT-I9103 (2.3.5) = 64MB.
Samsung Galaxy Y GT-S5360 (2.3.5) = 64MB

so there is not certan solution for it , but you can try to optimize the the bitmap size . for example recycle the bitmap after use it . or make another using bitmapFectory deoeed from sampleSize .

IF you are using a emulator then you can create a device which contain more heap size to Add new extra hardware configure in your avd manager as VM heap size = 32 or up .