Re: [android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
None of the tools I know work well with images and I'm not sure how to improve that. One way might be to use adb shell tools like dumpsys and compare the numbers over time, I heard. Not very convenient. I'm checking the difference between PNG8 and PNG24 now. From my understanding this could save some memory. BR, Seb On Fri, Jun 18, 2010 at 5:00 AM, Nathan critter...@crittermap.com wrote: Are any of those tools helpful with bitmaps? I've analyzed an HPRof where all the bitmaps are taking up32 bytes. that would be nice if it were true. I know that bitmaps are not on the regular heap, so the tools don't seem to find them. Since the bitmaps are marked as purgeable, they could be taking only 20K bytes, or as much as 256K bytes, so there is a wide range. Nathan On Jun 17, 8:35 am, Sebastian Roth sebastian.r...@gmail.com wrote: Yup. We've been running in that case too many times. Invest in a good tool like Yourkit, use HPROF Heap dumps to find the objects with the sticky connects to JVM root and prepare to spend nights on trying again and again.. I recommend writing automated Unit-Tests for that as well. So that you can call certain activities 100 times and see whether they retain in memory or not. Very helpful for us. Also check basics like background pictures can be encoded as JPG instead of PNG to save some memory... BR -- 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.comandroid-developers%2bunsubscr...@googlegroups.com 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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
Hi Romain, Is there a list somewhere of devices with 24Mb per process ? Is there a way to adjust this in the emulator ? Is there an API method allowing to know the total memory available for the process ? I'm writing a pictures manipulating app, and handling hires pics is hard with only 16Mb. New devices with high megapixels camera sure need more. Thank you, Kevin On 17 juin, 09:33, Romain Guy romain...@android.com wrote: When you get such an error it's because *your* process is running out of memory. Other processes have nothing to do with it. You are using too much memory in your process and blowing past the heap limit (16 MB or 24 MB depending on the device you're using.) On Thu, Jun 17, 2010 at 12:07 AM, Amit magic.man.a...@gmail.com wrote: Hi java.lang.OutOfMemoryError: bitmap size exceeds VM budget I am getting this message in my log. As I investigated and found out while loading contact image this error comes.I checked size of the image file and it was normal so came to a conclusion that other processes filling up the memory and hence at the time this image is being loaded ,VM running low of memory. My question is that, is there any tool to figure out which process is responsible for occupying memory so that we can look into the process for the exact reason. Thanks, Amit -- 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 -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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
Re: [android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
Hi Kevin: I think the memory for high megapixel images is not so important because u usally will stream the image through a InputStream onto disk. You can then read the image via BitmapFactory and set a inSampleSize to retrieve it. BR, Seb, starting up a WIKI for android memory issues.. On Fri, Jun 25, 2010 at 2:32 PM, Kevin Gaudin kevin.gau...@gmail.comwrote: Hi Romain, Is there a list somewhere of devices with 24Mb per process ? Is there a way to adjust this in the emulator ? Is there an API method allowing to know the total memory available for the process ? I'm writing a pictures manipulating app, and handling hires pics is hard with only 16Mb. New devices with high megapixels camera sure need more. Thank you, Kevin On 17 juin, 09:33, Romain Guy romain...@android.com wrote: When you get such an error it's because *your* process is running out of memory. Other processes have nothing to do with it. You are using too much memory in your process and blowing past the heap limit (16 MB or 24 MB depending on the device you're using.) On Thu, Jun 17, 2010 at 12:07 AM, Amit magic.man.a...@gmail.com wrote: Hi java.lang.OutOfMemoryError: bitmap size exceeds VM budget I am getting this message in my log. As I investigated and found out while loading contact image this error comes.I checked size of the image file and it was normal so came to a conclusion that other processes filling up the memory and hence at the time this image is being loaded ,VM running low of memory. My question is that, is there any tool to figure out which process is responsible for occupying memory so that we can look into the process for the exact reason. Thanks, Amit -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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.comandroid-developers%2bunsubscr...@googlegroups.com 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
Re: [android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
That's right but there is some limitation though. I can't find a way to zoom on a detail of an hires JPEG, for example. Kevin On Fri, Jun 25, 2010 at 8:41 AM, Sebastian Roth sebastian.r...@gmail.comwrote: Hi Kevin: I think the memory for high megapixel images is not so important because u usally will stream the image through a InputStream onto disk. You can then read the image via BitmapFactory and set a inSampleSize to retrieve it. BR, Seb, starting up a WIKI for android memory issues.. On Fri, Jun 25, 2010 at 2:32 PM, Kevin Gaudin kevin.gau...@gmail.comwrote: Hi Romain, Is there a list somewhere of devices with 24Mb per process ? Is there a way to adjust this in the emulator ? Is there an API method allowing to know the total memory available for the process ? I'm writing a pictures manipulating app, and handling hires pics is hard with only 16Mb. New devices with high megapixels camera sure need more. Thank you, Kevin On 17 juin, 09:33, Romain Guy romain...@android.com wrote: When you get such an error it's because *your* process is running out of memory. Other processes have nothing to do with it. You are using too much memory in your process and blowing past the heap limit (16 MB or 24 MB depending on the device you're using.) On Thu, Jun 17, 2010 at 12:07 AM, Amit magic.man.a...@gmail.com wrote: Hi java.lang.OutOfMemoryError: bitmap size exceeds VM budget I am getting this message in my log. As I investigated and found out while loading contact image this error comes.I checked size of the image file and it was normal so came to a conclusion that other processes filling up the memory and hence at the time this image is being loaded ,VM running low of memory. My question is that, is there any tool to figure out which process is responsible for occupying memory so that we can look into the process for the exact reason. Thanks, Amit -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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.comandroid-developers%2bunsubscr...@googlegroups.com 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.comandroid-developers%2bunsubscr...@googlegroups.com 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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
Are any of those tools helpful with bitmaps? I've analyzed an HPRof where all the bitmaps are taking up32 bytes. that would be nice if it were true. I know that bitmaps are not on the regular heap, so the tools don't seem to find them. Since the bitmaps are marked as purgeable, they could be taking only 20K bytes, or as much as 256K bytes, so there is a wide range. Nathan On Jun 17, 8:35 am, Sebastian Roth sebastian.r...@gmail.com wrote: Yup. We've been running in that case too many times. Invest in a good tool like Yourkit, use HPROF Heap dumps to find the objects with the sticky connects to JVM root and prepare to spend nights on trying again and again.. I recommend writing automated Unit-Tests for that as well. So that you can call certain activities 100 times and see whether they retain in memory or not. Very helpful for us. Also check basics like background pictures can be encoded as JPG instead of PNG to save some memory... BR -- 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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
Hi Matt, you could try explicitly freeing the resources your bitmaps use by invoking Bitmap.recycle(). The description of this method reads Free up the memory associated with this bitmap's pixels, and mark the bitmap as dead, meaning it will throw an exception if getPixels() or setPixels() is called, and will draw nothing. This operation cannot be reversed, so it should only be called if you are sure there are no further uses for the bitmap. This is an advanced call, and normally need not be called, since the normal GC process will free up this memory when there are no more references to this bitmap. I found it quite useful when I ran into a similar issue. On 25 Nov., 18:37, Matt Kanninen mathias...@gmail.com wrote: -- 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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
If you're nulling your static bitmap in onPause why is it static to begin with? E.g. to have access to bitmaps outside of my activity, in classes that don't have reference to my activities. Or, in case there can be multiple instance of an activity, these instances can share 'expensive' data. But this requires something a bit more sophisticated than just nulling the static in the 'onDestroy ()'. In my gallery app i use static caches of thumbnails that are capacity limited. These caches manage themselves and don't rely on onPause or onDestroy. I do catch OutOfMemoryExceptions then clean these caches explicitly and try the operation that threw the execption again. So far, this has been working for me :) On Dec 10, 8:27 pm, Matt Kanninen mathias...@gmail.com wrote: I don't get it. If you're nulling your static bitmap in onPause why is it static to begin with? Also what you want to do is probably very different for a game that is basically all taking place in one activity and trying to avoid garbage collecting at all, compared to your standard Android app with an activity per screen. On Dec 10, 4:53 pm, Streets Of Boston flyingdutc...@gmail.com wrote: Statically held (caches of) bitmaps may come in very very handy. However, as soon as you do hold static references to 'expensive' resources, be sure to have a proper clean-up strategy. E.g. make sure the capacity of your cache of bitmaps is limited. Be sure to set the static reference to null when the activity is destroyed or paused, etc. On Dec 10, 6:05 pm, Matt Kanninen mathias...@gmail.com wrote: I recommend the only things you make static be strings, and that for everything else you are considering making static, instead write it to file and use static methods, that expect to be passed a context, to access the data. I think my problems might be camera related, so my plan is to stop using our own camera related activites and just use an intent to launch the camera, and then read the returned result. On Dec 10, 1:05 pm, fadden fad...@android.com wrote: On Dec 8, 12:28 pm, skominac stevan.komi...@gmail.com wrote: So not only is memory of static members not deallocated (which is actually not surprising), but the static references are still alive, pointing to the memory, and can be used to invoke the members back. This last part was surprising to me. This is actually not bad, as long as developers are aware of it. Is this Dalvik's feature? This is the expected behavior. Keep in mind that the VM doesn't shut down between runs of your activity. You are not necessarily starting with a clean slate.- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text - -- 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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
You catch out of memory? I wasn't willing to do that yet, but it would solve all my problems... On Dec 11, 7:09 am, Streets Of Boston flyingdutc...@gmail.com wrote: If you're nulling your static bitmap in onPause why is it static to begin with? E.g. to have access to bitmaps outside of my activity, in classes that don't have reference to my activities. Or, in case there can be multiple instance of an activity, these instances can share 'expensive' data. But this requires something a bit more sophisticated than just nulling the static in the 'onDestroy ()'. In my gallery app i use static caches of thumbnails that are capacity limited. These caches manage themselves and don't rely on onPause or onDestroy. I do catch OutOfMemoryExceptions then clean these caches explicitly and try the operation that threw the execption again. So far, this has been working for me :) On Dec 10, 8:27 pm, Matt Kanninen mathias...@gmail.com wrote: I don't get it. If you're nulling your static bitmap in onPause why is it static to begin with? Also what you want to do is probably very different for a game that is basically all taking place in one activity and trying to avoid garbage collecting at all, compared to your standard Android app with an activity per screen. On Dec 10, 4:53 pm, Streets Of Boston flyingdutc...@gmail.com wrote: Statically held (caches of) bitmaps may come in very very handy. However, as soon as you do hold static references to 'expensive' resources, be sure to have a proper clean-up strategy. E.g. make sure the capacity of your cache of bitmaps is limited. Be sure to set the static reference to null when the activity is destroyed or paused, etc. On Dec 10, 6:05 pm, Matt Kanninen mathias...@gmail.com wrote: I recommend the only things you make static be strings, and that for everything else you are considering making static, instead write it to file and use static methods, that expect to be passed a context, to access the data. I think my problems might be camera related, so my plan is to stop using our own camera related activites and just use an intent to launch the camera, and then read the returned result. On Dec 10, 1:05 pm, fadden fad...@android.com wrote: On Dec 8, 12:28 pm, skominac stevan.komi...@gmail.com wrote: So not only is memory of static members not deallocated (which is actually not surprising), but the static references are still alive, pointing to the memory, and can be used to invoke the members back. This last part was surprising to me. This is actually not bad, as long as developers are aware of it. Is this Dalvik's feature? This is the expected behavior. Keep in mind that the VM doesn't shut down between runs of your activity. You are not necessarily starting with a clean slate.- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text - -- 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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
It appears that static members of activity remain allocated and
referenced between consecutive runs of Activity. I can actually draw
the bitmap from the previous launch -- in a new launch (between finish
() calls). It's still there.
So not only is memory of static members not deallocated (which is
actually not surprising), but the static references are still alive,
pointing to the memory, and can be used to invoke the members back.
This last part was surprising to me.
This is actually not bad, as long as developers are aware of it.
Is this Dalvik's feature?
So, my VM budget issue can now be solved by simply creating my
bitmap (declared as static) on top of the activity, outside of onCreate
(); This way, on each new run of the activity, the bitmap is either
created (if memory was deallocated), or simply re-used (if memory is
still there). No need for me to check if the reference points to null,
or not.
Again, not sure if this is the best way of handling this. Any
thoughts?
-S.
On Dec 7, 2:23 pm, skominac stevan.komi...@gmail.com wrote:
On Dec 6, 10:23 pm, Romain Guy romain...@android.com wrote:
How come you still have a reference to your bitmap when a new Activity
is created?
That confuses me, too, actually. I really want to find out how I made
this happen.
If you have this bitmap somewhere else than within the
Activity, then it's perfectly normal that it's not de-allocated when
the Activity disappears.
What would be an example of somewhere else within the Activity?
In my case, the bitmap reference appears in onCreate(), onDraw(),
onPause(), as well inside an activity method, which is declared as
native and is called from C code.
The null checking, that I posted previously, happens in onCreate().
That is where I learned that I can still refer to the same bitmap from
the previous run.
In addition, if your Activity is not garbage
collected, you probably have a leak somewhere and are holding onto the
Activity object.
I am simply calling this activity via startActivity(). To my
knowledge, I am not holding any references to the activity object.
Some scenario I might be missing here?
Help is appreciated.
Thanks,
-S.
On Fri, Dec 4, 2009 at 7:19 PM,skominacstevan.komi...@gmail.com wrote:
I had a similar issue. Calling finish() on Activity does not in
itself deallocate memory allocated in Activity. The reason we notice
this problem with bitmaps is because they are often so large.
Recycling bitmaps did not work for me either.
So, instead, when my Activity starts, and before I create a new
bitmap, I do the following check:
if (bitmap == null) {
bitmap = Bitmap.createBitmap(width, height,
Bitmap.Config.ARGB_);
} else {
bitmap.eraseColor(0); // just clear pixels
}
This way, I reuse the previously allocated bitmap in a subsequent run
of the Activity. (My Activity only needs one bitmap.)
Not sure if this is the best way to do it, but it works for me.
-S.
On Nov 25, 11:43 am, Matt Hall matt.h...@gmail.com wrote:
Yeah, we've had a similar issue before. One thing you can try is to call
recycle() on the last frame of your animation before you replace it.
This is
normally called by the garbage collector and works fine when you're not
close to the memory limit, but it sounds like there might be cases where
you
temporarily go over the limit and the GC doesn't get to the bitmaps in
time.
Matt
On Wed, Nov 25, 2009 at 2:37 PM, Matt Kanninen mathias...@gmail.com
wrote:
Matt,
So in this case I definitely am frequently loading and unloading small
images. Those 10 id's all point at different states in our
animation. I can reduce the quality of our animation by reducing the
views, and decrease how often I stumble down this cow path:
but I only posted this stack trace because it was new, this happens
anytime my app is run for more then half an hour, or 5 mins on the
droid. The droid uses the same apk, same images, and 2 slightly
different xmls (we added margins to our Droid xml).
http://groups.google.com/group/android-developers/browse_thread/threa...
or to quote myself:
If my app runs for more then half an hour on the G1 it will fail on
inflating views from xml, giving an error about insufficient memory
creating a bitmap. Another issue, which may be a side effect is that
global static strings that are assigned at startup become null.
I have worked around that by throwing up setters around those statics
that also store them as a private preference, and thrown up getters
that read the preference in case of null.
The root cause of all of my issues may be that when I call release on
my MediaRecorder it sometimes hangs. No crash it just never returns,
stalling the thread. I have worked around that by calling release in
a thread that only does that.
Is anyone else seeing and
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
On Dec 8, 12:28 pm, skominac stevan.komi...@gmail.com wrote: So not only is memory of static members not deallocated (which is actually not surprising), but the static references are still alive, pointing to the memory, and can be used to invoke the members back. This last part was surprising to me. This is actually not bad, as long as developers are aware of it. Is this Dalvik's feature? This is the expected behavior. Keep in mind that the VM doesn't shut down between runs of your activity. You are not necessarily starting with a clean slate. -- 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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
I recommend the only things you make static be strings, and that for everything else you are considering making static, instead write it to file and use static methods, that expect to be passed a context, to access the data. I think my problems might be camera related, so my plan is to stop using our own camera related activites and just use an intent to launch the camera, and then read the returned result. On Dec 10, 1:05 pm, fadden fad...@android.com wrote: On Dec 8, 12:28 pm, skominac stevan.komi...@gmail.com wrote: So not only is memory of static members not deallocated (which is actually not surprising), but the static references are still alive, pointing to the memory, and can be used to invoke the members back. This last part was surprising to me. This is actually not bad, as long as developers are aware of it. Is this Dalvik's feature? This is the expected behavior. Keep in mind that the VM doesn't shut down between runs of your activity. You are not necessarily starting with a clean slate. -- 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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
Statically held (caches of) bitmaps may come in very very handy. However, as soon as you do hold static references to 'expensive' resources, be sure to have a proper clean-up strategy. E.g. make sure the capacity of your cache of bitmaps is limited. Be sure to set the static reference to null when the activity is destroyed or paused, etc. On Dec 10, 6:05 pm, Matt Kanninen mathias...@gmail.com wrote: I recommend the only things you make static be strings, and that for everything else you are considering making static, instead write it to file and use static methods, that expect to be passed a context, to access the data. I think my problems might be camera related, so my plan is to stop using our own camera related activites and just use an intent to launch the camera, and then read the returned result. On Dec 10, 1:05 pm, fadden fad...@android.com wrote: On Dec 8, 12:28 pm, skominac stevan.komi...@gmail.com wrote: So not only is memory of static members not deallocated (which is actually not surprising), but the static references are still alive, pointing to the memory, and can be used to invoke the members back. This last part was surprising to me. This is actually not bad, as long as developers are aware of it. Is this Dalvik's feature? This is the expected behavior. Keep in mind that the VM doesn't shut down between runs of your activity. You are not necessarily starting with a clean slate.- Hide quoted text - - Show quoted text - -- 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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
I don't get it. If you're nulling your static bitmap in onPause why is it static to begin with? Also what you want to do is probably very different for a game that is basically all taking place in one activity and trying to avoid garbage collecting at all, compared to your standard Android app with an activity per screen. On Dec 10, 4:53 pm, Streets Of Boston flyingdutc...@gmail.com wrote: Statically held (caches of) bitmaps may come in very very handy. However, as soon as you do hold static references to 'expensive' resources, be sure to have a proper clean-up strategy. E.g. make sure the capacity of your cache of bitmaps is limited. Be sure to set the static reference to null when the activity is destroyed or paused, etc. On Dec 10, 6:05 pm, Matt Kanninen mathias...@gmail.com wrote: I recommend the only things you make static be strings, and that for everything else you are considering making static, instead write it to file and use static methods, that expect to be passed a context, to access the data. I think my problems might be camera related, so my plan is to stop using our own camera related activites and just use an intent to launch the camera, and then read the returned result. On Dec 10, 1:05 pm, fadden fad...@android.com wrote: On Dec 8, 12:28 pm, skominac stevan.komi...@gmail.com wrote: So not only is memory of static members not deallocated (which is actually not surprising), but the static references are still alive, pointing to the memory, and can be used to invoke the members back. This last part was surprising to me. This is actually not bad, as long as developers are aware of it. Is this Dalvik's feature? This is the expected behavior. Keep in mind that the VM doesn't shut down between runs of your activity. You are not necessarily starting with a clean slate.- Hide quoted text - - Show quoted text - -- 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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
On Dec 6, 10:23 pm, Romain Guy romain...@android.com wrote:
How come you still have a reference to your bitmap when a new Activity
is created?
That confuses me, too, actually. I really want to find out how I made
this happen.
If you have this bitmap somewhere else than within the
Activity, then it's perfectly normal that it's not de-allocated when
the Activity disappears.
What would be an example of somewhere else within the Activity?
In my case, the bitmap reference appears in onCreate(), onDraw(),
onPause(), as well inside an activity method, which is declared as
native and is called from C code.
The null checking, that I posted previously, happens in onCreate().
That is where I learned that I can still refer to the same bitmap from
the previous run.
In addition, if your Activity is not garbage
collected, you probably have a leak somewhere and are holding onto the
Activity object.
I am simply calling this activity via startActivity(). To my
knowledge, I am not holding any references to the activity object.
Some scenario I might be missing here?
Help is appreciated.
Thanks,
-S.
On Fri, Dec 4, 2009 at 7:19 PM, skominac stevan.komi...@gmail.com wrote:
I had a similar issue. Calling finish() on Activity does not in
itself deallocate memory allocated in Activity. The reason we notice
this problem with bitmaps is because they are often so large.
Recycling bitmaps did not work for me either.
So, instead, when my Activity starts, and before I create a new
bitmap, I do the following check:
if (bitmap == null) {
bitmap = Bitmap.createBitmap(width, height,
Bitmap.Config.ARGB_);
} else {
bitmap.eraseColor(0); // just clear pixels
}
This way, I reuse the previously allocated bitmap in a subsequent run
of the Activity. (My Activity only needs one bitmap.)
Not sure if this is the best way to do it, but it works for me.
-S.
On Nov 25, 11:43 am, Matt Hall matt.h...@gmail.com wrote:
Yeah, we've had a similar issue before. One thing you can try is to call
recycle() on the last frame of your animation before you replace it. This
is
normally called by the garbage collector and works fine when you're not
close to the memory limit, but it sounds like there might be cases where
you
temporarily go over the limit and the GC doesn't get to the bitmaps in
time.
Matt
On Wed, Nov 25, 2009 at 2:37 PM, Matt Kanninen mathias...@gmail.com
wrote:
Matt,
So in this case I definitely am frequently loading and unloading small
images. Those 10 id's all point at different states in our
animation. I can reduce the quality of our animation by reducing the
views, and decrease how often I stumble down this cow path:
but I only posted this stack trace because it was new, this happens
anytime my app is run for more then half an hour, or 5 mins on the
droid. The droid uses the same apk, same images, and 2 slightly
different xmls (we added margins to our Droid xml).
http://groups.google.com/group/android-developers/browse_thread/threa...
or to quote myself:
If my app runs for more then half an hour on the G1 it will fail on
inflating views from xml, giving an error about insufficient memory
creating a bitmap. Another issue, which may be a side effect is that
global static strings that are assigned at startup become null.
I have worked around that by throwing up setters around those statics
that also store them as a private preference, and thrown up getters
that read the preference in case of null.
The root cause of all of my issues may be that when I call release on
my MediaRecorder it sometimes hangs. No crash it just never returns,
stalling the thread. I have worked around that by calling release in
a thread that only does that.
Is anyone else seeing and working around issues like these? I could
use some advice.
-Matt K
On Nov 25, 10:07 am, Matt Hall matt.h...@gmail.com wrote:
How big (dimensions) are the graphics Matt? If they're not very big
then I'm guessing you have bitmap memory used elsewhere in the app
that's putting you close to the max. Bitmap memory is different than
your heap memory, so it's management is hidden from you a little more
but basically this error means you have too many graphics loaded at
once, or are unloading and loading a lot of graphics in a row so the
finalizer can't reclaim the bitmap memory in time.
Matt
On Nov 25, 12:46 pm, Matt Kanninen mathias...@gmail.com wrote:
a
href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, Matt Kanninen mathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
I had a similar issue. Calling finish() on Activity does not in
itself deallocate memory allocated in Activity. The reason we notice
this problem with bitmaps is because they are often so large.
Recycling bitmaps did not work for me either.
So, instead, when my Activity starts, and before I create a new
bitmap, I do the following check:
if (bitmap == null) {
bitmap = Bitmap.createBitmap(width, height,
Bitmap.Config.ARGB_);
} else {
bitmap.eraseColor(0); // just clear pixels
}
This way, I reuse the previously allocated bitmap in a subsequent run
of the Activity. (My Activity only needs one bitmap.)
Not sure if this is the best way to do it, but it works for me.
-S.
On Nov 25, 11:43 am, Matt Hall matt.h...@gmail.com wrote:
Yeah, we've had a similar issue before. One thing you can try is to call
recycle() on the last frame of your animation before you replace it. This is
normally called by the garbage collector and works fine when you're not
close to the memory limit, but it sounds like there might be cases where you
temporarily go over the limit and the GC doesn't get to the bitmaps in time.
Matt
On Wed, Nov 25, 2009 at 2:37 PM, Matt Kanninen mathias...@gmail.com wrote:
Matt,
So in this case I definitely am frequently loading and unloading small
images. Those 10 id's all point at different states in our
animation. I can reduce the quality of our animation by reducing the
views, and decrease how often I stumble down this cow path:
but I only posted this stack trace because it was new, this happens
anytime my app is run for more then half an hour, or 5 mins on the
droid. The droid uses the same apk, same images, and 2 slightly
different xmls (we added margins to our Droid xml).
http://groups.google.com/group/android-developers/browse_thread/threa...
or to quote myself:
If my app runs for more then half an hour on the G1 it will fail on
inflating views from xml, giving an error about insufficient memory
creating a bitmap. Another issue, which may be a side effect is that
global static strings that are assigned at startup become null.
I have worked around that by throwing up setters around those statics
that also store them as a private preference, and thrown up getters
that read the preference in case of null.
The root cause of all of my issues may be that when I call release on
my MediaRecorder it sometimes hangs. No crash it just never returns,
stalling the thread. I have worked around that by calling release in
a thread that only does that.
Is anyone else seeing and working around issues like these? I could
use some advice.
-Matt K
On Nov 25, 10:07 am, Matt Hall matt.h...@gmail.com wrote:
How big (dimensions) are the graphics Matt? If they're not very big
then I'm guessing you have bitmap memory used elsewhere in the app
that's putting you close to the max. Bitmap memory is different than
your heap memory, so it's management is hidden from you a little more
but basically this error means you have too many graphics loaded at
once, or are unloading and loading a lot of graphics in a row so the
finalizer can't reclaim the bitmap memory in time.
Matt
On Nov 25, 12:46 pm, Matt Kanninen mathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, Matt Kanninen mathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to persist new
stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 objects /
15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 680-byte external
allocation too large for this process.
11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate 680
bytes
11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting down VM
11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread exiting
with uncaught exception (group=0x4001b180)
11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught handler:
thread main exiting due to uncaught
Re: [android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
How come you still have a reference to your bitmap when a new Activity
is created? If you have this bitmap somewhere else than within the
Activity, then it's perfectly normal that it's not de-allocated when
the Activity disappears. In addition, if your Activity is not garbage
collected, you probably have a leak somewhere and are holding onto the
Activity object.
On Fri, Dec 4, 2009 at 7:19 PM, skominac stevan.komi...@gmail.com wrote:
I had a similar issue. Calling finish() on Activity does not in
itself deallocate memory allocated in Activity. The reason we notice
this problem with bitmaps is because they are often so large.
Recycling bitmaps did not work for me either.
So, instead, when my Activity starts, and before I create a new
bitmap, I do the following check:
if (bitmap == null) {
bitmap = Bitmap.createBitmap(width, height,
Bitmap.Config.ARGB_);
} else {
bitmap.eraseColor(0); // just clear pixels
}
This way, I reuse the previously allocated bitmap in a subsequent run
of the Activity. (My Activity only needs one bitmap.)
Not sure if this is the best way to do it, but it works for me.
-S.
On Nov 25, 11:43 am, Matt Hall matt.h...@gmail.com wrote:
Yeah, we've had a similar issue before. One thing you can try is to call
recycle() on the last frame of your animation before you replace it. This is
normally called by the garbage collector and works fine when you're not
close to the memory limit, but it sounds like there might be cases where you
temporarily go over the limit and the GC doesn't get to the bitmaps in time.
Matt
On Wed, Nov 25, 2009 at 2:37 PM, Matt Kanninen mathias...@gmail.com wrote:
Matt,
So in this case I definitely am frequently loading and unloading small
images. Those 10 id's all point at different states in our
animation. I can reduce the quality of our animation by reducing the
views, and decrease how often I stumble down this cow path:
but I only posted this stack trace because it was new, this happens
anytime my app is run for more then half an hour, or 5 mins on the
droid. The droid uses the same apk, same images, and 2 slightly
different xmls (we added margins to our Droid xml).
http://groups.google.com/group/android-developers/browse_thread/threa...
or to quote myself:
If my app runs for more then half an hour on the G1 it will fail on
inflating views from xml, giving an error about insufficient memory
creating a bitmap. Another issue, which may be a side effect is that
global static strings that are assigned at startup become null.
I have worked around that by throwing up setters around those statics
that also store them as a private preference, and thrown up getters
that read the preference in case of null.
The root cause of all of my issues may be that when I call release on
my MediaRecorder it sometimes hangs. No crash it just never returns,
stalling the thread. I have worked around that by calling release in
a thread that only does that.
Is anyone else seeing and working around issues like these? I could
use some advice.
-Matt K
On Nov 25, 10:07 am, Matt Hall matt.h...@gmail.com wrote:
How big (dimensions) are the graphics Matt? If they're not very big
then I'm guessing you have bitmap memory used elsewhere in the app
that's putting you close to the max. Bitmap memory is different than
your heap memory, so it's management is hidden from you a little more
but basically this error means you have too many graphics loaded at
once, or are unloading and loading a lot of graphics in a row so the
finalizer can't reclaim the bitmap memory in time.
Matt
On Nov 25, 12:46 pm, Matt Kanninen mathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, Matt Kanninen mathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to persist new
stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 objects /
15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386):
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
My app involves taking a picture with the camera, or recording voice using the microphone, and sending the results to the server. It's a search tool. The UI isn't very complicated, as much as possible it is done in XML. For the droid we added some layouts in res/long that differ only in layout margins. I, like a great many Android developers, had to re create the look and feel that was established with our iPhone application. On the droid we had gradient banding so we pre dithered a png, but that was the art guy. The layouts could be simpler, but I have already repeatedly simplified them from the first version that had the right look and feel. I have some FrameLayouts, containing RelativeLayouts, containing single Views. It seems like RelativeLayout has been redone and is less brittle then I remember it, so I probably can start skipping the FrameLayouts. Framelayouts just seem like the simple easy way to control over lap of views, and I often have 4 over lapping views. I also have some linear layouts in side other linear layouts, but all with different weights. The 1 or 2 pixel differences between 1.5,1.6 and 2.0 make our application look worse on the Hero. I use ListViews, that sometimes are populated by CursorAdapters. I have gone back and forth between letting the activity manage the cursors, and managing them myself. (I'm referencing AdMob and other's numbers to try and figure out what Android versions I need to support, and what handsets I need to test on http://daringfireball.net/linked/2009/11/23/admob ) Much of the code for my app was written for Android 1.0, 1.1 etc. and it has been maintained by different developers over the years. Now I guess my task is to go over every line of code and reduce how much memory is used. I've tried to check every static reference that wasn't a private static final constant primitive, to make sure we weren't hindering garbage collection. I don't think I ever store a context, but we pass them around everywhere as arguments. I can't really recycle my drawables because I'm not managing them, I just call setContentView. My activities have some member variables, views, etc. I create some handlers, but more often just call runOnUiThread. I guess I can explicitly set these to null in onStop... when I hear improve memory management my first response is to set things null, my problem is the unusual lifecycle of an Android application, it's activities, and it's static variables. I'm already prepared for my major static variables, strings, to unexpectedly become null, and write my strings to a private preference, or save my camera or microphone content as a private application file. It's all pretty vanilla. The networking is done using some included apache jars, I guess I could redo all my networking to use something else, that would make it even more vanilla. But I will probably wait until my application becomes less vanilla and we need a push solution. SoftwareForMe, I have read your post a couple times now, I think it's clear to me now. Generating a new version of most or all of our PNGs, especially our largest, sounds like a good idea. Is there a good blog post I can send to the art guy so he can understand what he needs to do? I'd like not to have to go 11 more revisions on each asset. It'd be real cool if there was an easy way to just remove all my unused PNGs from my project, before I double them. I have not go through and removed every PNG that is no longer being referenced yet. My 2 cents, Matt Kanninen Android Developer On Dec 2, 8:38 pm, SoftwareForMe.com SoftwareForMe.com softwareforme@gmail.com wrote: The bitmap issue on the Droid is really about whether you want to show more graphics at smaller size, or the same graphics at larger size. I don't know what you app does, but imagine that it's a 2d game, where the graphics are re-used a lot (land tiles, character icons, etc.). If you let the higher resolution screen show more of the game map at a time, your program will consume NEARLY identical memory to what it would on other devices. Why? Because the tiles will be the same size in memory; the only thing that would be larger would be the screen surface, and any back buffers you use. On the other hand, if you want the graphics on the Droid to look the same (same game play area visible), then without work, your application will take more memory on the Droid. Why? Because unless you explicitly avoid it, Android will scale your image up to higher resolution when you load them, so they take more memory. The solutions are to: 1) Create high-density images that are simply smaller, but occupy the same number of pixels. This way, loading resources on the denser devices won't take any memory, or 2) Resize the images after you load them, understanding that loading the exact same resource on two different devices may result in two different sized bitmaps in memory Of course approach #1 is the standard
Re: [android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
Hi Matt, I'm not aware of any other source. This we learned on our own on Friday, November 6th (Droid release day :-) To put it simply, say I have a 64x64 .png resource and use: Bitmap b = BitmapFactory.decodeResource(...) I will get a 64x64, 32-bit in-memory bitmap. If I use the exact same code, and the exact same resource (in the 'drawable' folder) on the Droid, I get a larger bitmap; I don't remember the exact size, but I'll guess 86x86 pixels. It's the same image, stretched by Android so that when rendered, it will take approximately the same real screen space (not pixel space). So, if I wanted to always get the raw 64x64 image, I'd need to do one of: 1) Load the image scaled, or 2) Place the 64x64 image in the drawable-hdpi folder I hope that's clearer. If you find a good resource for advice, please share :-) SoftwareForMe.com Makers of PhoneMyPC Imagine Multi-touch On Thu, Dec 3, 2009 at 12:22 AM, Matt Kanninen mathias...@gmail.com wrote: My app involves taking a picture with the camera, or recording voice using the microphone, and sending the results to the server. It's a search tool. The UI isn't very complicated, as much as possible it is done in XML. For the droid we added some layouts in res/long that differ only in layout margins. I, like a great many Android developers, had to re create the look and feel that was established with our iPhone application. On the droid we had gradient banding so we pre dithered a png, but that was the art guy. The layouts could be simpler, but I have already repeatedly simplified them from the first version that had the right look and feel. I have some FrameLayouts, containing RelativeLayouts, containing single Views. It seems like RelativeLayout has been redone and is less brittle then I remember it, so I probably can start skipping the FrameLayouts. Framelayouts just seem like the simple easy way to control over lap of views, and I often have 4 over lapping views. I also have some linear layouts in side other linear layouts, but all with different weights. The 1 or 2 pixel differences between 1.5,1.6 and 2.0 make our application look worse on the Hero. I use ListViews, that sometimes are populated by CursorAdapters. I have gone back and forth between letting the activity manage the cursors, and managing them myself. (I'm referencing AdMob and other's numbers to try and figure out what Android versions I need to support, and what handsets I need to test on http://daringfireball.net/linked/2009/11/23/admob ) Much of the code for my app was written for Android 1.0, 1.1 etc. and it has been maintained by different developers over the years. Now I guess my task is to go over every line of code and reduce how much memory is used. I've tried to check every static reference that wasn't a private static final constant primitive, to make sure we weren't hindering garbage collection. I don't think I ever store a context, but we pass them around everywhere as arguments. I can't really recycle my drawables because I'm not managing them, I just call setContentView. My activities have some member variables, views, etc. I create some handlers, but more often just call runOnUiThread. I guess I can explicitly set these to null in onStop... when I hear improve memory management my first response is to set things null, my problem is the unusual lifecycle of an Android application, it's activities, and it's static variables. I'm already prepared for my major static variables, strings, to unexpectedly become null, and write my strings to a private preference, or save my camera or microphone content as a private application file. It's all pretty vanilla. The networking is done using some included apache jars, I guess I could redo all my networking to use something else, that would make it even more vanilla. But I will probably wait until my application becomes less vanilla and we need a push solution. SoftwareForMe, I have read your post a couple times now, I think it's clear to me now. Generating a new version of most or all of our PNGs, especially our largest, sounds like a good idea. Is there a good blog post I can send to the art guy so he can understand what he needs to do? I'd like not to have to go 11 more revisions on each asset. It'd be real cool if there was an easy way to just remove all my unused PNGs from my project, before I double them. I have not go through and removed every PNG that is no longer being referenced yet. My 2 cents, Matt Kanninen Android Developer On Dec 2, 8:38 pm, SoftwareForMe.com SoftwareForMe.com softwareforme@gmail.com wrote: The bitmap issue on the Droid is really about whether you want to show more graphics at smaller size, or the same graphics at larger size. I don't know what you app does, but imagine that it's a 2d game, where the graphics are re-used a lot (land tiles, character icons, etc.). If you let the
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
The app worked great on the G1. I've clearly hit a case where the
framework made some decisions that result in poorer performance on the
Droid.
The bitmap out of memory errors can still occur on any setLayout(res/
xml/id), after running the app for 5-30 mins. But I did fix the
bitmap out of memory crash that occured during
glow.setBackgroundResource(glowDrawableIds[scale]);
We just don't set a new background resource anymore.
I had 10 animation frames, and the animation frame chosen was based
upon the volume coming from the mic.
Now we take what was the last frame, and vary it's drawable's
transparency depending on volume.
glow.getBackground().setAlpha(alpha);
I will now start creating additional res/xml/files, so that LESS
complex layouts are used on the Verizon Motorola Droid with firmware
2.0 then we used on the G1.
The layouts, and the final resulting screens were approved by
management, so I will be trying hard not to change ANYTHING on the G1,
while adding support for the inferior memory handling on the only
Android 2.0 handset. The one with better specs.
Can anyone recommend which Android debugging tool I should be using to
figure out what to optimize?
On Nov 25, 11:11 am, Streets Of Boston flyingdutc...@gmail.com
wrote:
As in the comment in your bug-report by Romain, you're using too much
memory.
Note that you only have 16MByte total available RAM for your process,
including your bitmaps.
- Only load the bitmaps that are absolutely necessary (especially when
they become quite large).
- Load the bitmaps scaled to the size of your screen, if possible. Use
BitmapFactory.decode and set the 'inSampleSize' of your bitmap-options
to scale down the size of the bitmap to be loaded and rendered on the
screen.
On Nov 25, 12:46 pm, MattKanninenmathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, MattKanninenmathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to persist new stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 objects / 15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 680-byte external
allocation too large for this process.
11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate 680
bytes
11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting down VM
11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread exiting
with uncaught exception (group=0x4001b180)
11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught handler:
thread main exiting due to uncaught exception
11-25 09:21:03.014: ERROR/AndroidRuntime(2386):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.nativeCreate(Native Method)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:468)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:435)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createScaledBitmap(Bitmap.java:340)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:488)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:462)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:
323)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.drawable.Drawable.createFromResourceStream
(Drawable.java:697)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.content.res.Resources.loadDrawable(Resources.java:1705)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.content.res.Resources.getDrawable(Resources.java:580)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.view.View.setBackgroundResource(View.java:7187)- Hide quoted text
-
- Show quoted text -
Re: [android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
The Droid has more pixels and a high display density, therefore
bitmaps are scaled and require more memory. If your app is running out
of memory, do not blame it on the framework and poorer performance,
blame it on your app for doing the wrong thing and abusing the Java
heap.
The app worked great on the G1. I've clearly hit a case where the
framework made some decisions that result in poorer performance on the
Droid.
The bitmap out of memory errors can still occur on any setLayout(res/
xml/id), after running the app for 5-30 mins. But I did fix the
bitmap out of memory crash that occured during
glow.setBackgroundResource(glowDrawableIds[scale]);
We just don't set a new background resource anymore.
I had 10 animation frames, and the animation frame chosen was based
upon the volume coming from the mic.
Now we take what was the last frame, and vary it's drawable's
transparency depending on volume.
glow.getBackground().setAlpha(alpha);
I will now start creating additional res/xml/files, so that LESS
complex layouts are used on the Verizon Motorola Droid with firmware
2.0 then we used on the G1.
The layouts, and the final resulting screens were approved by
management, so I will be trying hard not to change ANYTHING on the G1,
while adding support for the inferior memory handling on the only
Android 2.0 handset. The one with better specs.
Can anyone recommend which Android debugging tool I should be using to
figure out what to optimize?
On Nov 25, 11:11 am, Streets Of Boston flyingdutc...@gmail.com
wrote:
As in the comment in your bug-report by Romain, you're using too much
memory.
Note that you only have 16MByte total available RAM for your process,
including your bitmaps.
- Only load the bitmaps that are absolutely necessary (especially when
they become quite large).
- Load the bitmaps scaled to the size of your screen, if possible. Use
BitmapFactory.decode and set the 'inSampleSize' of your bitmap-options
to scale down the size of the bitmap to be loaded and rendered on the
screen.
On Nov 25, 12:46 pm, MattKanninenmathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, MattKanninenmathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to persist new stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 objects / 15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 680-byte external
allocation too large for this process.
11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate 680
bytes
11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting down VM
11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread exiting
with uncaught exception (group=0x4001b180)
11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught handler:
thread main exiting due to uncaught exception
11-25 09:21:03.014: ERROR/AndroidRuntime(2386):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.nativeCreate(Native Method)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:468)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:435)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createScaledBitmap(Bitmap.java:340)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:488)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:462)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:
323)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.drawable.Drawable.createFromResourceStream
(Drawable.java:697)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
What did I do wrong? I worked within the defined limitations, then a
new handset came out with stricter limitations.
I'm kind of confused how you can blame me!
On Dec 2, 5:19 pm, Romain Guy romain...@android.com wrote:
The Droid has more pixels and a high display density, therefore
bitmaps are scaled and require more memory. If your app is running out
of memory, do not blame it on the framework and poorer performance,
blame it on your app for doing the wrong thing and abusing the Java
heap.
The app worked great on the G1. I've clearly hit a case where the
framework made some decisions that result in poorer performance on the
Droid.
The bitmap out of memory errors can still occur on any setLayout(res/
xml/id), after running the app for 5-30 mins. But I did fix the
bitmap out of memory crash that occured during
glow.setBackgroundResource(glowDrawableIds[scale]);
We just don't set a new background resource anymore.
I had 10 animation frames, and the animation frame chosen was based
upon the volume coming from the mic.
Now we take what was the last frame, and vary it's drawable's
transparency depending on volume.
glow.getBackground().setAlpha(alpha);
I will now start creating additional res/xml/files, so that LESS
complex layouts are used on the Verizon Motorola Droid with firmware
2.0 then we used on the G1.
The layouts, and the final resulting screens were approved by
management, so I will be trying hard not to change ANYTHING on the G1,
while adding support for the inferior memory handling on the only
Android 2.0 handset. The one with better specs.
Can anyone recommend which Android debugging tool I should be using to
figure out what to optimize?
On Nov 25, 11:11 am, Streets Of Boston flyingdutc...@gmail.com
wrote:
As in the comment in your bug-report by Romain, you're using too much
memory.
Note that you only have 16MByte total available RAM for your process,
including your bitmaps.
- Only load the bitmaps that are absolutely necessary (especially when
they become quite large).
- Load the bitmaps scaled to the size of your screen, if possible. Use
BitmapFactory.decode and set the 'inSampleSize' of your bitmap-options
to scale down the size of the bitmap to be loaded and rendered on the
screen.
On Nov 25, 12:46 pm, MattKanninenmathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, MattKanninenmathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to persist new stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 objects / 15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 680-byte external
allocation too large for this process.
11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate 680
bytes
11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting down VM
11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread exiting
with uncaught exception (group=0x4001b180)
11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught handler:
thread main exiting due to uncaught exception
11-25 09:21:03.014: ERROR/AndroidRuntime(2386):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.nativeCreate(Native Method)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:468)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:435)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createScaledBitmap(Bitmap.java:340)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:488)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:462)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
Re: [android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
The new device does not have stricter limitations since it gives apps
more RAM (24 MB instead of 16 MB.)
On Wed, Dec 2, 2009 at 5:29 PM, Matt Kanninen mathias...@gmail.com wrote:
What did I do wrong? I worked within the defined limitations, then a
new handset came out with stricter limitations.
I'm kind of confused how you can blame me!
On Dec 2, 5:19 pm, Romain Guy romain...@android.com wrote:
The Droid has more pixels and a high display density, therefore
bitmaps are scaled and require more memory. If your app is running out
of memory, do not blame it on the framework and poorer performance,
blame it on your app for doing the wrong thing and abusing the Java
heap.
The app worked great on the G1. I've clearly hit a case where the
framework made some decisions that result in poorer performance on the
Droid.
The bitmap out of memory errors can still occur on any setLayout(res/
xml/id), after running the app for 5-30 mins. But I did fix the
bitmap out of memory crash that occured during
glow.setBackgroundResource(glowDrawableIds[scale]);
We just don't set a new background resource anymore.
I had 10 animation frames, and the animation frame chosen was based
upon the volume coming from the mic.
Now we take what was the last frame, and vary it's drawable's
transparency depending on volume.
glow.getBackground().setAlpha(alpha);
I will now start creating additional res/xml/files, so that LESS
complex layouts are used on the Verizon Motorola Droid with firmware
2.0 then we used on the G1.
The layouts, and the final resulting screens were approved by
management, so I will be trying hard not to change ANYTHING on the G1,
while adding support for the inferior memory handling on the only
Android 2.0 handset. The one with better specs.
Can anyone recommend which Android debugging tool I should be using to
figure out what to optimize?
On Nov 25, 11:11 am, Streets Of Boston flyingdutc...@gmail.com
wrote:
As in the comment in your bug-report by Romain, you're using too much
memory.
Note that you only have 16MByte total available RAM for your process,
including your bitmaps.
- Only load the bitmaps that are absolutely necessary (especially when
they become quite large).
- Load the bitmaps scaled to the size of your screen, if possible. Use
BitmapFactory.decode and set the 'inSampleSize' of your bitmap-options
to scale down the size of the bitmap to be loaded and rendered on the
screen.
On Nov 25, 12:46 pm, MattKanninenmathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, MattKanninenmathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to persist new stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 objects / 15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 680-byte external
allocation too large for this process.
11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate 680
bytes
11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting down VM
11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread exiting
with uncaught exception (group=0x4001b180)
11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught handler:
thread main exiting due to uncaught exception
11-25 09:21:03.014: ERROR/AndroidRuntime(2386):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.nativeCreate(Native Method)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:468)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:435)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createScaledBitmap(Bitmap.java:340)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:488)
11-25 09:21:03.014:
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
The same code works great on the G1 and the MyTouch. We've done some
testing on the Hero, and the Moment, but only on the Droid is the
issue significant. I've told my boss that I am spending time porting
to the Droid.
You have explained that bitmaps are scaled and require more memory.
This creates a stricter limitation, on the complexity possible for my
xml, on the frequency with which I can create bitmaps, etc.
It's a bug if an application works on phones A, B, C and D, but not
E. My first instinct is not to blame the guy who wrote the
application, but the guys responsible for handset E's software. In
fact situations like that are the textbook case for a bug with handset
E. Especially if handset E is newer, or running a newer firmware then
handsets A, B, C and D.
I think this is a big deal, especially given the fact for a lot of
users and non users, Droid -- Android. I'd consider it a priority
to make sure that G1 applications can run on the Droid.
Extensive googling didn't lead me to a lot of other people
complaining, so I may be one of the unlucky few who happens to use the
exact amount of memory such that it works on every phone but the
Droid. I'm not unfamiliar with that sort of luck :)
Extensive googling did lead me to old posts I remember reading the
year they were written, and I remember being suprised by how Bitmap
memory was handled then.
On Dec 2, 5:40 pm, Romain Guy romain...@android.com wrote:
The new device does not have stricter limitations since it gives apps
more RAM (24 MB instead of 16 MB.)
On Wed, Dec 2, 2009 at 5:29 PM, Matt Kanninen mathias...@gmail.com wrote:
What did I do wrong? I worked within the defined limitations, then a
new handset came out with stricter limitations.
I'm kind of confused how you can blame me!
On Dec 2, 5:19 pm, Romain Guy romain...@android.com wrote:
The Droid has more pixels and a high display density, therefore
bitmaps are scaled and require more memory. If your app is running out
of memory, do not blame it on the framework and poorer performance,
blame it on your app for doing the wrong thing and abusing the Java
heap.
The app worked great on the G1. I've clearly hit a case where the
framework made some decisions that result in poorer performance on the
Droid.
The bitmap out of memory errors can still occur on any setLayout(res/
xml/id), after running the app for 5-30 mins. But I did fix the
bitmap out of memory crash that occured during
glow.setBackgroundResource(glowDrawableIds[scale]);
We just don't set a new background resource anymore.
I had 10 animation frames, and the animation frame chosen was based
upon the volume coming from the mic.
Now we take what was the last frame, and vary it's drawable's
transparency depending on volume.
glow.getBackground().setAlpha(alpha);
I will now start creating additional res/xml/files, so that LESS
complex layouts are used on the Verizon Motorola Droid with firmware
2.0 then we used on the G1.
The layouts, and the final resulting screens were approved by
management, so I will be trying hard not to change ANYTHING on the G1,
while adding support for the inferior memory handling on the only
Android 2.0 handset. The one with better specs.
Can anyone recommend which Android debugging tool I should be using to
figure out what to optimize?
On Nov 25, 11:11 am, Streets Of Boston flyingdutc...@gmail.com
wrote:
As in the comment in your bug-report by Romain, you're using too much
memory.
Note that you only have 16MByte total available RAM for your process,
including your bitmaps.
- Only load the bitmaps that are absolutely necessary (especially when
they become quite large).
- Load the bitmaps scaled to the size of your screen, if possible. Use
BitmapFactory.decode and set the 'inSampleSize' of your bitmap-options
to scale down the size of the bitmap to be loaded and rendered on the
screen.
On Nov 25, 12:46 pm, MattKanninenmathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, MattKanninenmathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow =
Re: [android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
IMHO, if the device offers 50% more memory per application, but the
bitmaps take up more than 50% more memory, then the net effect is a
stricter limitation.
i'm seeing some occasional OOMs only on Droid, and so i'm being extra
careful about recycling bitmaps and all that.
At 5:40 PM -0800 12/2/09, Romain Guy wrote:
The new device does not have stricter limitations since it gives apps
more RAM (24 MB instead of 16 MB.)
On Wed, Dec 2, 2009 at 5:29 PM, Matt Kanninen mathias...@gmail.com wrote:
What did I do wrong? I worked within the defined limitations, then a
new handset came out with stricter limitations.
I'm kind of confused how you can blame me!
On Dec 2, 5:19 pm, Romain Guy romain...@android.com wrote:
The Droid has more pixels and a high display density, therefore
bitmaps are scaled and require more memory. If your app is running out
of memory, do not blame it on the framework and poorer performance,
blame it on your app for doing the wrong thing and abusing the Java
heap.
The app worked great on the G1. I've clearly hit a case where the
framework made some decisions that result in poorer performance on the
Droid.
The bitmap out of memory errors can still occur on any setLayout(res/
xml/id), after running the app for 5-30 mins. But I did fix the
bitmap out of memory crash that occured during
glow.setBackgroundResource(glowDrawableIds[scale]);
We just don't set a new background resource anymore.
I had 10 animation frames, and the animation frame chosen was based
upon the volume coming from the mic.
Now we take what was the last frame, and vary it's drawable's
transparency depending on volume.
glow.getBackground().setAlpha(alpha);
I will now start creating additional res/xml/files, so that LESS
complex layouts are used on the Verizon Motorola Droid with firmware
2.0 then we used on the G1.
The layouts, and the final resulting screens were approved by
management, so I will be trying hard not to change ANYTHING on the G1,
while adding support for the inferior memory handling on the only
Android 2.0 handset. The one with better specs.
Can anyone recommend which Android debugging tool I should be using to
figure out what to optimize?
On Nov 25, 11:11 am, Streets Of Boston flyingdutc...@gmail.com
wrote:
As in the comment in your bug-report by Romain, you're using too much
memory.
Note that you only have 16MByte total available RAM for your process,
including your bitmaps.
- Only load the bitmaps that are absolutely necessary (especially when
they become quite large).
- Load the bitmaps scaled to the size of your screen, if possible. Use
BitmapFactory.decode and set the 'inSampleSize' of your bitmap-options
to scale down the size of the bitmap to be loaded and rendered on the
screen.
On Nov 25, 12:46 pm, MattKanninenmathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, MattKanninenmathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to
persist new stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298
objects / 15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 680-byte external
allocation too large for this process.
11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate 680
bytes
11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting down VM
11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread exiting
with uncaught exception (group=0x4001b180)
11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught handler:
thread main exiting due to uncaught exception
11-25 09:21:03.014: ERROR/AndroidRuntime(2386):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.nativeCreate(Native Method)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
Re: [android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
The bitmap issue on the Droid is really about whether you want to show more graphics at smaller size, or the same graphics at larger size. I don't know what you app does, but imagine that it's a 2d game, where the graphics are re-used a lot (land tiles, character icons, etc.). If you let the higher resolution screen show more of the game map at a time, your program will consume NEARLY identical memory to what it would on other devices. Why? Because the tiles will be the same size in memory; the only thing that would be larger would be the screen surface, and any back buffers you use. On the other hand, if you want the graphics on the Droid to look the same (same game play area visible), then without work, your application will take more memory on the Droid. Why? Because unless you explicitly avoid it, Android will scale your image up to higher resolution when you load them, so they take more memory. The solutions are to: 1) Create high-density images that are simply smaller, but occupy the same number of pixels. This way, loading resources on the denser devices won't take any memory, or 2) Resize the images after you load them, understanding that loading the exact same resource on two different devices may result in two different sized bitmaps in memory Of course approach #1 is the standard solution. I hope I am being clear. In short, if you want higher quality graphics, of course they will take more memory. If you want the same exact graphics (which will appear smaller on the denser screen), then you must do the work to make that happen, as it sounds like you are not now, so Android is scaling them up. SoftwareForMe.com Makers of PhoneMyPC On Wed, Dec 2, 2009 at 6:12 PM, Jason Proctor jason.android.li...@gmail.com wrote: IMHO, if the device offers 50% more memory per application, but the bitmaps take up more than 50% more memory, then the net effect is a stricter limitation. i'm seeing some occasional OOMs only on Droid, and so i'm being extra careful about recycling bitmaps and all that. At 5:40 PM -0800 12/2/09, Romain Guy wrote: The new device does not have stricter limitations since it gives apps more RAM (24 MB instead of 16 MB.) On Wed, Dec 2, 2009 at 5:29 PM, Matt Kanninen mathias...@gmail.com wrote: What did I do wrong? I worked within the defined limitations, then a new handset came out with stricter limitations. I'm kind of confused how you can blame me! On Dec 2, 5:19 pm, Romain Guy romain...@android.com wrote: The Droid has more pixels and a high display density, therefore bitmaps are scaled and require more memory. If your app is running out of memory, do not blame it on the framework and poorer performance, blame it on your app for doing the wrong thing and abusing the Java heap. The app worked great on the G1. I've clearly hit a case where the framework made some decisions that result in poorer performance on the Droid. The bitmap out of memory errors can still occur on any setLayout(res/ xml/id), after running the app for 5-30 mins. But I did fix the bitmap out of memory crash that occured during glow.setBackgroundResource(glowDrawableIds[scale]); We just don't set a new background resource anymore. I had 10 animation frames, and the animation frame chosen was based upon the volume coming from the mic. Now we take what was the last frame, and vary it's drawable's transparency depending on volume. glow.getBackground().setAlpha(alpha); I will now start creating additional res/xml/files, so that LESS complex layouts are used on the Verizon Motorola Droid with firmware 2.0 then we used on the G1. The layouts, and the final resulting screens were approved by management, so I will be trying hard not to change ANYTHING on the G1, while adding support for the inferior memory handling on the only Android 2.0 handset. The one with better specs. Can anyone recommend which Android debugging tool I should be using to figure out what to optimize? On Nov 25, 11:11 am, Streets Of Boston flyingdutc...@gmail.com wrote: As in the comment in your bug-report by Romain, you're using too much memory. Note that you only have 16MByte total available RAM for your process, including your bitmaps. - Only load the bitmaps that are absolutely necessary (especially when they become quite large). - Load the bitmaps scaled to the size of your screen, if possible. Use BitmapFactory.decode and set the 'inSampleSize' of your bitmap-options to scale down the size of the bitmap to be loaded and rendered on the screen. On Nov 25, 12:46 pm, MattKanninenmathias...@gmail.com wrote: a href=http://code.google.com/p/android/issues/detail?id=5045 Issue 5045/a http://code.google.com/p/android/issues/detail?id=5045 On Nov 25, 9:37 am, MattKanninenmathias...@gmail.com wrote:
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, Matt Kanninen mathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to persist new stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 objects / 15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 680-byte external
allocation too large for this process.
11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate 680
bytes
11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting down VM
11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread exiting
with uncaught exception (group=0x4001b180)
11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught handler:
thread main exiting due to uncaught exception
11-25 09:21:03.014: ERROR/AndroidRuntime(2386):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.nativeCreate(Native Method)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:468)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:435)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createScaledBitmap(Bitmap.java:340)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:488)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:462)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:
323)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.drawable.Drawable.createFromResourceStream
(Drawable.java:697)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.content.res.Resources.loadDrawable(Resources.java:1705)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.content.res.Resources.getDrawable(Resources.java:580)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.view.View.setBackgroundResource(View.java:7187)
--
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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
How big (dimensions) are the graphics Matt? If they're not very big
then I'm guessing you have bitmap memory used elsewhere in the app
that's putting you close to the max. Bitmap memory is different than
your heap memory, so it's management is hidden from you a little more
but basically this error means you have too many graphics loaded at
once, or are unloading and loading a lot of graphics in a row so the
finalizer can't reclaim the bitmap memory in time.
Matt
On Nov 25, 12:46 pm, Matt Kanninen mathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, Matt Kanninen mathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to persist new stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 objects / 15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 680-byte external
allocation too large for this process.
11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate 680
bytes
11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting down VM
11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread exiting
with uncaught exception (group=0x4001b180)
11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught handler:
thread main exiting due to uncaught exception
11-25 09:21:03.014: ERROR/AndroidRuntime(2386):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.nativeCreate(Native Method)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:468)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:435)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createScaledBitmap(Bitmap.java:340)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:488)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:462)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:
323)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.drawable.Drawable.createFromResourceStream
(Drawable.java:697)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.content.res.Resources.loadDrawable(Resources.java:1705)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.content.res.Resources.getDrawable(Resources.java:580)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.view.View.setBackgroundResource(View.java:7187)
--
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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
As in the comment in your bug-report by Romain, you're using too much
memory.
Note that you only have 16MByte total available RAM for your process,
including your bitmaps.
- Only load the bitmaps that are absolutely necessary (especially when
they become quite large).
- Load the bitmaps scaled to the size of your screen, if possible. Use
BitmapFactory.decode and set the 'inSampleSize' of your bitmap-options
to scale down the size of the bitmap to be loaded and rendered on the
screen.
On Nov 25, 12:46 pm, Matt Kanninen mathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, Matt Kanninen mathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to persist new stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 objects / 15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 680-byte external
allocation too large for this process.
11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate 680
bytes
11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting down VM
11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread exiting
with uncaught exception (group=0x4001b180)
11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught handler:
thread main exiting due to uncaught exception
11-25 09:21:03.014: ERROR/AndroidRuntime(2386):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.nativeCreate(Native Method)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:468)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:435)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createScaledBitmap(Bitmap.java:340)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:488)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:462)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:
323)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.drawable.Drawable.createFromResourceStream
(Drawable.java:697)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.content.res.Resources.loadDrawable(Resources.java:1705)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.content.res.Resources.getDrawable(Resources.java:580)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.view.View.setBackgroundResource(View.java:7187)- Hide quoted text -
- Show quoted text -
--
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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
Great guesses!
This happens randomly through my application, every half hour on a G1,
every 5 mins on the droid. The error happens randomly, usually in
setContentView, per another post of mine.
On Nov 25, 11:11 am, Streets Of Boston flyingdutc...@gmail.com
wrote:
As in the comment in your bug-report by Romain, you're using too much
memory.
Note that you only have 16MByte total available RAM for your process,
including your bitmaps.
- Only load the bitmaps that are absolutely necessary (especially when
they become quite large).
- Load the bitmaps scaled to the size of your screen, if possible. Use
BitmapFactory.decode and set the 'inSampleSize' of your bitmap-options
to scale down the size of the bitmap to be loaded and rendered on the
screen.
On Nov 25, 12:46 pm, Matt Kanninen mathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, Matt Kanninen mathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to persist new stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 objects / 15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 680-byte external
allocation too large for this process.
11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate 680
bytes
11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting down VM
11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread exiting
with uncaught exception (group=0x4001b180)
11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught handler:
thread main exiting due to uncaught exception
11-25 09:21:03.014: ERROR/AndroidRuntime(2386):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.nativeCreate(Native Method)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:468)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:435)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createScaledBitmap(Bitmap.java:340)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:488)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:462)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:
323)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.drawable.Drawable.createFromResourceStream
(Drawable.java:697)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.content.res.Resources.loadDrawable(Resources.java:1705)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.content.res.Resources.getDrawable(Resources.java:580)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.view.View.setBackgroundResource(View.java:7187)- Hide quoted text
-
- Show quoted text -
--
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
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
Matt,
So in this case I definitely am frequently loading and unloading small
images. Those 10 id's all point at different states in our
animation. I can reduce the quality of our animation by reducing the
views, and decrease how often I stumble down this cow path:
but I only posted this stack trace because it was new, this happens
anytime my app is run for more then half an hour, or 5 mins on the
droid. The droid uses the same apk, same images, and 2 slightly
different xmls (we added margins to our Droid xml).
http://groups.google.com/group/android-developers/browse_thread/thread/b455c6ac5782b7e7/c481a210b0f3c63d
or to quote myself:
If my app runs for more then half an hour on the G1 it will fail on
inflating views from xml, giving an error about insufficient memory
creating a bitmap. Another issue, which may be a side effect is that
global static strings that are assigned at startup become null.
I have worked around that by throwing up setters around those statics
that also store them as a private preference, and thrown up getters
that read the preference in case of null.
The root cause of all of my issues may be that when I call release on
my MediaRecorder it sometimes hangs. No crash it just never returns,
stalling the thread. I have worked around that by calling release in
a thread that only does that.
Is anyone else seeing and working around issues like these? I could
use some advice.
-Matt K
On Nov 25, 10:07 am, Matt Hall matt.h...@gmail.com wrote:
How big (dimensions) are the graphics Matt? If they're not very big
then I'm guessing you have bitmap memory used elsewhere in the app
that's putting you close to the max. Bitmap memory is different than
your heap memory, so it's management is hidden from you a little more
but basically this error means you have too many graphics loaded at
once, or are unloading and loading a lot of graphics in a row so the
finalizer can't reclaim the bitmap memory in time.
Matt
On Nov 25, 12:46 pm, Matt Kanninen mathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, Matt Kanninen mathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to persist new stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 objects / 15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 680-byte external
allocation too large for this process.
11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate 680
bytes
11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting down VM
11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread exiting
with uncaught exception (group=0x4001b180)
11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught handler:
thread main exiting due to uncaught exception
11-25 09:21:03.014: ERROR/AndroidRuntime(2386):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.nativeCreate(Native Method)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:468)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:435)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createScaledBitmap(Bitmap.java:340)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:488)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:462)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:
323)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.drawable.Drawable.createFromResourceStream
(Drawable.java:697)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.content.res.Resources.loadDrawable(Resources.java:1705)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
Re: [android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
Yeah, we've had a similar issue before. One thing you can try is to call
recycle() on the last frame of your animation before you replace it. This is
normally called by the garbage collector and works fine when you're not
close to the memory limit, but it sounds like there might be cases where you
temporarily go over the limit and the GC doesn't get to the bitmaps in time.
Matt
On Wed, Nov 25, 2009 at 2:37 PM, Matt Kanninen mathias...@gmail.com wrote:
Matt,
So in this case I definitely am frequently loading and unloading small
images. Those 10 id's all point at different states in our
animation. I can reduce the quality of our animation by reducing the
views, and decrease how often I stumble down this cow path:
but I only posted this stack trace because it was new, this happens
anytime my app is run for more then half an hour, or 5 mins on the
droid. The droid uses the same apk, same images, and 2 slightly
different xmls (we added margins to our Droid xml).
http://groups.google.com/group/android-developers/browse_thread/thread/b455c6ac5782b7e7/c481a210b0f3c63d
or to quote myself:
If my app runs for more then half an hour on the G1 it will fail on
inflating views from xml, giving an error about insufficient memory
creating a bitmap. Another issue, which may be a side effect is that
global static strings that are assigned at startup become null.
I have worked around that by throwing up setters around those statics
that also store them as a private preference, and thrown up getters
that read the preference in case of null.
The root cause of all of my issues may be that when I call release on
my MediaRecorder it sometimes hangs. No crash it just never returns,
stalling the thread. I have worked around that by calling release in
a thread that only does that.
Is anyone else seeing and working around issues like these? I could
use some advice.
-Matt K
On Nov 25, 10:07 am, Matt Hall matt.h...@gmail.com wrote:
How big (dimensions) are the graphics Matt? If they're not very big
then I'm guessing you have bitmap memory used elsewhere in the app
that's putting you close to the max. Bitmap memory is different than
your heap memory, so it's management is hidden from you a little more
but basically this error means you have too many graphics loaded at
once, or are unloading and loading a lot of graphics in a row so the
finalizer can't reclaim the bitmap memory in time.
Matt
On Nov 25, 12:46 pm, Matt Kanninen mathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, Matt Kanninen mathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to persist new
stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 objects /
15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 680-byte external
allocation too large for this process.
11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate 680
bytes
11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting down VM
11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread exiting
with uncaught exception (group=0x4001b180)
11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught handler:
thread main exiting due to uncaught exception
11-25 09:21:03.014: ERROR/AndroidRuntime(2386):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.nativeCreate(Native Method)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:468)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:435)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createScaledBitmap(Bitmap.java:340)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:488)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
Thank you, this is exactly the sort of workaround I was looking for.
I just filed the Media Recorder release bug, since the first bug got
closed so fast.
http://code.google.com/p/android/issues/detail?id=5047
On Nov 25, 11:43 am, Matt Hall matt.h...@gmail.com wrote:
Yeah, we've had a similar issue before. One thing you can try is to call
recycle() on the last frame of your animation before you replace it. This is
normally called by the garbage collector and works fine when you're not
close to the memory limit, but it sounds like there might be cases where you
temporarily go over the limit and the GC doesn't get to the bitmaps in time.
Matt
On Wed, Nov 25, 2009 at 2:37 PM, Matt Kanninen mathias...@gmail.com wrote:
Matt,
So in this case I definitely am frequently loading and unloading small
images. Those 10 id's all point at different states in our
animation. I can reduce the quality of our animation by reducing the
views, and decrease how often I stumble down this cow path:
but I only posted this stack trace because it was new, this happens
anytime my app is run for more then half an hour, or 5 mins on the
droid. The droid uses the same apk, same images, and 2 slightly
different xmls (we added margins to our Droid xml).
http://groups.google.com/group/android-developers/browse_thread/threa...
or to quote myself:
If my app runs for more then half an hour on the G1 it will fail on
inflating views from xml, giving an error about insufficient memory
creating a bitmap. Another issue, which may be a side effect is that
global static strings that are assigned at startup become null.
I have worked around that by throwing up setters around those statics
that also store them as a private preference, and thrown up getters
that read the preference in case of null.
The root cause of all of my issues may be that when I call release on
my MediaRecorder it sometimes hangs. No crash it just never returns,
stalling the thread. I have worked around that by calling release in
a thread that only does that.
Is anyone else seeing and working around issues like these? I could
use some advice.
-Matt K
On Nov 25, 10:07 am, Matt Hall matt.h...@gmail.com wrote:
How big (dimensions) are the graphics Matt? If they're not very big
then I'm guessing you have bitmap memory used elsewhere in the app
that's putting you close to the max. Bitmap memory is different than
your heap memory, so it's management is hidden from you a little more
but basically this error means you have too many graphics loaded at
once, or are unloading and loading a lot of graphics in a row so the
finalizer can't reclaim the bitmap memory in time.
Matt
On Nov 25, 12:46 pm, Matt Kanninen mathias...@gmail.com wrote:
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, Matt Kanninen mathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
R.drawable.graphic_microphoneglow_01,
R.drawable.graphic_microphoneglow_02,
R.drawable.graphic_microphoneglow_03,
R.drawable.graphic_microphoneglow_04,
R.drawable.graphic_microphoneglow_05,
R.drawable.graphic_microphoneglow_06,
R.drawable.graphic_microphoneglow_07,
R.drawable.graphic_microphoneglow_08,
R.drawable.graphic_microphoneglow_09,
R.drawable.graphic_microphoneglow_10
};
...
View glow = findViewById(R.id.glow);
..
glow.setBackgroundResource(glowDrawableIds[scale]);
is causing
11-25 09:21:02.046: WARN/UsageStats(1018): Failed to persist new
stats
11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 objects /
15656
bytes in 61ms
11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 680-byte external
allocation too large for this process.
11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate 680
bytes
11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting down VM
11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread exiting
with uncaught exception (group=0x4001b180)
11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught handler:
thread main exiting due to uncaught exception
11-25 09:21:03.014: ERROR/AndroidRuntime(2386):
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.nativeCreate(Native Method)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:468)
11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at
android.graphics.Bitmap.createBitmap(Bitmap.java:435)
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
I do this in my app as well, and it works fine using BitmapFactory. But i make sure that this large bitmap (full-size image, 6Mpix) is about the only one loaded in my application. If not, i get the same exception. Opening 2 of these large ones will give me this exception, whatever i do. On Apr 26, 11:10 am, anthony.dahanne anthony.daha...@gmail.com wrote: Hello ! While I'm trying to resize a photo (originally on a sd card), grabbed using : InputStream openInputStream = contentResolver.openInputStream (photoUri); I got the following stack trace when calling : Bitmap bitmap = BitmapFactory.decodeStream(openInputStream); 04-26 14:57:57.213: ERROR/dalvikvm-heap(349): 6291456-byte external allocation too large for this process. 04-26 14:57:57.224: ERROR/(349): VM won't let us allocate 6291456 bytes 04-26 14:57:57.234: DEBUG/skia(349): allocPixelRef failed 04-26 14:58:58.005: WARN/dalvikvm(349): threadid=15: thread exiting with uncaught exception (group=0x4000fe68) 04-26 14:58:58.014: ERROR/AndroidRuntime(349): Uncaught handler: thread Thread-19 exiting due to uncaught exception 04-26 14:58:58.153: ERROR/AndroidRuntime(349): java.lang.OutOfMemoryError: bitmap size exceeds VM budget 04-26 14:58:58.153: ERROR/AndroidRuntime(349): at android.graphics.BitmapFactory.nativeDecodeStream(Native Method) 04-26 14:58:58.153: ERROR/AndroidRuntime(349): at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:304) 04-26 14:58:58.153: ERROR/AndroidRuntime(349): at android.graphics.BitmapFactory.decodeFile(BitmapFactory.java:149) 04-26 14:58:58.153: ERROR/AndroidRuntime(349): at android.graphics.BitmapFactory.decodeFile(BitmapFactory.java:174) Do you know an alternative way to resize a picture ? without calling BitmapFactory ? and without getting such an exception ? Thanks in advance for your help Anthony --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
I've tried the unbind method and it doesnt seem to help my case :( It is a good thing to know and keep in mind. Rohit On Jan 23, 2:07 pm, JP joachim.pfeif...@gmail.com wrote: There's a bunch of discussions about this issue in this forum, just dig a little and you will find what you need to know. Also, Romain Guy posted a write-up about un-binding views (and bitmaps) from activities.http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks Admittedly, a lot to read up on. On Jan 23, 3:48 am, ad avra...@gmail.com wrote: I've problem with memory of the bitmaps, I'm creating a lot of bitmaps and then releasing them by recycle() and after many retries I get: java.lang.OutOfMemoryError: bitmap size exceeds VM budget How to get rid of this??? The problem is that even if i close the activity (call onDestroy()), in next program run the bitmap memory is still allocated (I've also android:clearTaskOnLaunch=true in my manifest). This is horrible. Can anybody help me with that? I suspect that every application using BitmapFactory.decodeResource must get this exception in some call! Do you have any idea what's going on? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
It seems that there my be a bug, memory leak with the BitmapFactory when decoding, and reading bitmaps from file. I, and many other developers have noticed similar problems to what you describe. I haven't been able to get any official confirmation that this is a known bug, but it looks like a bug to me. I have been able to mitigate this problem in my code by using bitmap.recycle and object pooling, but I have not been able to get rid of this problem entrirely. Mark On Jan 23, 3:48 am, ad avra...@gmail.com wrote: I've problem with memory of the bitmaps, I'm creating a lot of bitmaps and then releasing them by recycle() and after many retries I get: java.lang.OutOfMemoryError: bitmap size exceeds VM budget How to get rid of this??? The problem is that even if i close the activity (call onDestroy()), in next program run the bitmap memory is still allocated (I've also android:clearTaskOnLaunch=true in my manifest). This is horrible. Can anybody help me with that? I suspect that every application using BitmapFactory.decodeResource must get this exception in some call! Do you have any idea what's going on? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
There's a bunch of discussions about this issue in this forum, just dig a little and you will find what you need to know. Also, Romain Guy posted a write-up about un-binding views (and bitmaps) from activities. http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html Admittedly, a lot to read up on. On Jan 23, 3:48 am, ad avra...@gmail.com wrote: I've problem with memory of the bitmaps, I'm creating a lot of bitmaps and then releasing them by recycle() and after many retries I get: java.lang.OutOfMemoryError: bitmap size exceeds VM budget How to get rid of this??? The problem is that even if i close the activity (call onDestroy()), in next program run the bitmap memory is still allocated (I've also android:clearTaskOnLaunch=true in my manifest). This is horrible. Can anybody help me with that? I suspect that every application using BitmapFactory.decodeResource must get this exception in some call! Do you have any idea what's going on? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
