Thanks for pointing out the high memory consumption when loading the game level…this version of the benchmark was accidentally using the wrong model (well, actually it’s the correct model, but i used the one serialized for the desktop version of jPCT, which was overkill for Android). I’ve fixed this, memory usage should be much lower now.
However, that’s not the real problem, because i never got any crashes while loading the level but only when loading the textures (which happens before loading the level itself) and while showing the result screen. In both cases, memory is pretty empty…maybe 2.5 MB are in use then…but it still couldn’t create those bitmaps/dialog box for whatever reason from time to time.
Hmm. Well, unfortunately I don’t have the answers on this. I’ve succeeded to a large extent with eliminating OOM errors on my apps by a strict regime of trimming the graphics, going banzai on memory leaks, and strictly controlling the graphics in memory as mentioned above (having one module that controls all the graphics loading/cleaning is probably the key for me - once everything is loaded once, the apps memory usage remains stable).
Regarding your memory usage of 2.5mb - that sounds very low for the amount of graphics you are using. Are you sure that you are seeing the memory usage including bitmaps (you need to run “adb shell procrank” - heap dumps won’t give you this information)?
The native heap GC is extremely slow, so I suppose that it is not impossible that you could be getting inside its GC cycle if you are loading/cleaning out bitmaps rapidly enough (as I suggets above). However, I’ve (fortunately) yet to find a problem that suggests it is a real issue - the problems I’ve traced down have ultimately all been down to memory leaks somewhere in either my own or Google’s code - and the stuff that I know of in the Android OS has been fixed in the latest OS versions.