Googleads-mobile-unity: Wrong Position on Displays with a Cutout (notch)

Created on 26 Oct 2018  路  13Comments  路  Source: googleads/googleads-mobile-unity

The following results use the same code and APK file, the only difference is the simulated display cutout at the top of the display.

Steps to reproduce:

  1. Create an example banner with:
    bv = new BannerView(adUnitId, Adsize.Banner, AdPosition.Top);
  2. Use any device with Android Pie (9.0+) or with a build-in display cutout.
  3. Simulate a display cutout via developer options.
  4. Watch the banner as its position is calculated wrong.

Another example:
Try to position the banner at the bottom with a notched device,
and it will have a space between the banner and the bottom of the display, as shown in Issue #687.

this is crucial because it means it's impossible to use banners on devices with notches.
I could not find any workarounds (tried measuring the notch height and use the specific ad positioning, but I could not find any way to measure it).

Also described on Stack Overflow.

feature request P1

Most helpful comment

To anyone who is wrestling with this issue: I found a workaround. In my case it's a workaround for getting the ad to appear at the bottom of the screen, but I will also mention how you can probably get it to display at the top properly. I still hope for a release that just fixes this soon, but here is an option for those who don't want to wait around...
I discovered this workaround because I first started with the obvious solution: compute the y position manually via the obvious formula: int yDP = DensityIndependentPixels(Mathf.RoundToInt(Screen.safeArea.y + Screen.safeArea.height) - ScreenPixels(adSize.Height)); This would work, except for the fact that as of Unity 2018.3.5 safeArea always has 0, 0 for x and y, and while the width and height are usable to detect that there's a notch (although as far as I can tell, Screen.height == safeArea.height and same for width, so safeArea is entirely useless right now), you can't actually detect where the notch is... this means in this workaround I assume that the notch is at the top of the screen (a safe assumption, but some phones have two notches, one on top and one on bottom, and for those devices my workaround will leave the ad partially covered by the bottom notch... if safeArea ever gets useful values, my workaround can account for that... anyway, I digress.)...
With that assumption made we can use a slightly modified formula: int yDP = DensityIndependentPixels(Screen.height - ScreenPixels(adSize.Height));
But frustratingly while I was logging values I'd expect for the y position... it was still showing up in the same weird offset position! I started manually increasing the y position from 0 incrementally and confirmed that at a certain y coordinate, even if you increase the value, the position it would appear in would be the same! And then I discovered that if you add a fair bit more to the y value, it would inexplicably pop back up at the top of the screen and you could continue incrementing the y position to bring it back down the screen, except this time it didn't get stuck at the weird offset position! After much experimentation I found that the formula for this inexplicable extra wrap-around y offset is: (DensityIndependentPixels(Display.main.systemHeight) + adSize.Height) and when added to intendedDensityIndependentPixelPosition... you now have the banner in the y position you were expecting!
Once you simplify the math, the manual y position that is a functional workaround for placing the banner at the bottom on a notched device is the shockingly simple:

int yDP = DensityIndependentPixels(Screen.height + Display.main.systemHeight);

I've tested this with all the simulated notches in Android 9 and it works (with the caveat that the double notch partially covers the ad still, but that's better than the ad covering the UI of the app), but be warned that I haven't yet tested this on actual notched devices!
Note that you only need to do this when Screen.height != Display.main.systemHeight... otherwise you're on a notchless device and should use AdPosition.BOTTOM.
For those who want your banner to appear at the top, the manual computation for y position is even simpler. Under the same assumption that notches are always on top, the y position of the ad should be set to DensityIndependentPixels(Display.main.systemHeight - Screen.height) with no bizarre inexplicable wrap-around offset necessary. Note that I haven't tested displaying the banner at the top given that the banner in my app is always displayed at the bottom.
The x position manual formula to make sure the ad is centered is exactly as you'd expect: int xDP = Mathf.RoundToInt(DensityIndependentPixels(Display.main.systemWidth - ScreenPixels(adSize.Width)) / 2f); Nothing particularly weird there.
One final note, I noticed that after I started manually specifying the ad position, I couldn't call Show() after calling Hide() on the BannerView... it would get in a weird state where it was invisible yet clickable; to fix this simply Destroy() and create a new AdRequest instead of calling Show()... I've seen some statements on Google support forums that say this is better practice anyway.
I hope the day I lost diving into this bizarre issue and finding this workaround helps someone here.

All 13 comments

Will be prioritizing notch compatibility for the next release.

Will be prioritizing notch compatibility for the next release.

That's great to hear! Any approximation for its release date?
I need that compatibility for my initial app release :X

