does the 16 MB heap limitation also applies to OpenGL ES textures or SoundPool sound effects?
Since they are managed by native code, is it correct to affirm that there is no problem in using more than 16 MB of RAM in app/game resources/assets?
If it is possible right now, it is guarantee to be possible in the future?

Thank you in advance for your reply,
Renato.

Maybe I am wrong, but I am a little confused about the memory leak in the sample of this article, because, the setBackgroundDrawable reset the drawable’s callback after the activity reloaded.

label.setBackgroundDrawable(sBackground);

And you can check the source of setBackgroundDrawable(…),

public void setBackgroundDrawable(Drawable d) {
…
if (d != null) {
…
d.setCallback(this);
…
}
…
}

This is SDK 1.6′s code, maybe it’s updated after this post.

-M.G.

As you may know, long living references of Context aren’t the only source of memory leak problems. I suggest you take a look at this video: http://www.youtube.com/watch?v=Dgnx0E7m1GQ

It won’t give you answer right away, but it will show you how to find your problem with the SDK tools (which are great, I must say). Learn to use TraceView, HierarchyViewer and AllocationTracker; debugging will become much more fun and programming – much easier.

P.S. One question about the aforementioned getApplicationContext() and getApplication() methods – after reading the blog entry, I had the impression that they were static in Android 1.0/1.1, but now, in Cupcake, they are regular instance methods, am I right?

Regards,
Dimitar

This Ramesh, I have one problem in my application “Low memory No more process” I have one activity. this activity change the views corresponding action. after some my application hanged and exit automatically. last one week i struggle with this problem. I don’t know what is the problem. I don’t kept static Context variable. Please help me any body knows the solution.

Advance thanks
Ramesh

I have an applications with “beans” that are created once, and used in all activities of the application. I already have a kind of “container” that keeps the bean references, but when those beans have dependencies on a “Context” (injected in their constructor), it was kind of tricky to have them use the right Context.

I ended up creating a CurrentContextProxy that extends Context and delegates all its calls to a real Context that is an instance variable of CurrentContextProxy. This CurrentContextProxy is injected in the beans.

Whenever an Activity comes to the front (onResume()), it updates the CurrentContextProxy with itself.

Althought this was better than recreating all beans for each activity, I will now use an Application context, much better :-).

Thanks !