AdMob V2 banners are unreliable across device resolutions

[davebollinger]

I tried reporting this as a bug, but they just blew me off without even testing, so… I’ll just offer this as a FYI:

If you’re doing dynamic content sizing (like “ultimate config” tutorials), particularly on Android (since there are so many more resolutions out there), and particularly if in landscape orientation (don’t know why, but is true)… then you may not be getting banner ads on all devices.

If you pay close attention to the logcat on a “bad” device you’ll see something like:

W/Ads     ( 5791): Invalid admob request error: [Ad size will not fit on screen] W/Ads     ( 5740): There was a problem getting an ad response. ErrorCode: 1 W/Ads     ( 5740): Failed to load ad: 1

My guess is there’s something wrong with the “math” for sizing the ad-request vs the ad-view, with all these fractional scaled coordinate floating around, (maybe something being rounded that should be truncated, or vice versa, etc) but don’t really know what’s actually failing internally.  All I know is that code that works consistently fine on devices of one resolution will consistently fail on devices of another resolution.  (the device make/model don’t seem to matter, just their native resolution, thus the resulting content scale)

If you dump the corresponding event.response, you get this somewhat less-helpful message:

The ad request was invalid; for instance, the ad unit ID was incorrect.

(of course, i’m testing with known valid ad unit ID’s that have been active and serving for a long time, where same code/same apk works fine on some device resolutions, so “ad unit ID was incorrect” is a red herring)

I haven’t found a workaround.  Tried various scaling “letterBox”, “zoomEven”, “zoomStretch”, and altering my content width/height, all for nothing, because at best the most I could achieve is altering WHICH resolutions would have the problem.

(that is, for example, If I altered my content size to 500x750 and used zoomStretch instead of letterBox I might fix it when running at 480x800, but then 600x1024 which had been working before, would now be one of the trouble ones instead.  not that I’m in a position to actually DO that for production, but just as an experiment while trying to figure this out)

All this with just the simplest possible config.lua, just "width=480, height=640, scale=“letterBox”, and landscape orientation in build.settings. (and the admob plugin itself, of course, and its required permissions)

Just a heads up that you might want to test on multiple devices if you wanna actually get paid.

[rob]

Do you have the bug ID number?

[davebollinger]

34895

[ingemar]

Personally I think that the whole ads.* API should be scrapped in favor of discreet plugins. The ads.* API was developed before plugins were available as a means to provide access to different ad networks, and it feels outdated.

After the introduction of plugins I think it’s unnecessary to have the ads.* API around anymore. It feels counterproductive to constantly have to call ads:setCurrentProvider() in the hope that ads.show()/hide() is performed on the correct provider, and sometimes I think that even doing that doesn’t guarantee it does.

Somehow I feel having discreet plugins for all ad-networks would be a better approach as it isolates each provider into its own “sandbox”.

[rob]

Do you have the bug ID number?

[davebollinger]

34895

[ingemar]

Personally I think that the whole ads.* API should be scrapped in favor of discreet plugins. The ads.* API was developed before plugins were available as a means to provide access to different ad networks, and it feels outdated.

After the introduction of plugins I think it’s unnecessary to have the ads.* API around anymore. It feels counterproductive to constantly have to call ads:setCurrentProvider() in the hope that ads.show()/hide() is performed on the correct provider, and sometimes I think that even doing that doesn’t guarantee it does.

Somehow I feel having discreet plugins for all ad-networks would be a better approach as it isolates each provider into its own “sandbox”.

[Hendri_Thijs]

Have the same exact error. Am testing on an android device with an app in landscape mode. The device is 1280x736 pixels (780 minus pixels for the soft buttons) it tries to retrieve a 962 x 50 ad, then it states that my screen height is 736 then it concludes that the add won’t fit the screen.
“format”:“962x50_as”,“sh”:736,“smart_h”:“auto”,“ad_pos”:{“height”:0,“visible”:0,“y”:0,“width”:0,“x”:0}
 
So it seems that it wants to use the screen height to show the banner (as in it wants to show it in portrait mode instead of landscape) is there a way to force this to landscape instead?
 
Or is corona providing google with the wrong screen height number?
 
Am using build 2511 btw.
And I have the following in config.lua:

[lua]

