More info - when I use meminfo the "native allocated" kb increases from 10MB to 15MB to 20MB after each screen orientation change, even though I am explicitly calling recycle() on the large bitmaps in our onDestroy (and I ran it in the debugger and verified that this code is being called). Also, when I reduce the size of the bitmap to the screen size (instead of twice the width and height of the screen) the "native allocated" only increases about 2MB each time, so it takes more screen orientation changes before the thing keels over (but it eventually does). So it looks like the bitmap is getting leaked somehow.
We have no static members, and one thread is created (which exits after our onDestroy is called, which I have verified) and I've checked all our inner classes to make sure there is nothing getting leaked. So I'm pretty sure it's not our code leaking it (but I could be wrong). And even if it was a leak in our code, the explicit recycle() should have sorted it out. On Sep 7, 1:08 pm, Romain Guy <[email protected]> wrote: > It could also be a memory leak in your application. -- 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
