How does the native heap actually tell you, will malloc return NULL if it cannot reserve enough space?
And if you are a foreground app, you won't get in trouble will you (unless you use insane amounts of it) I can understand that a background app should not use more native memory than the limit. On Jun 8, 9:35 pm, Dianne Hackborn <[email protected]> wrote: > 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.ht...() > > > > > > On Wed, Jun 8, 2011 at 10:17 AM, Erik R <[email protected]> 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 [email protected] > > 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 > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > 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 [email protected] 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
