So, I tested my game out for the first time with the Monkey test. I managed to go about 3 minutes without a crash, but I ended up crashing with an out of memory error, and I'm trying to figure out how I might make it better.

My program is structured as follows:

There is a front screen which will start an activity.

The secondary activity is where most of the action is, and also where I crashed.

I crash on an inflate command

My game forces portrait mode, it was easier to make 1 layout than 2 work...

There are a number of class variables associated with my secondary activity. I'll include the non-static ones below. I've also included some kind of a clue for those things which aren't obvious as to what they are.

What I'm wanting to know is how I can improve the memory management of my program so it won't crash. I suspect that I need to manually delete some of these variables, but I'm not sure what the right place to do so is. Thanks!

It would be nice to know where in your code you got the OOM. If you can, post a stacktrace and relevant piece of code. Not really related, but according to the Java naming convention variables should not have an underscore (unless it is a static final) but rather be written together with the first letter in the next word capitalized: docs.oracle.com/javase/tutorial/java/nutsandbolts/…
–
JaveMar 29 '12 at 13:22

@Jave: Included the line with the out of memory. I should learn Java conventions someday as well, I might work on that...
–
PearsonArtPhotoMar 29 '12 at 13:25

And what does the R.layout.level_layout contain? Large images or similiar?
–
JaveMar 29 '12 at 13:26

@Jave: Quite a few things, but several image views, image buttons, text views, etc. None of them are particularly large, but I suppose they add up.
–
PearsonArtPhotoMar 29 '12 at 13:31

I have a fair idea as to what is consuming memory, but I'm not quite sure what I need to do about it...
–
PearsonArtPhotoMar 29 '12 at 13:50

You need to know exactly which component is causing your memory problem, than you can concentrate on fixing that. You can adjust your scope, to ensure the variables are created\deleted at the right time, you can also cache some of the frequently accessed items in memory, to ensure you are only creating a single instance.
–
BoogerMar 29 '12 at 13:57

So it turns out, I was right on the hairy edge of the Heap. I am using quite a few images, and it turns out that I was over the "normal" heap size. I've managed to improve this situation by shrinking some of the images, but the best solution came by changing my manifest to the following:

The large heap will allow me to do future upgrades (Which will include level designs, etc, which would take up quite a bit of space...) All in all, it should be a pretty minimal affect.

I selected @Booger's answer as this was the piece which allowed me to do some research and figure out that my heap space just wasn't large enough, but I also included @Ramam-Mystry's piece of code.

I also used many answers from this excellent question in my quest. I started to store references instead of bitmaps, and a few other related bits. All in all, my memory consumption is down 25%, and continuing to improve.

Another tip could be to use the onLowMemory() function in Activity, trim the memory that's not needed then.

Try by using System.gc(); in onresume() to avoid memory leaks on using high resolution or high memory pictures in imageview.

Note:
For imageviews using bitmaps, default garbage collection is not called, so the execution memory exceeds the allocated memory when images memory is higher. manual garbasge collection to be done to avoid memory leak. it is better to call in onresume();