Yep, makes no sense at all, but thats how it is. Maybe we can ask Romain to give Dianne a call and get a response :-P
I tried finding that thread that mentioned this Dalvik bug/feature but no luck... i did come across Romain's famous "use less memory" quote :-P (http://code.google.com/p/android/issues/detail?id=8488&can=1) Which oddly, in your case does apply... As i said, the best trick i've found is just not to get the heap so large. On Wednesday, November 21, 2012 7:31:06 PM UTC+2, Fran wrote: > > Hi, > > That has no sense at all. I do not mean that you are not right, just mean > that in such case it is a mighty bug... > > Best regards, > > 2012/11/21 Piren <gpi...@gmail.com <javascript:>> > >> I remember reading about a similar issue in the past and experienced the >> same issue as well. >> From what i recall, but dont take my word for it, even if there is room >> in the heap and it isnt fragmented beyond belief, Dalvik first checks if >> the heap can be enlarged to include the needed space, instead of trying to >> use the space it has free. >> >> Since you're already at 48MB, you've just pushed through the limit with >> the new needed allocation (regardless of the fact you have the space), and >> Dalvik throws the OutOfMemoryException. I had it happen to me as well. >> >> Only solution i've found? to never get the heap so large it sits on the >> edge (stupid bug, stupid solution, i know). >> >> I think Dianne Hackburn mentioned that, maybe a google search will find >> it. >> >> >> On Wednesday, November 21, 2012 5:18:33 PM UTC+2, Fran wrote: >> >>> On 11/21/2012 03:58 PM, Mark Murphy wrote: >>> >>> First, you do not know necessarily what BitmapFactory.Options are being >>> specified on the decodeResource() call, as that does not appear to be >>> called from your code, and it could be they have strange values in there. >>> >>> Well, as far as my own code reaches (AndroidGraphics.java:77), I do set >>> these options. >>> >>> Options options = new Options(); >>> options.inPreferredConfig = Config.ARGB_8888; >>> options.inScaled = false; >>> >>> [...] >>> >>> bitmap = BitmapFactory.decodeResource(**this.context.getResources(), >>> resourceId, options); >>> >>> Beyond that, last I knew, Dalvik does not have a compacting garbage >>> collector. I haven't seen a recent statement as to whether or not that >>> limitation has been fixed. If it is still the case, though, your issue may >>> not so much that you are out of memory, but that there is no single >>> contiguous block that meets your needs. >>> >>> Well, it may happen, but the evidence on that is really weak. The game >>> has just started and it is loading the main menu screen, with only a few >>> objects in memory, so it is unlikely that in these circunstances and with >>> 15Mb of free heap an image of just 1M5 as raw ARGB_8888 will not find an >>> slot. >>> >>> On Wed, Nov 21, 2012 at 9:48 AM, Francisco Marzoa <fmma...@gmail.com>wrote: >>> >>>> Look at this: >>>> >>>> 0java.lang.OutOfMemoryError: (Heap Size=48547KB, Allocated=33541KB) >>>> 1at android.graphics.**BitmapFactory.**nativeDecodeAsset(Native Method) >>>> 2at android.graphics.**BitmapFactory.decodeResource(** >>>> BitmapFactory.java:595) 3at com.badlogic.androidgames.** >>>> framework.impl.**AndroidGraphics.newPixmap(**AndroidGraphics.java:77) >>>> 4at com.badlogic.androidgames.**framework.impl.** >>>> AndroidGraphics.newPixmap(**AndroidGraphics.java:133) 5at >>>> net.iberdroid.**ruletaafortunadacore.**MainMenuScreen.loadImages(** >>>> MainMenuScreen.java:255) 6at net.iberdroid.**ruletaafortunadacore.** >>>> MainMenuScreen.enable(**MainMenuScreen.java:241) >>>> The image that I am trying to load at MainMenuScreen.java:255 >>>> >>>> The weird thing is that there is free heap enough for loading that >>>> image: it is a 800x480 png indexed but with transparency, so I load it >>>> using four bytes per pixel (ARGB) and it should use about 1M5 of memory as >>>> a raw bitmap... but it crashes anyway trying to load an image ten times >>>> smaller the available heap space (48-35 = 15Mb). >>>> >>>> These things makes me crazy... >>>> >>>> Bests, >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Android Developers" group. >>>> To post to this group, send email to android-d...@**googlegroups.com >>>> >>>> To unsubscribe from this group, send email to >>>> android-developers+**unsubscr...@googlegroups.com >>>> For more options, visit this group at >>>> http://groups.google.com/**group/android-developers?hl=en<http://groups.google.com/group/android-developers?hl=en> >>>> >>> >>> >>> >>> -- >>> Mark Murphy (a Commons Guy) >>> http://commonsware.com | http://github.com/commonsguy >>> http://commonsware.com/blog | http://twitter.com/commonsguy >>> >>> _The Busy Coder's Guide to Android Development_ Version 4.3 Available! >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Android Developers" group. >>> To post to this group, send email to android-d...@**googlegroups.com >>> >>> To unsubscribe from this group, send email to >>> android-developers+**unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/**group/android-developers?hl=en<http://groups.google.com/group/android-developers?hl=en> >>> >>> >>> >>> -- >> You received this message because you are subscribed to the Google >> Groups "Android Developers" group. >> To post to this group, send email to >> android-d...@googlegroups.com<javascript:> >> To unsubscribe from this group, send email to >> android-developers+unsubscr...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en >> > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
