Ok, as told on previous emails, I managed to reduce the heap use even
more sacrificing image definition on xdpi devices. The good news is that
most of the OOM crashes seems to gone, but the bad news is that NOT all
of them and the worst is that this kind of crashes in particular persists.
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
Hi,
I hardly could use less memory. Devices with high dpi and res needs more
memory so they can use HD images, that's why they have a higher heap limit.
Now if you cannot use all that heap size... it is just absurd!
I rather prefer that the problem were a bug on bugsense and this report
weren't
Well, getting mad of this issue or trying to blame something else,
wouldn't really benefit you, would it? 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
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
One thing about this...
Do you think this may be a problem of target SDK or so?
This is what I am using right now:
uses-sdk android:minSdkVersion=7 android:targetSdkVersion=15 /
And most of this problems (99% at least) seems to be ocurring in 4.0.3+
Android devices...
Does this says
- 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
targetSdk has an impact on the way things work, but in your example i dont
think it matters.
On Thursday, November 22, 2012 2:53:59 PM UTC+2, Fran wrote:
One thing about this...
Do you think this may be a problem of target SDK or so?
This is what I am using right now:
uses-sdk
On 11/22/2012 03:19 PM, Piren wrote:
- yeah, swearing does help calm the psyche, does not help so much with
the code crashing :-P
I admit you are right. But I need to calm my psyche before starting
coding!... ;-)
- it is unlikely i need so much memory Fact is you have an OOM
exception...
Hi,
I started having to deal with new OOM errors one of my camera apps again
recently.
First started when I got a new Samsung Galaxy S3 LTE with Android 4.1.0,
OOM occurring after reading in an 8MP photo ok then attempting to
allocate additional Bitmap to create a modified copy of the
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
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.
Beyond that, last I knew, Dalvik does not have a compacting garbage
collector. I
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
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,
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
I remember reading about a similar issue in the past and experienced the
same issue as well.
From what i recall, but dont
Bitmap data is not allocated in the Java heap but in a much smaller area of
native memory.
So you can have several MB of Java Heap free and still have Bitmap OOM.
Bitmaps are a total PITA to manage with Android. But it's doable.
Except that when you thnk you are done fixing all OOM, a new
As of 3.0 Bitmaps are allocated on Dalvik's heap.
On Nov 21, 2012 10:23 AM, b0b pujos.mich...@gmail.com wrote:
Bitmap data is not allocated in the Java heap but in a much smaller area
of native memory.
So you can have several MB of Java Heap free and still have Bitmap OOM.
Bitmaps are a
And they were not allocated in a smaller area. They used to be allocated
on the native heap but they counted against the Dalvik heap's usage (which
is why you would get OOM anyway.)
On Nov 21, 2012 10:23 AM, b0b pujos.mich...@gmail.com wrote:
Bitmap data is not allocated in the Java heap but in
18 matches
Mail list logo
