Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong Position on Displays with a Cutout (notch) #792

Closed
itayganor opened this issue Oct 26, 2018 · 14 comments
Closed

Wrong Position on Displays with a Cutout (notch) #792

itayganor opened this issue Oct 26, 2018 · 14 comments
Labels
Feature Feature request. P1 Priority issue.

Comments

@itayganor
Copy link

itayganor commented Oct 26, 2018

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.

@rampara rampara self-assigned this Oct 26, 2018
@rampara rampara added Feature Feature request. P1 Priority issue. labels Oct 26, 2018
@rampara
Copy link
Contributor

rampara commented Oct 26, 2018

Will be prioritizing notch compatibility for the next release.

@itayganor
Copy link
Author

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

@itayganor
Copy link
Author

@rampara any updates?

@rampara
Copy link
Contributor

rampara commented Jan 23, 2019

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

@mariome17
Copy link

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.

@itayganor
Copy link
Author

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

@itayganor
Copy link
Author

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 :\

@silencewebber
Copy link

Is there an ETA for the notch fix yet?

@silencewebber
Copy link

silencewebber commented Feb 25, 2019

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.

@li3p
Copy link

li3p commented Apr 3, 2019

does version 3.16 solved this issue?

@mariome17
Copy link

No, it doesn't solve it

@stowy
Copy link
Contributor

stowy commented May 16, 2019

Please try version 3.17.0.

@itayganor
Copy link
Author

Awesome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Feature request. P1 Priority issue.
Projects
None yet
Development

No branches or pull requests

7 participants
@li3p @stowy @itayganor @silencewebber @rampara @mariome17 and others