My favorites | Sign in
Project Home Issues
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 5067: WebView causes memory leak - leaks the parent Activity
33 people starred this issue and may be notified of changes. Back to list
Status:  Released
Closed:  Dec 2009

Sign in to add a comment
Reported by, Nov 26, 2009
Starting an activity with a WebView, then destroying that activity (hitting 
back) and getting a heap dump shows that there are uncleaned up references 
that cause the activity to stay in memory (leak).

This is similar in nature to the accepted bug that I reported for the MapView 
28.3 KB   View   Download
3.6 MB   Download
Nov 26, 2009
For example, one of these leaks occurs because there is a static variable mInstance 
in PluginManager and that keeps a reference to the Context, which is the activity.

Unfortunately, since the context that is passed is the parent Activity (not an 
application context), this causes a problem. The comment says it should be an 
ApplicationContext, but if we follow this all the way up (through the Frame and 
WebViewCore), then we see WebView the regular context, not the application context...

So perhaps the fix is:
mWebViewCore = new WebViewCore(context, this, mCallbackProxy, javascriptInterfaces);
mWebViewCore = new WebViewCore(context.getApplicationContext(), this, mCallbackProxy, 

Nov 26, 2009
Or clean up this stuff in WebViewCore.destroy()
Nov 26, 2009
These memory leaks only seem to be there for Android 2.0 and are not there in 1.6.
Nov 30, 2009
(No comment was entered for this change.)
Status: Reviewed
Dec 1, 2009
(No comment was entered for this change.)
Status: FutureRelease
Feb 22, 2011
I've found the workaround in Comment #1:

mWebViewCore = new WebViewCore(context.getApplicationContext(), this, mCallbackProxy, 

is not usable when the Webview is displaying Flash content.  When WebView is created with the Application context, the Flash plugin crashes on a ClassCastException while trying to cast the Application context to an Activity context.

W/dalvikvm(13293): threadid=1: thread exiting with uncaught exception (group=0x4001d7d0)
E/AndroidRuntime(13293): FATAL EXCEPTION: main
E/AndroidRuntime(13293): java.lang.ClassCastException: com.zoodles.kidmode.ZoodlesApplication
E/AndroidRuntime(13293): 	at com.adobe.flashplayer.FlashPaintSurface.getBrowserActivity(
E/AndroidRuntime(13293): 	at com.adobe.flashplayer.FlashPaintSurface$2.surfaceCreated(
E/AndroidRuntime(13293): 	at android.view.SurfaceView.updateWindow(
E/AndroidRuntime(13293): 	at android.view.SurfaceView.dispatchDraw(
E/AndroidRuntime(13293): 	at android.view.View.draw(
E/AndroidRuntime(13293): 	at android.view.SurfaceView.draw(
E/AndroidRuntime(13293): 	at android.view.ViewGroup.drawChild(
E/AndroidRuntime(13293): 	at android.webkit.WebView.drawChild(

We're looking for suggestions for another way to work around this memory leak.

Apr 23, 2011
You could keep a single static instance of the WebView, attaching and detaching it as needed.
Dec 8, 2011
Seems like a quick fix. Why hasn't this been fixed yet? I'm having the same problem.
Aug 16, 2012
Has anyone found a workaround for this when the Webview displays Flash content? This is a bit of a double edged sword. If you don't pass the Application context, you get a memory leak. If you do pass the Application context, your app crashes when Flash content is on the page. 
Aug 17, 2012
I'm having the same issue with AdMob AdView objects.  Prior to integrating with AdMob, I used the application context workaround, but AdViews don't work if they are inflated via an Application context -- they want an Activity context.  Anybody figured out another workaround?
Jun 23, 2013
(No comment was entered for this change.)
Status: Released
Sign in to add a comment

Powered by Google Project Hosting