AdMob V2 problems

I’m getting very inconsistent results with AdMob V2, looking for any suggestions.  I started noticing that “about half” the random Android devices that I tried an app on didn’t appear to be getting ads,  Testing reveals lots of “curious” stuff in the logcat, but I I can’t decipher most of it.

What I’m doing:

I’ve got my own “tester” framework, just for checking out AdMob V2.  I have both a portrait and landscape build of same source.  Release 2014.2381

I’ve got two devices (primarily) that I’m testing on:

  Nexus 7 2012 (Android 4.4.4, GPlaySvcs 5.0.89)

  Trio Stealth G2 (Android 4.0.4, GPlaySvcs 5.0.89)

Both versions on both devices spit out LOTS of “Google Play services resources not found…” and “unable to resolve static field #### (common_google_play_services_unknown_issue)…” jibberish in the logcat.

Also, on both devices/both orientations, lots of:  “D/dalvikvm(12789): VFY: replacing opcode 0x60 at 0x0061” -type messages in logcat (opcode # and location vary)

On the N7:

Both portrait/landscape versions return both banners/interstitials on the N7

On the G2…

In portrait mode, I get neither banners nor interstitials, nor do I even get the callback to my listener.  I do get this occassionally in logcat:

E/GooglePlayServicesUtil(22297): The Google Play services resources were not fou nd. Check your project configuration to ensure that the resources are included. W/Ads     (22297): Interrupted during GADSignals creation. W/Ads     (22297): java.lang.InterruptedException W/Ads     (22297):      at java.util.concurrent.locks.AbstractQueuedSynchronizer

In landscape mode, for banners I get a listener response of “The ad request was invalid, for instance, the ad unit ID was incorrect.”  (it’s the *exact same* .apk as on the N7, so both ad units are known to be correct)

In landscape mode, for interstitials, I do get an ad, but I also get screens full of logcat messages from the WindowManager with various properties listed, usually starting with something like “W/WindowManager( 3275): Rebuild removed 4 windows but added 2” or "W/WindowManager( 3275): This window was lost: Window{4177c7c8 org.davebollinger.

AdsTesterAdMob/com.ansca.corona.CoronaActivity paused=true}"

Any ideas? Thanks.

fwiw: it’s very inconsistent, many devices observed, tho only three devices actually logged so far.  Bug 34895 submitted with full (yet simple) source, prebuilt apk’s, full logcat’s…  hopefully someone in engineering can figure it out.

Google (ASUS) Nexus 7 2012, Android 4.4.4, Google Play services 5.0.89

Portrait:  banner:pass, interstitial:pass

Landscape:  banner:pass, interstitial:pass

Ematic Genesis Prime 7", Android 4.1.1, Google Play services 5.0.89

Portrait:  banner:pass, interstitial:pass

Landscape:  banner:FAIL, interstitial:pass

Mach Speed Trio Stealth G2, Android 4.0.4, Google Play services 5.0.89

Portrait:  banner:FAIL, interstitial:FAIL (and no listener callbacks for either)

Landscape:  banner:FAIL, interstitial:pass

FYI and FWIW:  well I got a quick reply, but the tech totally missed the point, and instead dismissed it as if it was a fill-rate issue, and how they’re not in control or responsible if Google isn’t serving up ads – never mind that these errors are completely different than a “normal” fill-rate failure.

I got the strong impression (from how quickly the response came back) that it was just dismissed out-of-hand, without any further investigation or testing.

Argh, no point telling him that I’ve successfully dealt with fill-rate ad mediation in the past, or that I understand the difference between a (properly reported) no-fill scenario and an “internal” system-level exception that killed the whole ad listener callback entirely.  (besides I rarely see ANY fill-rate issues at all with admob … on the devices where it works)  And apparently no point telling him that this is repeatable, reproduceable, consistent, having nothing to do with Google’s ad inventory, and that these same failures occur even with test mode on (thereby ruling out inventory issues).

Frustrating.  Feel like I wasted an entire morning bundling all that stuff up nice and neat for submission – am a bit less than impressed with the “resolution”.  Ok,… done ranting.  ;D

fwiw: it’s very inconsistent, many devices observed, tho only three devices actually logged so far.  Bug 34895 submitted with full (yet simple) source, prebuilt apk’s, full logcat’s…  hopefully someone in engineering can figure it out.

Google (ASUS) Nexus 7 2012, Android 4.4.4, Google Play services 5.0.89

Portrait:  banner:pass, interstitial:pass

Landscape:  banner:pass, interstitial:pass

Ematic Genesis Prime 7", Android 4.1.1, Google Play services 5.0.89

Portrait:  banner:pass, interstitial:pass

Landscape:  banner:FAIL, interstitial:pass

Mach Speed Trio Stealth G2, Android 4.0.4, Google Play services 5.0.89

Portrait:  banner:FAIL, interstitial:FAIL (and no listener callbacks for either)

Landscape:  banner:FAIL, interstitial:pass

FYI and FWIW:  well I got a quick reply, but the tech totally missed the point, and instead dismissed it as if it was a fill-rate issue, and how they’re not in control or responsible if Google isn’t serving up ads – never mind that these errors are completely different than a “normal” fill-rate failure.

I got the strong impression (from how quickly the response came back) that it was just dismissed out-of-hand, without any further investigation or testing.

Argh, no point telling him that I’ve successfully dealt with fill-rate ad mediation in the past, or that I understand the difference between a (properly reported) no-fill scenario and an “internal” system-level exception that killed the whole ad listener callback entirely.  (besides I rarely see ANY fill-rate issues at all with admob … on the devices where it works)  And apparently no point telling him that this is repeatable, reproduceable, consistent, having nothing to do with Google’s ad inventory, and that these same failures occur even with test mode on (thereby ruling out inventory issues).

Frustrating.  Feel like I wasted an entire morning bundling all that stuff up nice and neat for submission – am a bit less than impressed with the “resolution”.  Ok,… done ranting.  ;D