local aspectRatio = display.pixelHeight / display.pixelWidth
application = {
    content = {
        width = aspectRatio > 1.33 and 768 or math.ceil( 1024 / aspectRatio ),
        height = aspectRatio < 1.33 and 1024 or math.ceil( 768 * aspectRatio ),
        scale = “zoomEven”,
        fps = 60,
    },
}

[/lua]

And the following in buildsettings.lua

[lua]

settings = {

    orientation = {

        default = “landscapeRight”,

        supported = { “landscapeLeft”, “landscapeRight” }

    },

[/lua]

Tested without landscape mode in build settings and then it shows the banner in portrait mode, however my game is in landscape so this is not a solution…

so this is the working request (portrait mode):

[lua]

CORE loadUrl javascript:AFMA_buildAdURL({“session_id”:“9884268380588540517”,“seq_num”:“1”,“slotname”:“ca-app-pub-niceid”,“rm”:2,“adtest”:“on”,“js”:“afma-sdk-a-v6599000.4242000.1”,“quality_signals”:{“ads”:[],“app”:{“preqs”:0,“support_transparent_background”:false,“pimp”:0,“session_id”:“9884268380588540517”,“seq_num”:“1”,“currts”:604887717,“pclick”:0,“basets”:604887717},“slots”:{}},“eid”:“46621067”,“hl”:“en”,“gnt”:0,“ma”:1,“battery”:{“is_charging”:true,“battery_level”:0.7400000095367432},“vc”:6,“sw”:800,“forceHttps”:true,“u_sd”:1.3312501,“sp”:0,“cnt”:1,“muv”:12,“riv”:4,“ms”:“nice hash”,“mv”:“80310011.com.android.vending”,“connectivity”:{“active_network_state”:5,“active_network_metered”:false},“format”:“600x90_as”,“sh”:1216,“smart_h”:“auto”,“ad_pos”:{“height”:0,“visible”:0,“y”:0,“width”:0,“x”:0},“coh”:1,“gl”:“US”,“am”:0,“cog”:1,“pt”:0,“pn”:“com.gemiware.appname”});

[/lua]

and this is the failing one (landscape mode):

[lua]

CORE loadUrl javascript:AFMA_buildAdURL({“session_id”:“12127961398928385070”,“seq_num”:“1”,“slotname”:“ca-app-pub-niceid”,“rm”:2,“adtest”:“on”,“js”:“afma-sdk-a-v6599000.4242000.1”,“quality_signals”:{“ads”:[],“app”:{“preqs”:0,“support_transparent_background”:false,“pimp”:0,“session_id”:“12127961398928385070”,“seq_num”:“1”,“currts”:606433396,“pclick”:0,“basets”:606433396},“slots”:{}},“eid”:“46621067”,“hl”:“en”,“gnt”:0,“ma”:1,“battery”:{“is_charging”:true,“battery_level”:0.7799999713897705},“vc”:7,“sw”:1280,“u_sd”:1.3312501,“sp”:0,“cnt”:1,“muv”:12,“riv”:4,“ms”:“nice hash”,“mv”:“80310011.com.android.vending”,“connectivity”:{“active_network_state”:5,“active_network_metered”:false},“format”:“962x50_as”,“sh”:736,“smart_h”:“auto”,“ad_pos”:{“height”:0,“visible”:0,“y”:0,“width”:0,“x”:0},“coh”:1,“gl”:“US”,“am”:0,“cog”:1,“pt”:0,“pn”:“com.gemiware.appname”});

[/lua]

[Hendri_Thijs]

OK, found the solution for my issue at least. Changed the scale parameter in the config.lua to letterbox (don’t need zoomEven anymore) and now it works!

now it retrieves a 961x50 ad instead of a 962x50 ad:

[lua]

CORE loadUrl javascript:AFMA_buildAdURL({“session_id”:“3956573889005809095”,“seq_num”:“1”,“slotname”:“ca-app-pub-niceid”,“rm”:2,“adtest”:“on”,“js”:“afma-sdk-a-v6599000.4242000.1”,“quality_signals”:{“ads”:[],“app”:{“preqs”:0,“support_transparent_background”:false,“pimp”:0,“session_id”:“3956573889005809095”,“seq_num”:“1”,“currts”:608619214,“pclick”:0,“basets”:608619214},“slots”:{}},“eid”:“46621067”,“hl”:“en”,“gnt”:0,“ma”:1,“battery”:{“is_charging”:true,“battery_level”:0.8399999737739563},“vc”:8,“sw”:1280,“u_sd”:1.3312501,“sp”:0,“cnt”:1,“muv”:12,“riv”:4,“ms”:“nice hash”,“mv”:“80310011.com.android.vending”,“connectivity”:{“active_network_state”:5,“active_network_metered”:false},“format”:“961x50_as”,“sh”:736,“smart_h”:“auto”,“ad_pos”:{“height”:0,“visible”:0,“y”:0,“width”:0,“x”:0},“coh”:1,“gl”:“US”,“am”:0,“cog”:1,“pt”:0,“pn”:“com.gemiware.appname”});

[/lua]

[davebollinger]

yeh, similar to what i found, and adds support to my deep suspicion that there’s a “rounding” -type error somewhere within the code.

that is, for example, hypothetically, if instead of requesting actual device physical resolution, they requested by back-converting content size by content scale, then potentially you could get this sort of “off by one” round/floor+0.5 error, requesting an ad 1 pixel too big for physical screen.  and would be consistent with results changing based on the scale mode you select (and is what i witnessed too)

just be sure to test your supposed “fix” on devices of other resolutions (where the math might work out differently).  the best i was able to achieve was to trade which devices experienced the problem (fe, ads now works on device A, but now fail on previously working device)  i never managed to find a single “fix” that worked on all my test devices simultaneously

[rob]

Well that actually makes sense.  zoomEven stretches the screen to fit the area and would report a larger screen size, though internally it’s still the smaller screen size based on your requested width/height parameters.  Just as an FYI, the config.lua where you are dynamically calculating the screen size is designed to work with “letterbox” only.  It assures your letterbox screen won’t have black bars.  zoomEven is a different way of attacking the “I don’t want black bars” issue.  Using them together can lead to issues like this.

Rob

[Hendri_Thijs]

Have the same exact error. Am testing on an android device with an app in landscape mode. The device is 1280x736 pixels (780 minus pixels for the soft buttons) it tries to retrieve a 962 x 50 ad, then it states that my screen height is 736 then it concludes that the add won’t fit the screen.
“format”:“962x50_as”,“sh”:736,“smart_h”:“auto”,“ad_pos”:{“height”:0,“visible”:0,“y”:0,“width”:0,“x”:0}
 
So it seems that it wants to use the screen height to show the banner (as in it wants to show it in portrait mode instead of landscape) is there a way to force this to landscape instead?
 
Or is corona providing google with the wrong screen height number?
 
Am using build 2511 btw.
And I have the following in config.lua:

[lua]

local aspectRatio = display.pixelHeight / display.pixelWidth
application = {
    content = {
        width = aspectRatio > 1.33 and 768 or math.ceil( 1024 / aspectRatio ),
        height = aspectRatio < 1.33 and 1024 or math.ceil( 768 * aspectRatio ),
        scale = “zoomEven”,
        fps = 60,
    },
}

[/lua]

And the following in buildsettings.lua

[lua]

settings = {

    orientation = {

        default = “landscapeRight”,

        supported = { “landscapeLeft”, “landscapeRight” }

    },

[/lua]

Tested without landscape mode in build settings and then it shows the banner in portrait mode, however my game is in landscape so this is not a solution…

so this is the working request (portrait mode):

[lua]

CORE loadUrl javascript:AFMA_buildAdURL({“session_id”:“9884268380588540517”,“seq_num”:“1”,“slotname”:“ca-app-pub-niceid”,“rm”:2,“adtest”:“on”,“js”:“afma-sdk-a-v6599000.4242000.1”,“quality_signals”:{“ads”:[],“app”:{“preqs”:0,“support_transparent_background”:false,“pimp”:0,“session_id”:“9884268380588540517”,“seq_num”:“1”,“currts”:604887717,“pclick”:0,“basets”:604887717},“slots”:{}},“eid”:“46621067”,“hl”:“en”,“gnt”:0,“ma”:1,“battery”:{“is_charging”:true,“battery_level”:0.7400000095367432},“vc”:6,“sw”:800,“forceHttps”:true,“u_sd”:1.3312501,“sp”:0,“cnt”:1,“muv”:12,“riv”:4,“ms”:“nice hash”,“mv”:“80310011.com.android.vending”,“connectivity”:{“active_network_state”:5,“active_network_metered”:false},“format”:“600x90_as”,“sh”:1216,“smart_h”:“auto”,“ad_pos”:{“height”:0,“visible”:0,“y”:0,“width”:0,“x”:0},“coh”:1,“gl”:“US”,“am”:0,“cog”:1,“pt”:0,“pn”:“com.gemiware.appname”});

[/lua]

and this is the failing one (landscape mode):

[lua]

CORE loadUrl javascript:AFMA_buildAdURL({“session_id”:“12127961398928385070”,“seq_num”:“1”,“slotname”:“ca-app-pub-niceid”,“rm”:2,“adtest”:“on”,“js”:“afma-sdk-a-v6599000.4242000.1”,“quality_signals”:{“ads”:[],“app”:{“preqs”:0,“support_transparent_background”:false,“pimp”:0,“session_id”:“12127961398928385070”,“seq_num”:“1”,“currts”:606433396,“pclick”:0,“basets”:606433396},“slots”:{}},“eid”:“46621067”,“hl”:“en”,“gnt”:0,“ma”:1,“battery”:{“is_charging”:true,“battery_level”:0.7799999713897705},“vc”:7,“sw”:1280,“u_sd”:1.3312501,“sp”:0,“cnt”:1,“muv”:12,“riv”:4,“ms”:“nice hash”,“mv”:“80310011.com.android.vending”,“connectivity”:{“active_network_state”:5,“active_network_metered”:false},“format”:“962x50_as”,“sh”:736,“smart_h”:“auto”,“ad_pos”:{“height”:0,“visible”:0,“y”:0,“width”:0,“x”:0},“coh”:1,“gl”:“US”,“am”:0,“cog”:1,“pt”:0,“pn”:“com.gemiware.appname”});

[/lua]

[Hendri_Thijs]

OK, found the solution for my issue at least. Changed the scale parameter in the config.lua to letterbox (don’t need zoomEven anymore) and now it works!

now it retrieves a 961x50 ad instead of a 962x50 ad:

[lua]

CORE loadUrl javascript:AFMA_buildAdURL({“session_id”:“3956573889005809095”,“seq_num”:“1”,“slotname”:“ca-app-pub-niceid”,“rm”:2,“adtest”:“on”,“js”:“afma-sdk-a-v6599000.4242000.1”,“quality_signals”:{“ads”:[],“app”:{“preqs”:0,“support_transparent_background”:false,“pimp”:0,“session_id”:“3956573889005809095”,“seq_num”:“1”,“currts”:608619214,“pclick”:0,“basets”:608619214},“slots”:{}},“eid”:“46621067”,“hl”:“en”,“gnt”:0,“ma”:1,“battery”:{“is_charging”:true,“battery_level”:0.8399999737739563},“vc”:8,“sw”:1280,“u_sd”:1.3312501,“sp”:0,“cnt”:1,“muv”:12,“riv”:4,“ms”:“nice hash”,“mv”:“80310011.com.android.vending”,“connectivity”:{“active_network_state”:5,“active_network_metered”:false},“format”:“961x50_as”,“sh”:736,“smart_h”:“auto”,“ad_pos”:{“height”:0,“visible”:0,“y”:0,“width”:0,“x”:0},“coh”:1,“gl”:“US”,“am”:0,“cog”:1,“pt”:0,“pn”:“com.gemiware.appname”});

[/lua]

[davebollinger]

yeh, similar to what i found, and adds support to my deep suspicion that there’s a “rounding” -type error somewhere within the code.

that is, for example, hypothetically, if instead of requesting actual device physical resolution, they requested by back-converting content size by content scale, then potentially you could get this sort of “off by one” round/floor+0.5 error, requesting an ad 1 pixel too big for physical screen.  and would be consistent with results changing based on the scale mode you select (and is what i witnessed too)

just be sure to test your supposed “fix” on devices of other resolutions (where the math might work out differently).  the best i was able to achieve was to trade which devices experienced the problem (fe, ads now works on device A, but now fail on previously working device)  i never managed to find a single “fix” that worked on all my test devices simultaneously

[rob]

Well that actually makes sense.  zoomEven stretches the screen to fit the area and would report a larger screen size, though internally it’s still the smaller screen size based on your requested width/height parameters.  Just as an FYI, the config.lua where you are dynamically calculating the screen size is designed to work with “letterbox” only.  It assures your letterbox screen won’t have black bars.  zoomEven is a different way of attacking the “I don’t want black bars” issue.  Using them together can lead to issues like this.

Rob