- yeah, swearing does help calm the psyche, does not help so much with the code crashing :-P
- "it is unlikely i need so much memory" Fact is you have an OOM exception... you're using too much memory:) And if its happening on your first activity, it isnt a memory leak... - i dont know if largeHeap is useful, but according to documentation, it should at least lower the amount of crashes some of your users experience. - if i were your user, i'd take hdpi images rather than crashes. if it crashes, i dont use the app :) On Thursday, November 22, 2012 2:51:04 PM UTC+2, Fran wrote: > > On 11/22/2012 12:48 PM, Piren wrote: > > Well, getting mad of this issue or trying to blame something else, > > wouldn't really benefit you, would it? > Actually yes: it would not solve my crashes, but helps me to unload a > bit of stress, you know... ;-D > > Also swearing is not incompatible with coding, I am doing both things at > same time ;-) > > Absurd as much as it is, thats most likely what you got. > > > > If you're so pressed on using so much memory, you can also resolve > > this issue by allocating it in a different manner. This issue is > > raised because the heap grew to 48MB prior to allocating the offending > > bitmap, not because that bitmap is too big... if you can change the > > way you do things so you'll never get to needing 48MB at the same time, > It is unlikely I need so much memory. In all the test I did, I never > used more than 30Mb. I do not know what determines the step that makes > the heap grow, but may be I just need 32Mb and the system decides to > allocate 48Mb by itself. > > Anyway we are not sure about this being the source of the problem. As > told, I cannot discard even that heap information passed by Bugsense is > inaccurate. > > Of course the crash is there, but the reason may be different and have a > more rational solution. > > you'd avoid the issue. This is how i resolved it, just changed the > > order of things i do and used stricter control on my memory allocation > > so i'll never inflate the heap so much. If you have 15mb free at the > > moment of the crash, it might indicate that you never needed to > > increase the heap to that size anyway. Imagine you're playing memory > > sokoban :) > > you can also: > > - use largeHeap=true and cross your fingers > This is useful at all? I mean, I do no think such devices will have a > heap bigger than those 48Mb (that as seen SHOULD be more than enough for > my app...) > > - use added code to limit the requested bitmap quality dependent on > > heap size. lower quality is better than crashing. > Well, this is more or less what I am doing right now, but it will make > users experience worse than they should be: they buy a xdpi screen, and > they will see only hdpi images... :-| > > And the worst is that I am not sure that this will solve the OOM > problems, and some users complain about updating to often -probably > those that are not affected by crashes-, but it is better than spending > $6000 in different phones for testing that may -or not- fail for real > debugging. > > - allocate the needed space on native memory manually. Although i > > haven't done the same, i understand that when using native your limits > > go up > > - Come to terms with random crashes but enjoy your HD backgrounds > > while they show:) > :-) > > -- 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
