Android WebViewCoreThread cpu usage with paused activity

[L0NESTAR]

Hey guys,

I've seen this issue being discussed in a few places but i've not discovered a satisfactory conclusion as yet.

Its so easy to repro that i am assuming im missing something.. 

If i load the ad sample (gms.samples.ads), click 'banner in code', drop in to DDMS and take a profiling snapshot i see this:

Which is fair enough ;)

all i have to do though, is tap the home button back to the launcher and then look at the app again in DDMS and i see this:

This is the sample app, the only thing ive done is set a test device and filled in a valid ad id. Surely this isnt correct? the app should be taking no CPU use in this state? The only solution ive come across is this code from Simone Bernardini :

https://groups.google.com/d/msg/google-admob-ads-sdk/D6X5yL8Acn4/9CO5k0WFx1EJ

If this is the case then this code should be included in the samples.

 

[Eric Leichtenschlag]

We're investigating this. To me it appears adView.pause() isn't quite doing what's advertised, and the WebView may still running in the background.

webView.pauseTimers() and webView.resumeTimers() is a pretty good workaround for now. But note that it affects all WebView's in the app, so if you have some WebView of your own that you want to run in the background, this won't work for you. Since this code affects all WebViews in your app, the code provided by Simone can be simplified to new WebView(this).pauseTimers() in onPause, and new WebView(this).resumeTimers() in onResume.

Thanks,
Eric 

[L0NESTAR]

That's great news, thanks for clarifying :)

[Dan Dragut]

No offense Eric, but from what I can see as well this not a new issue and I hope the workaround won't be used as an excuse to postpone or not fix it properly in the library... As I'm sure you're well aware of this, a lot of users already see ads not only as a bit of annoyance, but more importantly as a battery drain, which is not good for either party involved...

Instead of calling WebView.pauseTimers() / resumeTimers() which as Eric says it will interfere with all WebViews (I found it prevented my own content WebView from rendering entirely in another activity), maybe calling WebView.onPause() / onResume() is a better alternative. It is available as a public method in API 11+, but apparently might be available as a private in earlier versions to be called through reflection.

• StackOverflow - WebView threads never stop (WebViewCoreThread, ...)
• Issue 10282: Public API for WebView.onPause and WebView.onResume
• WebView.onPause()
  

  Pauses any extra processing associated with this WebView and its associated DOM, plugins, JavaScript etc. For example, if this WebView is taken offscreen, this could be called to reduce unnecessary CPU or network traffic. When this WebView is again "active", call onResume(). Note that this differs from pauseTimers(), which affects all WebViews.
  

private void pause(AdView p_adView) {
  // API...
  p_adView.pause();

  // Workaround...
  try {
    WebView webView = getWebView(p_adView);
    Class.forName("android.webkit.WebView").getMethod("onPause", (Class[]) null).invoke(webView, (Object[]) null);
  }
  catch (Exception e) {
    if (BuildConfig.DEBUG) {
      Log.w(TAG, Log.getStackTraceString(e));
    }
  }
}

[Eric Leichtenschlag]

HI Dan,

We think the issue is related to CSS animations and not JavaScript. WebView.pauseTimers()* seems to do more than webView.pause(). adView.pause() does call webView.pause() internally, but that doesn't seem to be enough.

I'm not aware of a method that turns off CSS animations, so we're exploring a solution at the creative level to be able to pause/resume animation on the creative.

Thanks,

Eric

*We've also discovered that WebView.pauseTimers() doesn't seem to work on Android 4.4.

[Dan Dragut]

Hi Eric,

Glad to hear you guys are making some progress with the issue.

Maybe it has to do with the contents of the ad and how the authors chose to do the animations and such, although from the ones I've observed they seem like plain banner ads with usual flip animations and the behavior was quite consistent.

Thanks,
Dan

* On Android 4.4 the trace looks a bit different, instead of a WebViewCoreThread there are a couple of unnamed threads (Thread-xxx) ticking away. I thought I wouldn't bring that in there to not confuse things, I can open a separate thread for that if you want.
Nexus 7, Android 4.4.2 (KOT49H), Google Play Services 4.3.24 (1084291-030), Google Play Services Library r16