[android-developers] Re: Allocation too large for this process
Justin, with the BitmapFactory.Options way, I'm getting this problem even when not changing orientation a single time. It's known that the Gallery leaks, I demonstrated that to Romain in a different post, so I know that my bitmaps will never be deleted (presumably), but Romain suggested using BitmapFactory.Options to reduce the amount of leaked memory (and to reduce the app's memory hunger in general, regardless of any leaks). However, the downsizing of the bitmap didn't help at all. On Dec 12, 9:47 am, "Justin (Google Employee)" wrote: > Mike, > > Something in your original post (which I hadn't previously read) might > be a clue. You said that this often happens after orientation changes. > Orientation changes must be accelerating whatever memory leak you have > because they cause your activity to be shutdown and restarted. Make > sure in your onPause code you're doing any necessary cleanup and > double check anything you might be doing with static members. > > Cheers, > Justin > Android Team @ Google > > On Dec 11, 3:03 pm, EboMike wrote: > > > I tried using BitmapFactory.Options when calling > > BitmapFactory.decodePath() on Romain's recommendation to resize the > > 1024x768 JPG files down to 480x320 before displaying them in a > > Gallery, but that didn't help at all - if anything, it made things > > worse. The app still runs out after viewing just a few images. > > > -Mike > > > On Dec 11, 10:38 am, "Justin (Google Employee)" > > wrote: > > > > Are you scaling the image down when you display it? Look at the longer > > > form of BitmapFactory.decodeByteArray. The BitmapFactory.Options > > > argument has parameters for down sampling the image on load. > > > > Cheers, > > > Justin > > > Android Team @ Google > > > > On Dec 11, 10:10 am, fala70 wrote: > > > > > my application open in sequence 3 activities, on last I've this > > > > situation heap: > > > > ID Heap Size Allocated Free Used Objs. > > > > 1 2,945 MB 1,936 MB 1,009 MB 65,75% 38.365 > > > > > at any case I've a problem that I can't solve againg after much time > > > > that I am on. I need to show a list, grid or gallery of a few photo > > > > selected from user from internal or external memory. For that I used: > > > > > Uri target = Media.INTERNAL_CONTENT_URI; > > > > Intent intent = new Intent(Intent.ACTION_PICK, target); > > > > startActivityForResult(intent, GET_IMAGE_FROM_FOLDER); > > > > > and that work good. Then I know the picture id and if it is in > > > > internal or external media.. Now I need to show the thumbnail of these > > > > picture selected but that is impossible I can't do it for too much > > > > memory request. All picture are taked from camera. > > > > > is there a solution for resize the images without goi out of memory ? > > > > > On 11 Dic, 13:51, Romain Guy wrote: > > > > > > It works when you load a smaller file because you simply have very > > > > > little amount of memory left. Your application is using too much > > > > > memory, you need to trim it down. > > > > > > On Thu, Dec 11, 2008 at 1:00 AM,fala70 wrote: > > > > > > > I 've a similar problem. I am going crazy from several days Is > > > > > > impossible to show images from internal or external memory captured > > > > > > from camera. Also I tried to read a file jpg of 700KB and use > > > > > > BitmapFactory.decodeByteArray to get the bitmap, but I receive that > > > > > > exeption: > > > > > > > 12-11 00:50:27.819: ERROR/dalvikvm-heap(3547): 6291456-byte external > > > > > > allocation too large for this process. > > > > > > > if I try to load an image smaller (around 4K) > > > > > > BitmapFactory.decodeByteArray work good. > > > > > > > somebody has a solution ? > > > > > > -- > > > > > Romain Guywww.curious-creature.org --~--~-~--~~~---~--~~ 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: Allocation too large for this process
Mike, Something in your original post (which I hadn't previously read) might be a clue. You said that this often happens after orientation changes. Orientation changes must be accelerating whatever memory leak you have because they cause your activity to be shutdown and restarted. Make sure in your onPause code you're doing any necessary cleanup and double check anything you might be doing with static members. Cheers, Justin Android Team @ Google On Dec 11, 3:03 pm, EboMike wrote: > I tried using BitmapFactory.Options when calling > BitmapFactory.decodePath() on Romain's recommendation to resize the > 1024x768 JPG files down to 480x320 before displaying them in a > Gallery, but that didn't help at all - if anything, it made things > worse. The app still runs out after viewing just a few images. > > -Mike > > On Dec 11, 10:38 am, "Justin (Google Employee)" > wrote: > > > Are you scaling the image down when you display it? Look at the longer > > form of BitmapFactory.decodeByteArray. The BitmapFactory.Options > > argument has parameters for down sampling the image on load. > > > Cheers, > > Justin > > Android Team @ Google > > > On Dec 11, 10:10 am, fala70 wrote: > > > > my application open in sequence 3 activities, on last I've this > > > situation heap: > > > ID Heap Size Allocated Free Used Objs. > > > 1 2,945 MB 1,936 MB 1,009 MB 65,75% 38.365 > > > > at any case I've a problem that I can't solve againg after much time > > > that I am on. I need to show a list, grid or gallery of a few photo > > > selected from user from internal or external memory. For that I used: > > > > Uri target = Media.INTERNAL_CONTENT_URI; > > > Intent intent = new Intent(Intent.ACTION_PICK, target); > > > startActivityForResult(intent, GET_IMAGE_FROM_FOLDER); > > > > and that work good. Then I know the picture id and if it is in > > > internal or external media.. Now I need to show the thumbnail of these > > > picture selected but that is impossible I can't do it for too much > > > memory request. All picture are taked from camera. > > > > is there a solution for resize the images without goi out of memory ? > > > > On 11 Dic, 13:51, Romain Guy wrote: > > > > > It works when you load a smaller file because you simply have very > > > > little amount of memory left. Your application is using too much > > > > memory, you need to trim it down. > > > > > On Thu, Dec 11, 2008 at 1:00 AM,fala70 wrote: > > > > > > I 've a similar problem. I am going crazy from several days Is > > > > > impossible to show images from internal or external memory captured > > > > > from camera. Also I tried to read a file jpg of 700KB and use > > > > > BitmapFactory.decodeByteArray to get the bitmap, but I receive that > > > > > exeption: > > > > > > 12-11 00:50:27.819: ERROR/dalvikvm-heap(3547): 6291456-byte external > > > > > allocation too large for this process. > > > > > > if I try to load an image smaller (around 4K) > > > > > BitmapFactory.decodeByteArray work good. > > > > > > somebody has a solution ? > > > > > -- > > > > Romain Guywww.curious-creature.org > > --~--~-~--~~~---~--~~ 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: Allocation too large for this process
do you know how can I save on file a jpg format after decoded and resized the bitmap ? -Stefano --~--~-~--~~~---~--~~ 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: Allocation too large for this process
Not much to it, really. BitmapFactory.Options options = new BitmapFactory.Options(); // Get the dimensions only. options.inJustDecodeBounds = true; BitmapFactory.decodeFile(path, options); int width = options.outWidth; int height = options.outHeight; // At this point, change width and height to retain the aspect ratio but use a smaller size. // What you do here depends on the size of the images you expect. // If you always want to use a fixed size, you can skip the step above entirely and // just set width and height to those values. options.inJustDecodeBounds = false; options.outWidth = width; options.outHeight = height; Bitmap bitmap = BitmapFactory.decodeFile(path, options); drawable = new BitmapDrawable(bitmap); For good measure, I'm also using my own temporary storage to avoid having the BitmapFactory allocate and deallocate it twice. Do this when filling out the options object: options.inTempStorage = tempStorage; And add this to your class: byte[] tempStorage = new byte[16 * 1024]; (Obviously, this means that your function is not re-entrant, so keep that in mind if you do any sort of multi-threaded shenanigans.) (Likewise, if you want to cut down on memory allocations, use a persistent BitmapFactory.Options object as well.) -Mike On Dec 11, 3:12 pm, fala70 wrote: > Mike, can you explain me how did you use BitmapFactory.Options params > to resize the image ? > > Stefano > > On 12 Dic, 00:03, EboMike wrote: > > > I tried using BitmapFactory.Options when calling > > BitmapFactory.decodePath() on Romain's recommendation to resize the > > 1024x768 JPG files down to 480x320 before displaying them in a > > Gallery, but that didn't help at all - if anything, it made things > > worse. The app still runs out after viewing just a few images. > > > -Mike > > > On Dec 11, 10:38 am, "Justin (Google Employee)" > > wrote: > > > > Are you scaling the image down when you display it? Look at the longer > > > form of BitmapFactory.decodeByteArray. The BitmapFactory.Options > > > argument has parameters for down sampling the image on load. > > > > Cheers, > > > Justin > > > Android Team @ Google > > > > On Dec 11, 10:10 am, fala70 wrote: > > > > > my application open in sequence 3 activities, on last I've this > > > > situation heap: > > > > ID Heap Size Allocated Free Used Objs. > > > > 1 2,945 MB 1,936 MB 1,009 MB 65,75% 38.365 > > > > > at any case I've a problem that I can't solve againg after much time > > > > that I am on. I need to show a list, grid or gallery of a few photo > > > > selected from user from internal or external memory. For that I used: > > > > > Uri target = Media.INTERNAL_CONTENT_URI; > > > > Intent intent = new Intent(Intent.ACTION_PICK, target); > > > > startActivityForResult(intent, GET_IMAGE_FROM_FOLDER); > > > > > and that work good. Then I know the picture id and if it is in > > > > internal or external media.. Now I need to show the thumbnail of these > > > > picture selected but that is impossible I can't do it for too much > > > > memory request. All picture are taked from camera. > > > > > is there a solution for resize the images without goi out of memory ? > > > > > On 11 Dic, 13:51, Romain Guy wrote: > > > > > > It works when you load a smaller file because you simply have very > > > > > little amount of memory left. Your application is using too much > > > > > memory, you need to trim it down. > > > > > > On Thu, Dec 11, 2008 at 1:00 AM,fala70 wrote: > > > > > > > I 've a similar problem. I am going crazy from several days Is > > > > > > impossible to show images from internal or external memory captured > > > > > > from camera. Also I tried to read a file jpg of 700KB and use > > > > > > BitmapFactory.decodeByteArray to get the bitmap, but I receive that > > > > > > exeption: > > > > > > > 12-11 00:50:27.819: ERROR/dalvikvm-heap(3547): 6291456-byte external > > > > > > allocation too large for this process. > > > > > > > if I try to load an image smaller (around 4K) > > > > > > BitmapFactory.decodeByteArray work good. > > > > > > > somebody has a solution ? > > > > > > -- > > > > > Romain Guywww.curious-creature.org --~--~-~--~~~---~--~~ 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: Allocation too large for this process
Mike, can you explain me how did you use BitmapFactory.Options params to resize the image ? Stefano On 12 Dic, 00:03, EboMike wrote: > I tried using BitmapFactory.Options when calling > BitmapFactory.decodePath() on Romain's recommendation to resize the > 1024x768 JPG files down to 480x320 before displaying them in a > Gallery, but that didn't help at all - if anything, it made things > worse. The app still runs out after viewing just a few images. > > -Mike > > On Dec 11, 10:38 am, "Justin (Google Employee)" > wrote: > > > > > > > Are you scaling the image down when you display it? Look at the longer > > form of BitmapFactory.decodeByteArray. The BitmapFactory.Options > > argument has parameters for down sampling the image on load. > > > Cheers, > > Justin > > Android Team @ Google > > > On Dec 11, 10:10 am, fala70 wrote: > > > > my application open in sequence 3 activities, on last I've this > > > situation heap: > > > ID Heap Size Allocated Free Used Objs. > > > 1 2,945 MB 1,936 MB 1,009 MB 65,75% 38.365 > > > > at any case I've a problem that I can't solve againg after much time > > > that I am on. I need to show a list, grid or gallery of a few photo > > > selected from user from internal or external memory. For that I used: > > > > Uri target = Media.INTERNAL_CONTENT_URI; > > > Intent intent = new Intent(Intent.ACTION_PICK, target); > > > startActivityForResult(intent, GET_IMAGE_FROM_FOLDER); > > > > and that work good. Then I know the picture id and if it is in > > > internal or external media.. Now I need to show the thumbnail of these > > > picture selected but that is impossible I can't do it for too much > > > memory request. All picture are taked from camera. > > > > is there a solution for resize the images without goi out of memory ? > > > > On 11 Dic, 13:51, Romain Guy wrote: > > > > > It works when you load a smaller file because you simply have very > > > > little amount of memory left. Your application is using too much > > > > memory, you need to trim it down. > > > > > On Thu, Dec 11, 2008 at 1:00 AM,fala70 wrote: > > > > > > I 've a similar problem. I am going crazy from several days Is > > > > > impossible to show images from internal or external memory captured > > > > > from camera. Also I tried to read a file jpg of 700KB and use > > > > > BitmapFactory.decodeByteArray to get the bitmap, but I receive that > > > > > exeption: > > > > > > 12-11 00:50:27.819: ERROR/dalvikvm-heap(3547): 6291456-byte external > > > > > allocation too large for this process. > > > > > > if I try to load an image smaller (around 4K) > > > > > BitmapFactory.decodeByteArray work good. > > > > > > somebody has a solution ? > > > > > -- > > > > Romain Guywww.curious-creature.org > > --~--~-~--~~~---~--~~ 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: Allocation too large for this process
I tried using BitmapFactory.Options when calling BitmapFactory.decodePath() on Romain's recommendation to resize the 1024x768 JPG files down to 480x320 before displaying them in a Gallery, but that didn't help at all - if anything, it made things worse. The app still runs out after viewing just a few images. -Mike On Dec 11, 10:38 am, "Justin (Google Employee)" wrote: > Are you scaling the image down when you display it? Look at the longer > form of BitmapFactory.decodeByteArray. The BitmapFactory.Options > argument has parameters for down sampling the image on load. > > Cheers, > Justin > Android Team @ Google > > On Dec 11, 10:10 am, fala70 wrote: > > > my application open in sequence 3 activities, on last I've this > > situation heap: > > ID Heap Size Allocated Free Used Objs. > > 1 2,945 MB 1,936 MB 1,009 MB 65,75% 38.365 > > > at any case I've a problem that I can't solve againg after much time > > that I am on. I need to show a list, grid or gallery of a few photo > > selected from user from internal or external memory. For that I used: > > > Uri target = Media.INTERNAL_CONTENT_URI; > > Intent intent = new Intent(Intent.ACTION_PICK, target); > > startActivityForResult(intent, GET_IMAGE_FROM_FOLDER); > > > and that work good. Then I know the picture id and if it is in > > internal or external media.. Now I need to show the thumbnail of these > > picture selected but that is impossible I can't do it for too much > > memory request. All picture are taked from camera. > > > is there a solution for resize the images without goi out of memory ? > > > On 11 Dic, 13:51, Romain Guy wrote: > > > > It works when you load a smaller file because you simply have very > > > little amount of memory left. Your application is using too much > > > memory, you need to trim it down. > > > > On Thu, Dec 11, 2008 at 1:00 AM,fala70 wrote: > > > > > I 've a similar problem. I am going crazy from several days Is > > > > impossible to show images from internal or external memory captured > > > > from camera. Also I tried to read a file jpg of 700KB and use > > > > BitmapFactory.decodeByteArray to get the bitmap, but I receive that > > > > exeption: > > > > > 12-11 00:50:27.819: ERROR/dalvikvm-heap(3547): 6291456-byte external > > > > allocation too large for this process. > > > > > if I try to load an image smaller (around 4K) > > > > BitmapFactory.decodeByteArray work good. > > > > > somebody has a solution ? > > > > -- > > > Romain Guywww.curious-creature.org --~--~-~--~~~---~--~~ 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: Allocation too large for this process
Are you scaling the image down when you display it? Look at the longer form of BitmapFactory.decodeByteArray. The BitmapFactory.Options argument has parameters for down sampling the image on load. Cheers, Justin Android Team @ Google On Dec 11, 10:10 am, fala70 wrote: > my application open in sequence 3 activities, on last I've this > situation heap: > ID Heap Size Allocated Free Used Objs. > 1 2,945 MB 1,936 MB 1,009 MB 65,75% 38.365 > > at any case I've a problem that I can't solve againg after much time > that I am on. I need to show a list, grid or gallery of a few photo > selected from user from internal or external memory. For that I used: > > Uri target = Media.INTERNAL_CONTENT_URI; > Intent intent = new Intent(Intent.ACTION_PICK, target); > startActivityForResult(intent, GET_IMAGE_FROM_FOLDER); > > and that work good. Then I know the picture id and if it is in > internal or external media.. Now I need to show the thumbnail of these > picture selected but that is impossible I can't do it for too much > memory request. All picture are taked from camera. > > is there a solution for resize the images without goi out of memory ? > > On 11 Dic, 13:51, Romain Guy wrote: > > > It works when you load a smaller file because you simply have very > > little amount of memory left. Your application is using too much > > memory, you need to trim it down. > > > On Thu, Dec 11, 2008 at 1:00 AM,fala70 wrote: > > > > I 've a similar problem. I am going crazy from several days Is > > > impossible to show images from internal or external memory captured > > > from camera. Also I tried to read a file jpg of 700KB and use > > > BitmapFactory.decodeByteArray to get the bitmap, but I receive that > > > exeption: > > > > 12-11 00:50:27.819: ERROR/dalvikvm-heap(3547): 6291456-byte external > > > allocation too large for this process. > > > > if I try to load an image smaller (around 4K) > > > BitmapFactory.decodeByteArray work good. > > > > somebody has a solution ? > > > -- > > Romain Guywww.curious-creature.org > > --~--~-~--~~~---~--~~ 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: Allocation too large for this process
Well how would you trim it down without takeing away from the app. On 12/11/2008, fala70 wrote: > > my application open in sequence 3 activities, on last I've this > situation heap: > ID Heap Size Allocated Free Used Objs. > 1 2,945 MB1,936 MB1,009 MB65,75% 38.365 > > at any case I've a problem that I can't solve againg after much time > that I am on. I need to show a list, grid or gallery of a few photo > selected from user from internal or external memory. For that I used: > > Uri target = Media.INTERNAL_CONTENT_URI; > Intent intent = new Intent(Intent.ACTION_PICK, target); > startActivityForResult(intent, GET_IMAGE_FROM_FOLDER); > > and that work good. Then I know the picture id and if it is in > internal or external media.. Now I need to show the thumbnail of these > picture selected but that is impossible I can't do it for too much > memory request. All picture are taked from camera. > > is there a solution for resize the images without goi out of memory ? > > > On 11 Dic, 13:51, Romain Guy wrote: >> It works when you load a smaller file because you simply have very >> little amount of memory left. Your application is using too much >> memory, you need to trim it down. >> >> >> >> >> >> >> >> On Thu, Dec 11, 2008 at 1:00 AM,fala70 wrote: >> >> > I 've a similar problem. I am going crazy from several days Is >> > impossible to show images from internal or external memory captured >> > from camera. Also I tried to read a file jpg of 700KB and use >> > BitmapFactory.decodeByteArray to get the bitmap, but I receive that >> > exeption: >> >> > 12-11 00:50:27.819: ERROR/dalvikvm-heap(3547): 6291456-byte external >> > allocation too large for this process. >> >> > if I try to load an image smaller (around 4K) >> > BitmapFactory.decodeByteArray work good. >> >> > somebody has a solution ? >> >> -- >> Romain Guywww.curious-creature.org > > > -- Xavier A. Mathews Student/Browser Specialist/Developer/Web-Master Google Group Client Based Tech Support Specialist Hazel Crest Illinois xavieruni...@gmail.com¥xavierunited@hotmail.com¥truestar...@yahoo.com "Fear of a name, only increases fear of the thing itself." --~--~-~--~~~---~--~~ 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: Allocation too large for this process
my application open in sequence 3 activities, on last I've this situation heap: ID Heap Size Allocated Free Used Objs. 1 2,945 MB1,936 MB1,009 MB65,75% 38.365 at any case I've a problem that I can't solve againg after much time that I am on. I need to show a list, grid or gallery of a few photo selected from user from internal or external memory. For that I used: Uri target = Media.INTERNAL_CONTENT_URI; Intent intent = new Intent(Intent.ACTION_PICK, target); startActivityForResult(intent, GET_IMAGE_FROM_FOLDER); and that work good. Then I know the picture id and if it is in internal or external media.. Now I need to show the thumbnail of these picture selected but that is impossible I can't do it for too much memory request. All picture are taked from camera. is there a solution for resize the images without goi out of memory ? On 11 Dic, 13:51, Romain Guy wrote: > It works when you load a smaller file because you simply have very > little amount of memory left. Your application is using too much > memory, you need to trim it down. > > > > > > > > On Thu, Dec 11, 2008 at 1:00 AM,fala70 wrote: > > > I 've a similar problem. I am going crazy from several days Is > > impossible to show images from internal or external memory captured > > from camera. Also I tried to read a file jpg of 700KB and use > > BitmapFactory.decodeByteArray to get the bitmap, but I receive that > > exeption: > > > 12-11 00:50:27.819: ERROR/dalvikvm-heap(3547): 6291456-byte external > > allocation too large for this process. > > > if I try to load an image smaller (around 4K) > > BitmapFactory.decodeByteArray work good. > > > somebody has a solution ? > > -- > Romain Guywww.curious-creature.org --~--~-~--~~~---~--~~ 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: Allocation too large for this process
It works when you load a smaller file because you simply have very little amount of memory left. Your application is using too much memory, you need to trim it down. On Thu, Dec 11, 2008 at 1:00 AM, fala70 <[EMAIL PROTECTED]> wrote: > > I 've a similar problem. I am going crazy from several days Is > impossible to show images from internal or external memory captured > from camera. Also I tried to read a file jpg of 700KB and use > BitmapFactory.decodeByteArray to get the bitmap, but I receive that > exeption: > > 12-11 00:50:27.819: ERROR/dalvikvm-heap(3547): 6291456-byte external > allocation too large for this process. > > if I try to load an image smaller (around 4K) > BitmapFactory.decodeByteArray work good. > > somebody has a solution ? > > > -- Romain Guy www.curious-creature.org --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
fala70 wrote: > I 've a similar problem. I am going crazy from several days Is > impossible to show images from internal or external memory captured > from camera. Also I tried to read a file jpg of 700KB and use > BitmapFactory.decodeByteArray to get the bitmap, but I receive that > exeption: > > 12-11 00:50:27.819: ERROR/dalvikvm-heap(3547): 6291456-byte external > allocation too large for this process. > > if I try to load an image smaller (around 4K) > BitmapFactory.decodeByteArray work good. > > somebody has a solution ? Use a smaller image. A 700KB JPEG is fairly massive. Bear in mind that JPEG files have to be decompressed when they get turned into a bitmap. Apparently the uncompressed form of your image exceeds a limit on how big an individual memory allocation can be. Furthermore, a 700KB JPEG has *got* to have a resolution bigger than what the G1 can handle. If you intend to show the whole image via some sort of panning mechanism, consider splitting the image up into discrete tiles, akin to what Google Maps does. -- Mark Murphy (a Commons Guy) http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009 http://www.bignerdranch.com/schedule.shtml --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
I 've a similar problem. I am going crazy from several days Is impossible to show images from internal or external memory captured from camera. Also I tried to read a file jpg of 700KB and use BitmapFactory.decodeByteArray to get the bitmap, but I receive that exeption: 12-11 00:50:27.819: ERROR/dalvikvm-heap(3547): 6291456-byte external allocation too large for this process. if I try to load an image smaller (around 4K) BitmapFactory.decodeByteArray work good. somebody has a solution ? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
Any ideas? I've created a little test app that's nothing more than a Gallery with an adapter that creates an ImageView and populates it through new BitmapDrawable(BitmapFactory.decodeFile(filename)), with always the same filename. Every time a new view is created, the "data object" size increases by 2KB or so. What is classified as a "data object" and how can I track them? Likewise, the 1-byte array heap also goes up by 32KB every time, as do the 4-byte arrays (by 4KB). And finally, how is the 16MB heap an application has split up? In the constructor of my test app, Runtime.getRuntime().freeMemory() returns ~760KB. -Mike On Nov 16, 12:34 pm, EboMike <[EMAIL PROTECTED]> wrote: > I'm reading JPGs off the storage device, and they are typically > 1024x768 since they came straight from a server. The VM typically > errors out allocating ~1MB of memory. (One time, it errored allocating > 30KB even though the gc freed up 900KB just prior to that). > > Yeah, I could have the server crunch the image to 480x320 first, but > I'd like to reserve the option to add a zoom function later. Besides, > it DOES work most of the time, and if I really have a 16MB heap, there > shouldn't be any issues whatsoever. > > By the way, it does seem like there might be a leak - in the "data > object" row in the Heap DDMS view, I seem to be leaking 10KB or so > with every image. How can I track down what's going on there? Like I > mentioned earlier, my BitmapDrawables are deleted properly according > to the allocation tracker. > > -Mike > > On Nov 16, 12:02 pm, Romain Guy <[EMAIL PROTECTED]> wrote: > > > What is the size of the Bitmap you are trying to create? > > > On Sun, Nov 16, 2008 at 11:33 AM, EboMike <[EMAIL PROTECTED]> wrote: > > > > Um, yes... except that I'm randomly getting OutOfMemoryExceptions when > > > I create a new bitmap :) > > > > On Nov 16, 11:13 am, Romain Guy <[EMAIL PROTECTED]> wrote: > > >> 16 MB is the maximum limit of the heap. Your app can use at most 16 > > >> MB. The heap in your application will grow as more memory is needed. > > >> If you're currently at 3/4 MB, then everything's fine :)) > > > >> On Sun, Nov 16, 2008 at 11:00 AM, EboMike <[EMAIL PROTECTED]> wrote: > > > >> > Thanks for your answer, Romain! > > > >> > How much of those 16MB are accessible to the app? When I look at the > > >> > Heap view in the DDMS, I only see one heap with a total size of 3MB, > > >> > sometimes 4MB. If I add up all the allocations (either in the VM Heap > > >> > or the allocation tracker), I don't get anywhere near 16 MB. I also > > >> > don't see any major allocation from the drawables themselves other > > >> > than 16KB for the BufferedInputReader and BitmapFactory per drawable - > > >> > is the bitmap data being allocated by native code and invisible to the > > >> > VM allocation tracker? > > > >> > After a gc, Runtime.getRuntime().freeMemory() typically gives me > > >> > numbers between 600KB and 800KB at any given point while I have the > > >> > Gallery up. > > > >> > It also seems that I'm not leaking any drawables, at least judging by > > >> > the number of BitmapDrawable/Bitmap/BufferedInputRead/BitmapFactory > > >> > objects I have in the allocation tracker - they match the amount of > > >> > visible views in my gallery. > > > >> > -Mike > > > >> > On Nov 15, 1:01 am, Romain Guy <[EMAIL PROTECTED]> wrote: > > >> >> Applications have a hard limit of 16 MB. As for the other bug you > > >> >> mention, it has nothing to do with memory usage; the implementation of > > >> >> BitmapFactory that reads images from URL will fail over slow > > >> >> connections. Besides, when you load a Drawable from the resources, it > > >> >> simply calls the BitmapFactory to decode the resource anyway. > > > >> >> If you hit an out of memory exception, your app *is* using too much > > >> >> memory (which you might very well be "leaking," it's not that hard, > > >> >> especially if you use static fields in your code.) You can use DDMS > > >> >> and its allocation tracker, as well as its various GC/heap monitors to > > >> >> see when and how your application is allocating so much memory. > > > >> >> I have run myself into this issue several times over the past 18 > > >> >> months and every time, the application was leaking something > > >> >> (especially on screen rotation.) > > > >> >> On Sat, Nov 15, 2008 at 12:55 AM, blindfold <[EMAIL PROTECTED]> wrote: > > > >> >> > Well Mike, I don't know either, but just remember from my own app > > >> >> > that > > >> >> > I too had a zillion unexplained "Clamp target GC heap" messages at > > >> >> > that 16 MB limit (while my app definitely needs far less memory than > > >> >> > that), until I got rid of Drawables altogether. It could have been a > > >> >> > coincidence, but together with the report from a Google Android Team > > >> >> > member > > >> >> > thathttp://groups.google.com/group/android-developers/browse_thread/threa... > > >> >> > "this is a known bug" (without being more sp
[android-developers] Re: Allocation too large for this process
I'm reading JPGs off the storage device, and they are typically
1024x768 since they came straight from a server. The VM typically
errors out allocating ~1MB of memory. (One time, it errored allocating
30KB even though the gc freed up 900KB just prior to that).
Yeah, I could have the server crunch the image to 480x320 first, but
I'd like to reserve the option to add a zoom function later. Besides,
it DOES work most of the time, and if I really have a 16MB heap, there
shouldn't be any issues whatsoever.
By the way, it does seem like there might be a leak - in the "data
object" row in the Heap DDMS view, I seem to be leaking 10KB or so
with every image. How can I track down what's going on there? Like I
mentioned earlier, my BitmapDrawables are deleted properly according
to the allocation tracker.
-Mike
On Nov 16, 12:02 pm, Romain Guy <[EMAIL PROTECTED]> wrote:
> What is the size of the Bitmap you are trying to create?
>
>
>
> On Sun, Nov 16, 2008 at 11:33 AM, EboMike <[EMAIL PROTECTED]> wrote:
>
> > Um, yes... except that I'm randomly getting OutOfMemoryExceptions when
> > I create a new bitmap :)
>
> > On Nov 16, 11:13 am, Romain Guy <[EMAIL PROTECTED]> wrote:
> >> 16 MB is the maximum limit of the heap. Your app can use at most 16
> >> MB. The heap in your application will grow as more memory is needed.
> >> If you're currently at 3/4 MB, then everything's fine :))
>
> >> On Sun, Nov 16, 2008 at 11:00 AM, EboMike <[EMAIL PROTECTED]> wrote:
>
> >> > Thanks for your answer, Romain!
>
> >> > How much of those 16MB are accessible to the app? When I look at the
> >> > Heap view in the DDMS, I only see one heap with a total size of 3MB,
> >> > sometimes 4MB. If I add up all the allocations (either in the VM Heap
> >> > or the allocation tracker), I don't get anywhere near 16 MB. I also
> >> > don't see any major allocation from the drawables themselves other
> >> > than 16KB for the BufferedInputReader and BitmapFactory per drawable -
> >> > is the bitmap data being allocated by native code and invisible to the
> >> > VM allocation tracker?
>
> >> > After a gc, Runtime.getRuntime().freeMemory() typically gives me
> >> > numbers between 600KB and 800KB at any given point while I have the
> >> > Gallery up.
>
> >> > It also seems that I'm not leaking any drawables, at least judging by
> >> > the number of BitmapDrawable/Bitmap/BufferedInputRead/BitmapFactory
> >> > objects I have in the allocation tracker - they match the amount of
> >> > visible views in my gallery.
>
> >> > -Mike
>
> >> > On Nov 15, 1:01 am, Romain Guy <[EMAIL PROTECTED]> wrote:
> >> >> Applications have a hard limit of 16 MB. As for the other bug you
> >> >> mention, it has nothing to do with memory usage; the implementation of
> >> >> BitmapFactory that reads images from URL will fail over slow
> >> >> connections. Besides, when you load a Drawable from the resources, it
> >> >> simply calls the BitmapFactory to decode the resource anyway.
>
> >> >> If you hit an out of memory exception, your app *is* using too much
> >> >> memory (which you might very well be "leaking," it's not that hard,
> >> >> especially if you use static fields in your code.) You can use DDMS
> >> >> and its allocation tracker, as well as its various GC/heap monitors to
> >> >> see when and how your application is allocating so much memory.
>
> >> >> I have run myself into this issue several times over the past 18
> >> >> months and every time, the application was leaking something
> >> >> (especially on screen rotation.)
>
> >> >> On Sat, Nov 15, 2008 at 12:55 AM, blindfold <[EMAIL PROTECTED]> wrote:
>
> >> >> > Well Mike, I don't know either, but just remember from my own app that
> >> >> > I too had a zillion unexplained "Clamp target GC heap" messages at
> >> >> > that 16 MB limit (while my app definitely needs far less memory than
> >> >> > that), until I got rid of Drawables altogether. It could have been a
> >> >> > coincidence, but together with the report from a Google Android Team
> >> >> > member
> >> >> > thathttp://groups.google.com/group/android-developers/browse_thread/threa...
> >> >> > "this is a known bug" (without being more specific) and his Drawable-
> >> >> > free workaround it suggested that this could be related to your
> >> >> > problem. Of course there are plenty of other things that could be
> >> >> > wrong...
>
> >> >> >> This is for an ImageSwitcher, so I need a Drawable of some sort
>
> >> >> > I have never used ImageSwitcher myself (Android seems to often offer
> >> >> > at least three totally different ways to do the same thing, which is
> >> >> > nice if two-out-of-three are still too buggy for deployment ). Yet
> >> >> > to avoid Drawables there I could imagine trying
> >> >> > ImageSwitcher.setImageURI(new ContentURI("/data/data/mypackage/files/
> >> >> > myimage.jpg")) if the image is in internal flash, or
> >> >> > ImageSwitcher.setImageURI(new ContentURI("/sdcard/mypath/
> >> >> > myimage.jpg")) when loading from SD card. Ju
[android-developers] Re: Allocation too large for this process
What is the size of the Bitmap you are trying to create?
On Sun, Nov 16, 2008 at 11:33 AM, EboMike <[EMAIL PROTECTED]> wrote:
>
> Um, yes... except that I'm randomly getting OutOfMemoryExceptions when
> I create a new bitmap :)
>
>
> On Nov 16, 11:13 am, Romain Guy <[EMAIL PROTECTED]> wrote:
>> 16 MB is the maximum limit of the heap. Your app can use at most 16
>> MB. The heap in your application will grow as more memory is needed.
>> If you're currently at 3/4 MB, then everything's fine :))
>>
>>
>>
>> On Sun, Nov 16, 2008 at 11:00 AM, EboMike <[EMAIL PROTECTED]> wrote:
>>
>> > Thanks for your answer, Romain!
>>
>> > How much of those 16MB are accessible to the app? When I look at the
>> > Heap view in the DDMS, I only see one heap with a total size of 3MB,
>> > sometimes 4MB. If I add up all the allocations (either in the VM Heap
>> > or the allocation tracker), I don't get anywhere near 16 MB. I also
>> > don't see any major allocation from the drawables themselves other
>> > than 16KB for the BufferedInputReader and BitmapFactory per drawable -
>> > is the bitmap data being allocated by native code and invisible to the
>> > VM allocation tracker?
>>
>> > After a gc, Runtime.getRuntime().freeMemory() typically gives me
>> > numbers between 600KB and 800KB at any given point while I have the
>> > Gallery up.
>>
>> > It also seems that I'm not leaking any drawables, at least judging by
>> > the number of BitmapDrawable/Bitmap/BufferedInputRead/BitmapFactory
>> > objects I have in the allocation tracker - they match the amount of
>> > visible views in my gallery.
>>
>> > -Mike
>>
>> > On Nov 15, 1:01 am, Romain Guy <[EMAIL PROTECTED]> wrote:
>> >> Applications have a hard limit of 16 MB. As for the other bug you
>> >> mention, it has nothing to do with memory usage; the implementation of
>> >> BitmapFactory that reads images from URL will fail over slow
>> >> connections. Besides, when you load a Drawable from the resources, it
>> >> simply calls the BitmapFactory to decode the resource anyway.
>>
>> >> If you hit an out of memory exception, your app *is* using too much
>> >> memory (which you might very well be "leaking," it's not that hard,
>> >> especially if you use static fields in your code.) You can use DDMS
>> >> and its allocation tracker, as well as its various GC/heap monitors to
>> >> see when and how your application is allocating so much memory.
>>
>> >> I have run myself into this issue several times over the past 18
>> >> months and every time, the application was leaking something
>> >> (especially on screen rotation.)
>>
>> >> On Sat, Nov 15, 2008 at 12:55 AM, blindfold <[EMAIL PROTECTED]> wrote:
>>
>> >> > Well Mike, I don't know either, but just remember from my own app that
>> >> > I too had a zillion unexplained "Clamp target GC heap" messages at
>> >> > that 16 MB limit (while my app definitely needs far less memory than
>> >> > that), until I got rid of Drawables altogether. It could have been a
>> >> > coincidence, but together with the report from a Google Android Team
>> >> > member
>> >> > thathttp://groups.google.com/group/android-developers/browse_thread/threa...
>> >> > "this is a known bug" (without being more specific) and his Drawable-
>> >> > free workaround it suggested that this could be related to your
>> >> > problem. Of course there are plenty of other things that could be
>> >> > wrong...
>>
>> >> >> This is for an ImageSwitcher, so I need a Drawable of some sort
>>
>> >> > I have never used ImageSwitcher myself (Android seems to often offer
>> >> > at least three totally different ways to do the same thing, which is
>> >> > nice if two-out-of-three are still too buggy for deployment ). Yet
>> >> > to avoid Drawables there I could imagine trying
>> >> > ImageSwitcher.setImageURI(new ContentURI("/data/data/mypackage/files/
>> >> > myimage.jpg")) if the image is in internal flash, or
>> >> > ImageSwitcher.setImageURI(new ContentURI("/sdcard/mypath/
>> >> > myimage.jpg")) when loading from SD card. Just my two cent guess.
>>
>> >> > Regards
>>
>> >> > On Nov 15, 7:57 am, EboMike <[EMAIL PROTECTED]> wrote:
>> >> >> Hey blind, you're right, I'm using Drawables -- BitmapDrawables, to be
>> >> >> precise. This is for an ImageSwitcher, so I need a Drawable of some
>> >> >> sort (since I'm loading jpeg images off the storage device, so I can't
>> >> >> use resources). I've tried BitmapFactory.decodeFile() instead of
>> >> >> BitmapDrawables constructor that takes a String, but I get the same
>> >> >> result, except that the OutOfMemoryException is now in
>> >> >> BitmapFactory.decodeFile() itself instead of a cryptic callstack like
>> >> >> before.
>>
>> >> >> I also call the gc right before creating the Bitmap... and the TTY is
>> >> >> kind of interesting:
>>
>> >> >> 06:50:43.970: INFO/dalvikvm-heap(6039): Clamp target GC heap from
>> >> >> 17.019MB to 16.000MB
>> >> >> 06:50:43.990: DEBUG/dalvikvm(6039): GC freed 8139 objects / 927224
>> >> >> bytes in 171ms
>> >> >>
[android-developers] Re: Allocation too large for this process
Um, yes... except that I'm randomly getting OutOfMemoryExceptions when
I create a new bitmap :)
On Nov 16, 11:13 am, Romain Guy <[EMAIL PROTECTED]> wrote:
> 16 MB is the maximum limit of the heap. Your app can use at most 16
> MB. The heap in your application will grow as more memory is needed.
> If you're currently at 3/4 MB, then everything's fine :))
>
>
>
> On Sun, Nov 16, 2008 at 11:00 AM, EboMike <[EMAIL PROTECTED]> wrote:
>
> > Thanks for your answer, Romain!
>
> > How much of those 16MB are accessible to the app? When I look at the
> > Heap view in the DDMS, I only see one heap with a total size of 3MB,
> > sometimes 4MB. If I add up all the allocations (either in the VM Heap
> > or the allocation tracker), I don't get anywhere near 16 MB. I also
> > don't see any major allocation from the drawables themselves other
> > than 16KB for the BufferedInputReader and BitmapFactory per drawable -
> > is the bitmap data being allocated by native code and invisible to the
> > VM allocation tracker?
>
> > After a gc, Runtime.getRuntime().freeMemory() typically gives me
> > numbers between 600KB and 800KB at any given point while I have the
> > Gallery up.
>
> > It also seems that I'm not leaking any drawables, at least judging by
> > the number of BitmapDrawable/Bitmap/BufferedInputRead/BitmapFactory
> > objects I have in the allocation tracker - they match the amount of
> > visible views in my gallery.
>
> > -Mike
>
> > On Nov 15, 1:01 am, Romain Guy <[EMAIL PROTECTED]> wrote:
> >> Applications have a hard limit of 16 MB. As for the other bug you
> >> mention, it has nothing to do with memory usage; the implementation of
> >> BitmapFactory that reads images from URL will fail over slow
> >> connections. Besides, when you load a Drawable from the resources, it
> >> simply calls the BitmapFactory to decode the resource anyway.
>
> >> If you hit an out of memory exception, your app *is* using too much
> >> memory (which you might very well be "leaking," it's not that hard,
> >> especially if you use static fields in your code.) You can use DDMS
> >> and its allocation tracker, as well as its various GC/heap monitors to
> >> see when and how your application is allocating so much memory.
>
> >> I have run myself into this issue several times over the past 18
> >> months and every time, the application was leaking something
> >> (especially on screen rotation.)
>
> >> On Sat, Nov 15, 2008 at 12:55 AM, blindfold <[EMAIL PROTECTED]> wrote:
>
> >> > Well Mike, I don't know either, but just remember from my own app that
> >> > I too had a zillion unexplained "Clamp target GC heap" messages at
> >> > that 16 MB limit (while my app definitely needs far less memory than
> >> > that), until I got rid of Drawables altogether. It could have been a
> >> > coincidence, but together with the report from a Google Android Team
> >> > member
> >> > thathttp://groups.google.com/group/android-developers/browse_thread/threa...
> >> > "this is a known bug" (without being more specific) and his Drawable-
> >> > free workaround it suggested that this could be related to your
> >> > problem. Of course there are plenty of other things that could be
> >> > wrong...
>
> >> >> This is for an ImageSwitcher, so I need a Drawable of some sort
>
> >> > I have never used ImageSwitcher myself (Android seems to often offer
> >> > at least three totally different ways to do the same thing, which is
> >> > nice if two-out-of-three are still too buggy for deployment ). Yet
> >> > to avoid Drawables there I could imagine trying
> >> > ImageSwitcher.setImageURI(new ContentURI("/data/data/mypackage/files/
> >> > myimage.jpg")) if the image is in internal flash, or
> >> > ImageSwitcher.setImageURI(new ContentURI("/sdcard/mypath/
> >> > myimage.jpg")) when loading from SD card. Just my two cent guess.
>
> >> > Regards
>
> >> > On Nov 15, 7:57 am, EboMike <[EMAIL PROTECTED]> wrote:
> >> >> Hey blind, you're right, I'm using Drawables -- BitmapDrawables, to be
> >> >> precise. This is for an ImageSwitcher, so I need a Drawable of some
> >> >> sort (since I'm loading jpeg images off the storage device, so I can't
> >> >> use resources). I've tried BitmapFactory.decodeFile() instead of
> >> >> BitmapDrawables constructor that takes a String, but I get the same
> >> >> result, except that the OutOfMemoryException is now in
> >> >> BitmapFactory.decodeFile() itself instead of a cryptic callstack like
> >> >> before.
>
> >> >> I also call the gc right before creating the Bitmap... and the TTY is
> >> >> kind of interesting:
>
> >> >> 06:50:43.970: INFO/dalvikvm-heap(6039): Clamp target GC heap from
> >> >> 17.019MB to 16.000MB
> >> >> 06:50:43.990: DEBUG/dalvikvm(6039): GC freed 8139 objects / 927224
> >> >> bytes in 171ms
> >> >> 06:50:45.271: ERROR/dalvikvm-heap(6039): 38400-byte external
> >> >> allocation too large for this process.
> >> >> 06:50:45.271: ERROR/(6039): VM won't let us allocate 38400 bytes
> >> >> 06:50:45.280: DEBUG/skia(6039): xxx
[android-developers] Re: Allocation too large for this process
16 MB is the maximum limit of the heap. Your app can use at most 16
MB. The heap in your application will grow as more memory is needed.
If you're currently at 3/4 MB, then everything's fine :))
On Sun, Nov 16, 2008 at 11:00 AM, EboMike <[EMAIL PROTECTED]> wrote:
>
> Thanks for your answer, Romain!
>
> How much of those 16MB are accessible to the app? When I look at the
> Heap view in the DDMS, I only see one heap with a total size of 3MB,
> sometimes 4MB. If I add up all the allocations (either in the VM Heap
> or the allocation tracker), I don't get anywhere near 16 MB. I also
> don't see any major allocation from the drawables themselves other
> than 16KB for the BufferedInputReader and BitmapFactory per drawable -
> is the bitmap data being allocated by native code and invisible to the
> VM allocation tracker?
>
> After a gc, Runtime.getRuntime().freeMemory() typically gives me
> numbers between 600KB and 800KB at any given point while I have the
> Gallery up.
>
> It also seems that I'm not leaking any drawables, at least judging by
> the number of BitmapDrawable/Bitmap/BufferedInputRead/BitmapFactory
> objects I have in the allocation tracker - they match the amount of
> visible views in my gallery.
>
> -Mike
>
>
> On Nov 15, 1:01 am, Romain Guy <[EMAIL PROTECTED]> wrote:
>> Applications have a hard limit of 16 MB. As for the other bug you
>> mention, it has nothing to do with memory usage; the implementation of
>> BitmapFactory that reads images from URL will fail over slow
>> connections. Besides, when you load a Drawable from the resources, it
>> simply calls the BitmapFactory to decode the resource anyway.
>>
>> If you hit an out of memory exception, your app *is* using too much
>> memory (which you might very well be "leaking," it's not that hard,
>> especially if you use static fields in your code.) You can use DDMS
>> and its allocation tracker, as well as its various GC/heap monitors to
>> see when and how your application is allocating so much memory.
>>
>> I have run myself into this issue several times over the past 18
>> months and every time, the application was leaking something
>> (especially on screen rotation.)
>>
>>
>>
>> On Sat, Nov 15, 2008 at 12:55 AM, blindfold <[EMAIL PROTECTED]> wrote:
>>
>> > Well Mike, I don't know either, but just remember from my own app that
>> > I too had a zillion unexplained "Clamp target GC heap" messages at
>> > that 16 MB limit (while my app definitely needs far less memory than
>> > that), until I got rid of Drawables altogether. It could have been a
>> > coincidence, but together with the report from a Google Android Team
>> > member
>> > thathttp://groups.google.com/group/android-developers/browse_thread/threa...
>> > "this is a known bug" (without being more specific) and his Drawable-
>> > free workaround it suggested that this could be related to your
>> > problem. Of course there are plenty of other things that could be
>> > wrong...
>>
>> >> This is for an ImageSwitcher, so I need a Drawable of some sort
>>
>> > I have never used ImageSwitcher myself (Android seems to often offer
>> > at least three totally different ways to do the same thing, which is
>> > nice if two-out-of-three are still too buggy for deployment ). Yet
>> > to avoid Drawables there I could imagine trying
>> > ImageSwitcher.setImageURI(new ContentURI("/data/data/mypackage/files/
>> > myimage.jpg")) if the image is in internal flash, or
>> > ImageSwitcher.setImageURI(new ContentURI("/sdcard/mypath/
>> > myimage.jpg")) when loading from SD card. Just my two cent guess.
>>
>> > Regards
>>
>> > On Nov 15, 7:57 am, EboMike <[EMAIL PROTECTED]> wrote:
>> >> Hey blind, you're right, I'm using Drawables -- BitmapDrawables, to be
>> >> precise. This is for an ImageSwitcher, so I need a Drawable of some
>> >> sort (since I'm loading jpeg images off the storage device, so I can't
>> >> use resources). I've tried BitmapFactory.decodeFile() instead of
>> >> BitmapDrawables constructor that takes a String, but I get the same
>> >> result, except that the OutOfMemoryException is now in
>> >> BitmapFactory.decodeFile() itself instead of a cryptic callstack like
>> >> before.
>>
>> >> I also call the gc right before creating the Bitmap... and the TTY is
>> >> kind of interesting:
>>
>> >> 06:50:43.970: INFO/dalvikvm-heap(6039): Clamp target GC heap from
>> >> 17.019MB to 16.000MB
>> >> 06:50:43.990: DEBUG/dalvikvm(6039): GC freed 8139 objects / 927224
>> >> bytes in 171ms
>> >> 06:50:45.271: ERROR/dalvikvm-heap(6039): 38400-byte external
>> >> allocation too large for this process.
>> >> 06:50:45.271: ERROR/(6039): VM won't let us allocate 38400 bytes
>> >> 06:50:45.280: DEBUG/skia(6039): allocPixelRef
>> >> failed
>>
>> >> The gc freed 927KB, and then cannot allocate 38KB? Um, what?
>>
>> >> -Mike
>>
>> --
>> Romain Guywww.curious-creature.org
> >
>
--
Romain Guy
www.curious-creature.org
--~--~-~--~~~---~--~~
You received this m
[android-developers] Re: Allocation too large for this process
Thanks for your answer, Romain!
How much of those 16MB are accessible to the app? When I look at the
Heap view in the DDMS, I only see one heap with a total size of 3MB,
sometimes 4MB. If I add up all the allocations (either in the VM Heap
or the allocation tracker), I don't get anywhere near 16 MB. I also
don't see any major allocation from the drawables themselves other
than 16KB for the BufferedInputReader and BitmapFactory per drawable -
is the bitmap data being allocated by native code and invisible to the
VM allocation tracker?
After a gc, Runtime.getRuntime().freeMemory() typically gives me
numbers between 600KB and 800KB at any given point while I have the
Gallery up.
It also seems that I'm not leaking any drawables, at least judging by
the number of BitmapDrawable/Bitmap/BufferedInputRead/BitmapFactory
objects I have in the allocation tracker - they match the amount of
visible views in my gallery.
-Mike
On Nov 15, 1:01 am, Romain Guy <[EMAIL PROTECTED]> wrote:
> Applications have a hard limit of 16 MB. As for the other bug you
> mention, it has nothing to do with memory usage; the implementation of
> BitmapFactory that reads images from URL will fail over slow
> connections. Besides, when you load a Drawable from the resources, it
> simply calls the BitmapFactory to decode the resource anyway.
>
> If you hit an out of memory exception, your app *is* using too much
> memory (which you might very well be "leaking," it's not that hard,
> especially if you use static fields in your code.) You can use DDMS
> and its allocation tracker, as well as its various GC/heap monitors to
> see when and how your application is allocating so much memory.
>
> I have run myself into this issue several times over the past 18
> months and every time, the application was leaking something
> (especially on screen rotation.)
>
>
>
> On Sat, Nov 15, 2008 at 12:55 AM, blindfold <[EMAIL PROTECTED]> wrote:
>
> > Well Mike, I don't know either, but just remember from my own app that
> > I too had a zillion unexplained "Clamp target GC heap" messages at
> > that 16 MB limit (while my app definitely needs far less memory than
> > that), until I got rid of Drawables altogether. It could have been a
> > coincidence, but together with the report from a Google Android Team
> > member
> > thathttp://groups.google.com/group/android-developers/browse_thread/threa...
> > "this is a known bug" (without being more specific) and his Drawable-
> > free workaround it suggested that this could be related to your
> > problem. Of course there are plenty of other things that could be
> > wrong...
>
> >> This is for an ImageSwitcher, so I need a Drawable of some sort
>
> > I have never used ImageSwitcher myself (Android seems to often offer
> > at least three totally different ways to do the same thing, which is
> > nice if two-out-of-three are still too buggy for deployment ). Yet
> > to avoid Drawables there I could imagine trying
> > ImageSwitcher.setImageURI(new ContentURI("/data/data/mypackage/files/
> > myimage.jpg")) if the image is in internal flash, or
> > ImageSwitcher.setImageURI(new ContentURI("/sdcard/mypath/
> > myimage.jpg")) when loading from SD card. Just my two cent guess.
>
> > Regards
>
> > On Nov 15, 7:57 am, EboMike <[EMAIL PROTECTED]> wrote:
> >> Hey blind, you're right, I'm using Drawables -- BitmapDrawables, to be
> >> precise. This is for an ImageSwitcher, so I need a Drawable of some
> >> sort (since I'm loading jpeg images off the storage device, so I can't
> >> use resources). I've tried BitmapFactory.decodeFile() instead of
> >> BitmapDrawables constructor that takes a String, but I get the same
> >> result, except that the OutOfMemoryException is now in
> >> BitmapFactory.decodeFile() itself instead of a cryptic callstack like
> >> before.
>
> >> I also call the gc right before creating the Bitmap... and the TTY is
> >> kind of interesting:
>
> >> 06:50:43.970: INFO/dalvikvm-heap(6039): Clamp target GC heap from
> >> 17.019MB to 16.000MB
> >> 06:50:43.990: DEBUG/dalvikvm(6039): GC freed 8139 objects / 927224
> >> bytes in 171ms
> >> 06:50:45.271: ERROR/dalvikvm-heap(6039): 38400-byte external
> >> allocation too large for this process.
> >> 06:50:45.271: ERROR/(6039): VM won't let us allocate 38400 bytes
> >> 06:50:45.280: DEBUG/skia(6039): allocPixelRef
> >> failed
>
> >> The gc freed 927KB, and then cannot allocate 38KB? Um, what?
>
> >> -Mike
>
> --
> Romain Guywww.curious-creature.org
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
Hi Romain, > I don't know what you're doing with the Camera but a picture coming > from the Camera uses several MB of memory so... In part for this reason I normally use the camera preview mode, which on the T-Mobile G1 takes only 3 * 480 * 320 / 2 ~= 230 KB per image, so no memory problem there, and even when expanding this into an integer pixel array for further image processing it would still be a manageable 480 * 320 * 4 ~= 614 KB. However, for my purposes I need only 64 x 64 pixel views, such that sub-sampling during YUV411 decoding and prior to further image processing keeps the extra memory use (on top of G1's hard-coded 230 KB preview data) far below this 614 KB (namely just 64 * 64 * 4 ~= 16 KB). The uncompressed still images from takePicture() are indeed several MB by default because of G1's 2048 * 1536 pixel snapshots, or about 6 MB when mapping to an RGB_565 bitmap. In fact it is one of the still unanswered questions which still image resolutions are supported by the G1. There is of course the heap-devouring 2048 * 1536, and experimentally it was determined that 480 * 320 also works (I tested that yesterday together with another developer who has a G1), but we have no comprehensive and authoritative list of supported resolutions to make proper trade-offs with memory use, while Android (SDK 1.0 r1) has no API for querying the camera about supported resolutions. The latter makes that Android-based camera applications cannot be made future-proof for when other Android phones with other cameras hit the market. I find this a serious concern as I have expressed on multiple occasions. Thank you for your further explanation about the internals of Drawable. I cannot be sure if my getting rid of using Drawable was indeed the reason that all my heap problems vanished, but your explanation further encourages me not to touch it with a stick unless I fully understand what I am doing - or what Android is doing. :-) Peter On Nov 15, 8:10 pm, Romain Guy <[EMAIL PROTECTED]> wrote: > I don't know what you're doing with the Camera but a picture coming > from the Camera uses several MB of memory so... > > One issue with Drawable is that they have a Callback pointer to a > View. That means if you keep your Drawable in a static field (directly > or indirectly), you forever keep a reference to a View. And that View > has a reference to the Context (your Activity), which has references > to all the widgets and resources on the current screen. That makes it > very easy to blow up the heap :) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
I don't know what you're doing with the Camera but a picture coming from the Camera uses several MB of memory so... One issue with Drawable is that they have a Callback pointer to a View. That means if you keep your Drawable in a static field (directly or indirectly), you forever keep a reference to a View. And that View has a reference to the Context (your Activity), which has references to all the widgets and resources on the current screen. That makes it very easy to blow up the heap :) On Sat, Nov 15, 2008 at 1:55 AM, blindfold <[EMAIL PROTECTED]> wrote: > > I forgot to mention that on the emulator I never had memory trouble > even with my older versions: my app would run for over 1,300 > iterations without ever crashing whereas the G1 would crash with some > OutOfMemoryError within 10 to 20 iterations. However, the camera part > is of course very different for emulator and G1, so I cannot exclude > the possibility that in my case the main problems originated there > since it is now known that G1 camera programming must be done with > white gloves. I did and do not have a G1 to look at possible memory > leaks on the physical device. > > On Nov 15, 10:30 am, blindfold <[EMAIL PROTECTED]> wrote: >> Thank you for your clarification, Romain! That is very helpful. I was >> initially using a fixed final Drawable array for my switching >> background images, and did not find any reason for memory leaks while >> I did not have to wait long for hitting the heap limit, but I am aware >> that it is easy to overlook such things. Even though my PNG background >> images together take only about 35 KB on disk, the decompressed >> versions will of course eat a lot more. Yet after moving over to using >> a final Bitmap array for the same image set I had far less memory >> related problems, and to further minimize memory usage I later changed >> to loading images one by one by doing a BitmapFactory.decodeResource >> (getResources(),) dynamically, only for the active background image. >> DDMS currently indicates zero leakage for my app, but I do not know >> how this was for my older breaking versions, because (at that time >> being unfamiliar with DDMS) I initially had trouble getting the heap >> info display to update. >> >> I hope Mike can do some allocation tracking like you indicate, and >> playing with some alternative implementations may help narrow down the >> possible causes of his problems, which may be entirely different from >> mine (and the one in the other thread). >> >> Thanks > > > > -- Romain Guy www.curious-creature.org --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
I forgot to mention that on the emulator I never had memory trouble even with my older versions: my app would run for over 1,300 iterations without ever crashing whereas the G1 would crash with some OutOfMemoryError within 10 to 20 iterations. However, the camera part is of course very different for emulator and G1, so I cannot exclude the possibility that in my case the main problems originated there since it is now known that G1 camera programming must be done with white gloves. I did and do not have a G1 to look at possible memory leaks on the physical device. On Nov 15, 10:30 am, blindfold <[EMAIL PROTECTED]> wrote: > Thank you for your clarification, Romain! That is very helpful. I was > initially using a fixed final Drawable array for my switching > background images, and did not find any reason for memory leaks while > I did not have to wait long for hitting the heap limit, but I am aware > that it is easy to overlook such things. Even though my PNG background > images together take only about 35 KB on disk, the decompressed > versions will of course eat a lot more. Yet after moving over to using > a final Bitmap array for the same image set I had far less memory > related problems, and to further minimize memory usage I later changed > to loading images one by one by doing a BitmapFactory.decodeResource > (getResources(),) dynamically, only for the active background image. > DDMS currently indicates zero leakage for my app, but I do not know > how this was for my older breaking versions, because (at that time > being unfamiliar with DDMS) I initially had trouble getting the heap > info display to update. > > I hope Mike can do some allocation tracking like you indicate, and > playing with some alternative implementations may help narrow down the > possible causes of his problems, which may be entirely different from > mine (and the one in the other thread). > > Thanks --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
Thank you for your clarification, Romain! That is very helpful. I was initially using a fixed final Drawable array for my switching background images, and did not find any reason for memory leaks while I did not have to wait long for hitting the heap limit, but I am aware that it is easy to overlook such things. Even though my PNG background images together take only about 35 KB on disk, the decompressed versions will of course eat a lot more. Yet after moving over to using a final Bitmap array for the same image set I had far less memory related problems, and to further minimize memory usage I later changed to loading images one by one by doing a BitmapFactory.decodeResource (getResources(),) dynamically, only for the active background image. DDMS currently indicates zero leakage for my app, but I do not know how this was for my older breaking versions, because (at that time being unfamiliar with DDMS) I initially had trouble getting the heap info display to update. I hope Mike can do some allocation tracking like you indicate, and playing with some alternative implementations may help narrow down the possible causes of his problems, which may be entirely different from mine (and the one in the other thread). Thanks On Nov 15, 10:01 am, Romain Guy <[EMAIL PROTECTED]> wrote: > Applications have a hard limit of 16 MB. As for the other bug you > mention, it has nothing to do with memory usage; the implementation of > BitmapFactory that reads images from URL will fail over slow > connections. Besides, when you load a Drawable from the resources, it > simply calls the BitmapFactory to decode the resource anyway. > > If you hit an out of memory exception, your app *is* using too much > memory (which you might very well be "leaking," it's not that hard, > especially if you use static fields in your code.) You can use DDMS > and its allocation tracker, as well as its various GC/heap monitors to > see when and how your application is allocating so much memory. > > I have run myself into this issue several times over the past 18 > months and every time, the application was leaking something > (especially on screen rotation.) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
Applications have a hard limit of 16 MB. As for the other bug you
mention, it has nothing to do with memory usage; the implementation of
BitmapFactory that reads images from URL will fail over slow
connections. Besides, when you load a Drawable from the resources, it
simply calls the BitmapFactory to decode the resource anyway.
If you hit an out of memory exception, your app *is* using too much
memory (which you might very well be "leaking," it's not that hard,
especially if you use static fields in your code.) You can use DDMS
and its allocation tracker, as well as its various GC/heap monitors to
see when and how your application is allocating so much memory.
I have run myself into this issue several times over the past 18
months and every time, the application was leaking something
(especially on screen rotation.)
On Sat, Nov 15, 2008 at 12:55 AM, blindfold <[EMAIL PROTECTED]> wrote:
>
> Well Mike, I don't know either, but just remember from my own app that
> I too had a zillion unexplained "Clamp target GC heap" messages at
> that 16 MB limit (while my app definitely needs far less memory than
> that), until I got rid of Drawables altogether. It could have been a
> coincidence, but together with the report from a Google Android Team
> member that
> http://groups.google.com/group/android-developers/browse_thread/thread/4ed17d7e48899b26/
> "this is a known bug" (without being more specific) and his Drawable-
> free workaround it suggested that this could be related to your
> problem. Of course there are plenty of other things that could be
> wrong...
>
>> This is for an ImageSwitcher, so I need a Drawable of some sort
>
> I have never used ImageSwitcher myself (Android seems to often offer
> at least three totally different ways to do the same thing, which is
> nice if two-out-of-three are still too buggy for deployment ). Yet
> to avoid Drawables there I could imagine trying
> ImageSwitcher.setImageURI(new ContentURI("/data/data/mypackage/files/
> myimage.jpg")) if the image is in internal flash, or
> ImageSwitcher.setImageURI(new ContentURI("/sdcard/mypath/
> myimage.jpg")) when loading from SD card. Just my two cent guess.
>
> Regards
>
> On Nov 15, 7:57 am, EboMike <[EMAIL PROTECTED]> wrote:
>> Hey blind, you're right, I'm using Drawables -- BitmapDrawables, to be
>> precise. This is for an ImageSwitcher, so I need a Drawable of some
>> sort (since I'm loading jpeg images off the storage device, so I can't
>> use resources). I've tried BitmapFactory.decodeFile() instead of
>> BitmapDrawables constructor that takes a String, but I get the same
>> result, except that the OutOfMemoryException is now in
>> BitmapFactory.decodeFile() itself instead of a cryptic callstack like
>> before.
>>
>> I also call the gc right before creating the Bitmap... and the TTY is
>> kind of interesting:
>>
>> 06:50:43.970: INFO/dalvikvm-heap(6039): Clamp target GC heap from
>> 17.019MB to 16.000MB
>> 06:50:43.990: DEBUG/dalvikvm(6039): GC freed 8139 objects / 927224
>> bytes in 171ms
>> 06:50:45.271: ERROR/dalvikvm-heap(6039): 38400-byte external
>> allocation too large for this process.
>> 06:50:45.271: ERROR/(6039): VM won't let us allocate 38400 bytes
>> 06:50:45.280: DEBUG/skia(6039): allocPixelRef
>> failed
>>
>> The gc freed 927KB, and then cannot allocate 38KB? Um, what?
>>
>> -Mike
>
> >
>
--
Romain Guy
www.curious-creature.org
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
Well Mike, I don't know either, but just remember from my own app that
I too had a zillion unexplained "Clamp target GC heap" messages at
that 16 MB limit (while my app definitely needs far less memory than
that), until I got rid of Drawables altogether. It could have been a
coincidence, but together with the report from a Google Android Team
member that
http://groups.google.com/group/android-developers/browse_thread/thread/4ed17d7e48899b26/
"this is a known bug" (without being more specific) and his Drawable-
free workaround it suggested that this could be related to your
problem. Of course there are plenty of other things that could be
wrong...
> This is for an ImageSwitcher, so I need a Drawable of some sort
I have never used ImageSwitcher myself (Android seems to often offer
at least three totally different ways to do the same thing, which is
nice if two-out-of-three are still too buggy for deployment ). Yet
to avoid Drawables there I could imagine trying
ImageSwitcher.setImageURI(new ContentURI("/data/data/mypackage/files/
myimage.jpg")) if the image is in internal flash, or
ImageSwitcher.setImageURI(new ContentURI("/sdcard/mypath/
myimage.jpg")) when loading from SD card. Just my two cent guess.
Regards
On Nov 15, 7:57 am, EboMike <[EMAIL PROTECTED]> wrote:
> Hey blind, you're right, I'm using Drawables -- BitmapDrawables, to be
> precise. This is for an ImageSwitcher, so I need a Drawable of some
> sort (since I'm loading jpeg images off the storage device, so I can't
> use resources). I've tried BitmapFactory.decodeFile() instead of
> BitmapDrawables constructor that takes a String, but I get the same
> result, except that the OutOfMemoryException is now in
> BitmapFactory.decodeFile() itself instead of a cryptic callstack like
> before.
>
> I also call the gc right before creating the Bitmap... and the TTY is
> kind of interesting:
>
> 06:50:43.970: INFO/dalvikvm-heap(6039): Clamp target GC heap from
> 17.019MB to 16.000MB
> 06:50:43.990: DEBUG/dalvikvm(6039): GC freed 8139 objects / 927224
> bytes in 171ms
> 06:50:45.271: ERROR/dalvikvm-heap(6039): 38400-byte external
> allocation too large for this process.
> 06:50:45.271: ERROR/(6039): VM won't let us allocate 38400 bytes
> 06:50:45.280: DEBUG/skia(6039): allocPixelRef
> failed
>
> The gc freed 927KB, and then cannot allocate 38KB? Um, what?
>
> -Mike
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
Hey blind, you're right, I'm using Drawables -- BitmapDrawables, to be precise. This is for an ImageSwitcher, so I need a Drawable of some sort (since I'm loading jpeg images off the storage device, so I can't use resources). I've tried BitmapFactory.decodeFile() instead of BitmapDrawables constructor that takes a String, but I get the same result, except that the OutOfMemoryException is now in BitmapFactory.decodeFile() itself instead of a cryptic callstack like before. I also call the gc right before creating the Bitmap... and the TTY is kind of interesting: 06:50:43.970: INFO/dalvikvm-heap(6039): Clamp target GC heap from 17.019MB to 16.000MB 06:50:43.990: DEBUG/dalvikvm(6039): GC freed 8139 objects / 927224 bytes in 171ms 06:50:45.271: ERROR/dalvikvm-heap(6039): 38400-byte external allocation too large for this process. 06:50:45.271: ERROR/(6039): VM won't let us allocate 38400 bytes 06:50:45.280: DEBUG/skia(6039): allocPixelRef failed The gc freed 927KB, and then cannot allocate 38KB? Um, what? -Mike On Nov 13, 2:11 am, blindfold <[EMAIL PROTECTED]> wrote: > Do you use Drawable's by any chance? See > alsohttp://groups.google.com/group/android-developers/browse_thread/threa... > I had plenty of memory allocation problems on the G1 until I started > using BitmapFactory.decodeResource(getResources() instead of > getResources().getDrawable(). Also, try to avoid static loading of > images that you can also load dynamically, one by one, when needed > while releasing the ones that you do not need at any given moment. > Finally, calling System.gc() when loading a new image does no harm and > might help the garbage collector to stay further away from the heap > limits. > > On Nov 13, 6:10 am, EboMike <[EMAIL PROTECTED]> wrote: > > > I'm getting this error too pretty often (mostly after changing > > orientation a few times). I just have a Gallery with up to three > > images visible at the same time, and one ImageSwitcher with images > > that are typically 1024x768 in size or less. I'm using the Heap view > > in Eclipse, and there's tons of memory available (not sure if > > fragmentation is an issue, the Heap view doesn't have any information > > on that). > > > That surely can't be touching the limits of the VM - how am I supposed > > to get this working? I could be more aggressive in disposing objects, > > but since I don't have any lingering references to anything, and the > > gc kicks in whenever memory is low (as LogCat clearly indicates), I > > don't see why this should be necessary. > > > My LogCat says: > > > 11-13 05:02:21.602: DEBUG/dalvikvm(31410): GC freed 1351 objects / > > 597328 bytes in 69ms > > 11-13 05:02:24.200: DEBUG/dalvikvm(47): GC freed 4402 objects / 275688 > > bytes in 116ms > > 11-13 05:02:27.691: DEBUG/dalvikvm(31410): GC freed 860 objects / > > 347368 bytes in 61ms > > 11-13 05:02:31.151: DEBUG/dalvikvm(31410): GC freed 591 objects / > > 196624 bytes in 76ms > > 11-13 05:02:32.781: ERROR/dalvikvm-heap(31410): 1134000-byte external > > allocation too large for this process. > > 11-13 05:02:32.781: ERROR/(31410): VM won't let us allocate 1134000 > > bytes > > 11-13 05:02:32.781: DEBUG/skia(31410): > > allocPixelRef failed --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
Do you use Drawable's by any chance? See also http://groups.google.com/group/android-developers/browse_thread/thread/4ed17d7e48899b26/ I had plenty of memory allocation problems on the G1 until I started using BitmapFactory.decodeResource(getResources() instead of getResources().getDrawable(). Also, try to avoid static loading of images that you can also load dynamically, one by one, when needed while releasing the ones that you do not need at any given moment. Finally, calling System.gc() when loading a new image does no harm and might help the garbage collector to stay further away from the heap limits. On Nov 13, 6:10 am, EboMike <[EMAIL PROTECTED]> wrote: > I'm getting this error too pretty often (mostly after changing > orientation a few times). I just have a Gallery with up to three > images visible at the same time, and one ImageSwitcher with images > that are typically 1024x768 in size or less. I'm using the Heap view > in Eclipse, and there's tons of memory available (not sure if > fragmentation is an issue, the Heap view doesn't have any information > on that). > > That surely can't be touching the limits of the VM - how am I supposed > to get this working? I could be more aggressive in disposing objects, > but since I don't have any lingering references to anything, and the > gc kicks in whenever memory is low (as LogCat clearly indicates), I > don't see why this should be necessary. > > My LogCat says: > > 11-13 05:02:21.602: DEBUG/dalvikvm(31410): GC freed 1351 objects / > 597328 bytes in 69ms > 11-13 05:02:24.200: DEBUG/dalvikvm(47): GC freed 4402 objects / 275688 > bytes in 116ms > 11-13 05:02:27.691: DEBUG/dalvikvm(31410): GC freed 860 objects / > 347368 bytes in 61ms > 11-13 05:02:31.151: DEBUG/dalvikvm(31410): GC freed 591 objects / > 196624 bytes in 76ms > 11-13 05:02:32.781: ERROR/dalvikvm-heap(31410): 1134000-byte external > allocation too large for this process. > 11-13 05:02:32.781: ERROR/(31410): VM won't let us allocate 1134000 > bytes > 11-13 05:02:32.781: DEBUG/skia(31410): > allocPixelRef failed --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
I'm getting this error too pretty often (mostly after changing orientation a few times). I just have a Gallery with up to three images visible at the same time, and one ImageSwitcher with images that are typically 1024x768 in size or less. I'm using the Heap view in Eclipse, and there's tons of memory available (not sure if fragmentation is an issue, the Heap view doesn't have any information on that). That surely can't be touching the limits of the VM - how am I supposed to get this working? I could be more aggressive in disposing objects, but since I don't have any lingering references to anything, and the gc kicks in whenever memory is low (as LogCat clearly indicates), I don't see why this should be necessary. My LogCat says: 11-13 05:02:21.602: DEBUG/dalvikvm(31410): GC freed 1351 objects / 597328 bytes in 69ms 11-13 05:02:24.200: DEBUG/dalvikvm(47): GC freed 4402 objects / 275688 bytes in 116ms 11-13 05:02:27.691: DEBUG/dalvikvm(31410): GC freed 860 objects / 347368 bytes in 61ms 11-13 05:02:31.151: DEBUG/dalvikvm(31410): GC freed 591 objects / 196624 bytes in 76ms 11-13 05:02:32.781: ERROR/dalvikvm-heap(31410): 1134000-byte external allocation too large for this process. 11-13 05:02:32.781: ERROR/(31410): VM won't let us allocate 1134000 bytes 11-13 05:02:32.781: DEBUG/skia(31410): allocPixelRef failed On Oct 27, 12:55 am, blindfold <[EMAIL PROTECTED]> wrote: > Easier said than done. An end-user of my app immediately got an > OutOfMemoryError on a real G1 (not the emulator) when capturing just s > single image from the camera at 2048 x 1536, the only specified > resolution that I could find on the web for the T-Mobile G1. Do you > know of any lower still image resolutions supported by the G1, > Romain? > > Thanks! > > On Oct 27, 4:15 am, "Romain Guy" <[EMAIL PROTECTED]> wrote: > > > Use less memory in your application :) > > > On Sun, Oct 26, 2008 at 7:54 PM, Tim <[EMAIL PROTECTED]> wrote: > > > > suffer to the same issue, out of memory :( --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
Easier said than done. An end-user of my app immediately got an OutOfMemoryError on a real G1 (not the emulator) when capturing just s single image from the camera at 2048 x 1536, the only specified resolution that I could find on the web for the T-Mobile G1. Do you know of any lower still image resolutions supported by the G1, Romain? Thanks! On Oct 27, 4:15 am, "Romain Guy" <[EMAIL PROTECTED]> wrote: > Use less memory in your application :) > > On Sun, Oct 26, 2008 at 7:54 PM, Tim <[EMAIL PROTECTED]> wrote: > > > suffer to the same issue, out of memory :( --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
On Sep 12, 1:39 pm, Zach Hobbs <[EMAIL PROTECTED]> wrote: > I'm able to randomly reproduce a situation that crashes my application. Does > this mean that my application is using too much memory? Correct. All it takes are memory requests for a few large bitmaps and you're out. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
Use less memory in your application :) On Sun, Oct 26, 2008 at 7:54 PM, Tim <[EMAIL PROTECTED]> wrote: > > suffer to the same issue, out of memory :( > > …… > 10-27 10:44:17.998: ERROR/dalvikvm-heap(1621): 10240-byte external > allocation too large for this process. > 10-27 10:44:18.007: ERROR/(1621): VM won't let us allocate 10240 bytes > …… > > anyone knows how to increase the working memory of dalvikvm? > > > -- Romain Guy www.curious-creature.org --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Allocation too large for this process
suffer to the same issue, out of memory :( …… 10-27 10:44:17.998: ERROR/dalvikvm-heap(1621): 10240-byte external allocation too large for this process. 10-27 10:44:18.007: ERROR/(1621): VM won't let us allocate 10240 bytes …… anyone knows how to increase the working memory of dalvikvm? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
