WebViewCoreThread problem using Google Play Services AdMob

[Simone Bernardini]

Hi everyone,
I'm currently developing an app for Android and, after implementing AdMob's AdViews and interstitial ads through Google Play Services I've started experiencing some issues.
My app features some activities and a service, which keeps running in background even after the app's main activity has been destroyed. I noticed that, after implementing ads, my background service retains an excessive amount of RAM memory while it's executing: the ads featuring version of the app retains something like 18 MBs of rmemory while the "plain" version only needs 7-8 MBs (according to a real device's running services system monitor). Moreover, analyzing the app's execution using debug and DDMS perspectives in Eclipse, I could also notice that, even after the main activity is destroyed, the WebViewCoreThread and CookieSyncManager keep running in background. I've followed the AdMob help center's guide step by step for implementing ads in my app and I'm calling adView.pause(), adView.resume() and adView.destroy() in my onPause(), onResume() and onDestroy() methods, also setting adView = null after calling destroy(). The implementation has been mainly made programmatically; i just declare an empty RelativeLayout in my activity's xml layout file and then dynamically create, load and add adviews to that layout.
Has anyone already experienced this using the Google Play Services version of the SDK? the adView.destroy() method seems not really destroying the views and having the threads continuously running seems to be draining the battery out. Any idea would be greatly appreciated ;)

Simone

[Eric Leichtenschlag]

Hi Simone,

Could you provide more information such as a sample app that shows this behaviour and what device(s) it occurs on? And does it happen in an app that doesn't use a service?

Thanks,
Eric

[Simone Bernardini]

Hi Eric, I've coded a very simple app that uses a service and a broadcastreceiver. I've attached the app's source files to this message, together with screenshots of my device's running apps before and after implementing ads, a screenshot of my ddms perspective some minutes after the app's onDestroy has been called, a screenshot of what the debugger shows me while the service is running and after the activity's been destroyed, and LogCat traces . The devices I used for testing are a Samsung Galaxy Note (GT-N7000), and a Sony Xperia S both running Android 4.1.2 . Hope it helps.

Simone

[Simone Bernardini]

I forgot to tell you, if the app doesn't use a service it seems to happen anyway. The difference is, without a service, after calling onDestroy() the OS immediately (almost) releases all previously allocated memory, so I think the background threads get stopped in this cases. But quickly switching to my device's running apps screen I could still see the same increase in memory allocation after adding adviews and interstitials to the app. I also forgot to attach to the previous post the screenshot showing the difference in memory usage before and after adding ads, I'm doing it here.

Simone

Il giorno sabato 7 dicembre 2013 04:06:59 UTC+1, Eric Leichtenschlag ha scritto:

[William Ferguson]

Umm, it's against Admob's terms of service to display more than one banner ad on a page at a time.

I have no idea if this is causing your pain, but it would be the first thing I would excise.

Followed by accessing the UI from your service.

And if it's still occurring after that then I'd try to narrow down whether it's the banner , interstitial, your service or broadcast receiver that is causing the issue.

William

[Simone Bernardini]

Thanks, William, for your reply and for pointing that out. I did totally overlook the fact that it's not allowed to show more than one banner per page. I will follow your advices and do some more testing.

Simone

[Simone Bernardini]

I've done some more testing, I'm still having the same issue in any case; I tried using just one interstitial and a banner, just the interstitial and just the banner: it's still there. Moreover, I tried dropping the BroadcastReceiver, but it didn't solve the problem, It seems it's enough to have a service using starForegorund() in onStartCommand() to make this noticeable. I've also noticed, using DDMS in Eclipse, that while the background service is running, WebViewCoreThread's utime and stime keep growing, no matter whether the activity's onDestroy() has been called or not. Moreover, they keep growing even after locking the device's screen, probably forcing it not to go to sleep.

Il giorno sabato 7 dicembre 2013 16:24:39 UTC+1, William Ferguson ha scritto:

[Simone Bernardini]

Does anyone have any idea about how to fix this?

[Simone Bernardini]

Testing my app with real ads, I've now discovered that AdViews keep requesting ads even after activity's onDestroy...I really can't understand what's wrong with it! Using the debugger shows that AdView keeps alive after calling adView.destroy(), just like the destroy() method does nothing

[Amy Quispe (AdMob SDK Team)]

Hi Simone,

Are you still having trouble? Does working with only one AdView work?

Amy Quispe

[Simone]

Hi Amy thanks for your reply,
It doesn't work even if I use one adview only, webviewcorethread keeps runnin and loading ads despite calling the pause and destroy methods. I think I found a partial workaround by using my own methods to pause webviewcorethread but I still can't find a way to release allocated memory on destroy...

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "Google AdMob Ads Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-admob-ads-sdk/D6X5yL8Acn4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-admob-ads...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Amy Quispe (AdMob SDK Team)]

Have you tried customizing your AdView lifecycle methods?

Amy Quispe

To unsubscribe from this group and all its topics, send an email to google-admob-ads-sdk+unsub...@googlegroups.com.

[Simone]

Well, at first I tried to pause, resume and destroy adviews just calling the pause(), resume() and destroy() methods on them in my activity's onResume() onPause() and onDestroy() methods, as written in the admob guide, them, since those methods seemed not to work properly, I've implemented custom additional methods:

pauseWebView(Viewgroup v) {

  for (int i = 0; i < v.getChildCount(); i++) {

    View child = v.getChildAt(i);

    if (child instanceof Webview) {

      ((WebView)child).pauseTimers();

    }

    else if (child instanceof ViewGroup) {

      pauseWebView((ViewGroup) child);

    }

  }

}

 

resumeWebView(Viewgroup v) {

  for (int i = 0; i < v.getChildCount(); i++) {

    View child = v.getChildAt(i);

    if (child instanceof WebView) {

      ((WebView)child).resumeTimers();

    }

    else if (child instanceof ViewGroup) {

      resumeWebView((ViewGroup)child);

    }

  }

}

 

and then using these like:

 

public void onResume() {

  if (adView != null) {

    resumeWebview(adView);

    adView.resume();

  }

}

 

public void onPause() {

  if (adView != null) {

    adView.pause();

    pauseWebView(adView);

  }

}

 

I've also tried to use a custom method to release allocated memory, getting an instance of the WebView contained in the AdView and trying to manually remove cache and destroy it but that didn't seem to work, plus, calling the destroyWebView method made impossible to also call the AdMob's destroy() method on the adviews, so I decided to keep using the original destroy() method.

 

 

 

 

2013/12/26 Amy Quispe (AdMob SDK Team) <admobsdk-advi...@google.com>

To unsubscribe from this group and all its topics, send an email to google-admob-ads...@googlegroups.com.