Note that just because heap limits aren't imposed on the native heap like they are on the Java heap doesn't mean that there aren't limits. The failure cases are just more difficult -- not allowing stuff to work in the background when it should to your application just silently being killed.
You *can* push the limit somewhat from the native heap, but there aren't many good ways to tell how much on any particular device. A general safe rule of thumb is to keep your native allocations below the java heap limit as well independent of what is allocated in Java. Also keep in mind that as of 3.0 there is an API to extend the Java heap to a larger safe limit for specific large apps that need it, and find out what that limit is: http://developer.android.com/reference/android/app/ActivityManager.html#getLargeMemoryClass() On Wed, Jun 8, 2011 at 10:17 AM, Erik R <ejwrobert...@gmail.com> wrote: > I'm working on a simple image manipulation app that requires opening > bitmaps at full resolution, which of course results in OutOfMemory > issues. I know that the short answer is to simply use less memory via > BitmapFactory's inSampleSize Option to downsample the bitmap, but for > this app I really would like to retain the full resolution for > editing. One solution I have been investigating is loading the bitmap > entirely on the native heap, after learning that the memory limitation > is only imposed within the Dalvik VM heap. A look into the Android > source code revealed that this is already the case... BitmapFactory > uses native methods to load a bitmap on the native heap, while > maintaining a reference to it on the VM heap. The issue then is that > it appears the native memory used by the bitmap is actually counted > against the available VM memory, when it really isn't there. A look > into the stock Camera and Gallery apps' source revealed that they get > around this by using an additional BitmapFactory Option, > inNativeAlloc. I was able to find this field in the Java code for > BitmapFactory: > > 196 * Normally bitmap allocations count against the dalvik > heap, which > 197 * means they help trigger GCs when a lot have been > allocated. However, > 198 * in rare cases, the caller may want to allocate the > bitmap outside of > 199 * that heap. To request that, set inNativeAlloc to true. > In these > 200 * rare instances, it is solely up to the caller to > ensure that OOM is > 201 * managed explicitly by calling bitmap.recycle() as soon > as such a > 202 * bitmap is no longer needed. > 203 * > 204 * @hide pending API council approval > 205 */ > 206 public boolean inNativeAlloc; > > Are there any plans to "unhide" this field anytime soon? > > -- > 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 > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. 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