@rampara any updates?

This work got pushed back but will be making it into the next release. No ETAs yet but should be soon.

I have the same issue.
On Android devices with a notch the banner is cut, partially.
On iPhone with notch the banner ad looks OK(same app).
I'm on the latest version of the Google Mobile Ads(3.15.1).
On Android devices without a notch, the banner shows up OK.
My Unity version is the latest, 2018.3.0.

This work got pushed back but will be making it into the next release. No ETAs yet but should be soon.

So glad to know it's coming, I'm waiting with my app's initial release for this to be fixed

Unity 2018.3 and up now support Screen.safeArea according to this forum thread. Maybe there could be some kind of workaround for this.
My final goal is to position the banner at the Bottom, So I was thinking about calculating the notch height and use it as a custom position instead of AdPosition.Bottom.
If you have an idea, or any update regarding this issue, please let me know. Unity Ads is not ready yet for banners :\

Is there an ETA for the notch fix yet?

To anyone who is wrestling with this issue: I found a workaround. In my case it's a workaround for getting the ad to appear at the bottom of the screen, but I will also mention how you can probably get it to display at the top properly. I still hope for a release that just fixes this soon, but here is an option for those who don't want to wait around...
I discovered this workaround because I first started with the obvious solution: compute the y position manually via the obvious formula: int yDP = DensityIndependentPixels(Mathf.RoundToInt(Screen.safeArea.y + Screen.safeArea.height) - ScreenPixels(adSize.Height)); This would work, except for the fact that as of Unity 2018.3.5 safeArea always has 0, 0 for x and y, and while the width and height are usable to detect that there's a notch (although as far as I can tell, Screen.height == safeArea.height and same for width, so safeArea is entirely useless right now), you can't actually detect where the notch is... this means in this workaround I assume that the notch is at the top of the screen (a safe assumption, but some phones have two notches, one on top and one on bottom, and for those devices my workaround will leave the ad partially covered by the bottom notch... if safeArea ever gets useful values, my workaround can account for that... anyway, I digress.)...
With that assumption made we can use a slightly modified formula: int yDP = DensityIndependentPixels(Screen.height - ScreenPixels(adSize.Height));
But frustratingly while I was logging values I'd expect for the y position... it was still showing up in the same weird offset position! I started manually increasing the y position from 0 incrementally and confirmed that at a certain y coordinate, even if you increase the value, the position it would appear in would be the same! And then I discovered that if you add a fair bit more to the y value, it would inexplicably pop back up at the top of the screen and you could continue incrementing the y position to bring it back down the screen, except this time it didn't get stuck at the weird offset position! After much experimentation I found that the formula for this inexplicable extra wrap-around y offset is: (DensityIndependentPixels(Display.main.systemHeight) + adSize.Height) and when added to intendedDensityIndependentPixelPosition... you now have the banner in the y position you were expecting!
Once you simplify the math, the manual y position that is a functional workaround for placing the banner at the bottom on a notched device is the shockingly simple:

int yDP = DensityIndependentPixels(Screen.height + Display.main.systemHeight);

I've tested this with all the simulated notches in Android 9 and it works (with the caveat that the double notch partially covers the ad still, but that's better than the ad covering the UI of the app), but be warned that I haven't yet tested this on actual notched devices!
Note that you only need to do this when Screen.height != Display.main.systemHeight... otherwise you're on a notchless device and should use AdPosition.BOTTOM.
For those who want your banner to appear at the top, the manual computation for y position is even simpler. Under the same assumption that notches are always on top, the y position of the ad should be set to DensityIndependentPixels(Display.main.systemHeight - Screen.height) with no bizarre inexplicable wrap-around offset necessary. Note that I haven't tested displaying the banner at the top given that the banner in my app is always displayed at the bottom.
The x position manual formula to make sure the ad is centered is exactly as you'd expect: int xDP = Mathf.RoundToInt(DensityIndependentPixels(Display.main.systemWidth - ScreenPixels(adSize.Width)) / 2f); Nothing particularly weird there.
One final note, I noticed that after I started manually specifying the ad position, I couldn't call Show() after calling Hide() on the BannerView... it would get in a weird state where it was invisible yet clickable; to fix this simply Destroy() and create a new AdRequest instead of calling Show()... I've seen some statements on Google support forums that say this is better practice anyway.
I hope the day I lost diving into this bizarre issue and finding this workaround helps someone here.

does version 3.16 solved this issue?

No, it doesn't solve it

Please try version 3.17.0.

Awesome!

Was this page helpful?
0 / 5 - 0 ratings