Hi. I’m having problems with my application on samsung s10. The device navigation buttons are displayed above the application buttons (and not in a separate bar). Does this happen to anyone else? Is there any solution?
Thanks in advance.
Have you set androidSystemUiVisibility to immersive/immersiveSticky?
https://docs.coronalabs.com/api/library/native/setProperty.html
Starting from Android 10 (X), it is like that. I had the same problem when my phone was upgrade to Android 10.
I just needed to set “native.setProperty( “androidSystemUiVisibility”, “immersiveSticky” )” in main.lua
I also re-positioned by bottom-buttons to the top. Seems that apple and android is moving forward to ‘encourage’ us to put our app buttons @ top.
The bottom navigation bar height on Android is usually 48dp , so a quick fix will be to move all buttons at the bottom slightly to the top.
Thanks for your answer, they were very useful. So if I don’t use “immersiveSticky”, I would have to move the lower buttons slightly to the top when the app detects that the device uses Android 10. Am I right?
Seems like it, but shouldnt there be an api that gives the height of those buttons?
There isn’t any API. I got the value (48) from a test plugin that I have, which runs on java-android.
Hi. I moved the lower buttons slightly to the top and I added a bar to the bottom (when the app detects that the device uses Android 10), and it worked on Samsung 10 with Android 10. But then I installed the app on Huawei using EMUI 10 (android 10), and the navigation buttons are not displayed, but the app moves the lower buttons to the top and shows the bar I told you before.
Is there any way to know if the navigation buttons below are being displayed?
The first picture has been taken from a Samsung s10 and the second one from Huawei P30, where you can see the bottom bar on light grey:
Do take note, I noticed the moment I added the immersive sticky that a lot of android phones (with virtual menu buttons) end up cropping the top/bottom (landscape) edges of the game display. Seems almost like the content area is not calculated correctly (I’m using zoomEven) when using immersive sticky. But on the whole the immersive sticky works well to auto-hide the virtual menu buttons. You may want to ask where in your main.lua is the best place to place the immersive sticky code.
Best not to use zoomEven… much better to use letterbox scaling.
@SGS, thanks as always for your feedback, depends how the UI is created I suppose.
Our game runs in landscape with either 640 or 768 (default height) but the width can be any width as the menu buttons and bg images are coded to spread out. Letterbox just gives ugly black bars on the sides for devices more than 2:1 ratio and worse still it lets content show in the black bars but you can’t put anything there, so not really appropriate for games that have lots of player zooming in and out.
Anyhoo (not to steal this thread) one way devs could stick with zoomEven is how I did it; just re-adjusting any menu bars by adding their default y positions with the display.safeScreenOriginY. And also putting in a manual option for fans so they can manually adjust the top/bottom menu bars from within the options screen.
Maybe not the best approach for everyone but I don’t really code the corona way with all that scene manager and other stuff.
I use letterbox in all of my projects, be it personal, Spyric or client, and I don’t suffer from any black bars. You simply need to design around them.
For instance, a simple rookie mistake is to create a background out of a single image that looks perfect on the device resolution that you are developing for. It just doesn’t work because it’ll look off or simply bad on all other device resolutions or aspect ratios. Instead, you create the backgrounds out of multiple components so that all resolutions and aspect ratios are handled. As a result, you’ll never see a black bar anywhere unless you explicitly create one.
Also, you shouldn’t design your apps around using display.safeScreenOriginY if you are developing for Android as well as that API doesn’t work on Android yet.
@ gongalf , you can get the information via https://docs.coronalabs.com/api/library/native/getProperty.html or you could alternatively set a variable to true or false depending on the count of resize events. Since the appearance of the navigation bar will trigger a resize event, you could track how many times it has happened. The first time you hide it. Then the next time it is revealed, i.e. every even number should mean that the navigation bar is showing.
@spyric, appreciate the feedback, actually a single bg image works fine on any device if you know what your doing design-wise, but no worries I’m just doing some final ‘sticky tape’ solutions for this game’s corona version as have moved on to unity.
A few point though, as I say perhaps it’s because I don’t code the correct corona way, but display.safeScreenOriginY seems to work fine on any Android if all you need is to grab the value for adjustments. And perhaps the nav bar when using letterbox causes a resize but doesn’t seem have any effect when using zoomEven. In the end guess it depends how all things are coded.
Our game runs in landscape with either 640 or 768 (default height) but the width can be any width as the menu buttons and bg images are coded to spread out. Letterbox just gives ugly black bars on the sides for devices more than 2:1 ratio and worse still it lets content show in the black bars but you can’t put anything there, so not really appropriate for games that have lots of player zooming in and out.
Anyhoo (not to steal this thread) one way devs could stick with zoomEven is how I did it; just re-adjusting any menu bars by adding their default y positions with the display.safeScreenOriginY. mycfavisit
Do take note, I noticed the moment I added the immersive sticky that a lot of android phones (with virtual menu buttons) end up cropping the top/bottom (landscape) edges of the game display. Seems almost like the content area is not calculated correctly (I’m using zoomEven) when using immersive sticky. But on the whole the immersive sticky works well to auto-hide the virtual menu buttons. You may want to ask where in your main.lua is the best place to place the immersive sticky code.
Best not to use zoomEven… much better to use letterbox scaling.
@SGS, thanks as always for your feedback, depends how the UI is created I suppose.
Our game runs in landscape with either 640 or 768 (default height) but the width can be any width as the menu buttons and bg images are coded to spread out. Letterbox just gives ugly black bars on the sides for devices more than 2:1 ratio and worse still it lets content show in the black bars but you can’t put anything there, so not really appropriate for games that have lots of player zooming in and out.
Anyhoo (not to steal this thread) one way devs could stick with zoomEven is how I did it; just re-adjusting any menu bars by adding their default y positions with the display.safeScreenOriginY. And also putting in a manual option for fans so they can manually adjust the top/bottom menu bars from within the options screen.
Maybe not the best approach for everyone but I don’t really code the corona way with all that scene manager and other stuff.
I use letterbox in all of my projects, be it personal, Spyric or client, and I don’t suffer from any black bars. You simply need to design around them.
For instance, a simple rookie mistake is to create a background out of a single image that looks perfect on the device resolution that you are developing for. It just doesn’t work because it’ll look off or simply bad on all other device resolutions or aspect ratios. Instead, you create the backgrounds out of multiple components so that all resolutions and aspect ratios are handled. As a result, you’ll never see a black bar anywhere unless you explicitly create one.
Also, you shouldn’t design your apps around using display.safeScreenOriginY if you are developing for Android as well as that API doesn’t work on Android yet.
@ gongalf , you can get the information via https://docs.coronalabs.com/api/library/native/getProperty.html or you could alternatively set a variable to true or false depending on the count of resize events. Since the appearance of the navigation bar will trigger a resize event, you could track how many times it has happened. The first time you hide it. Then the next time it is revealed, i.e. every even number should mean that the navigation bar is showing.
@spyric, appreciate the feedback, actually a single bg image works fine on any device if you know what your doing design-wise, but no worries I’m just doing some final ‘sticky tape’ solutions for this game’s corona version as have moved on to unity.
A few point though, as I say perhaps it’s because I don’t code the correct corona way, but display.safeScreenOriginY seems to work fine on any Android if all you need is to grab the value for adjustments. And perhaps the nav bar when using letterbox causes a resize but doesn’t seem have any effect when using zoomEven. In the end guess it depends how all things are coded.
Our game runs in landscape with either 640 or 768 (default height) but the width can be any width as the menu buttons and bg images are coded to spread out. Letterbox just gives ugly black bars on the sides for devices more than 2:1 ratio and worse still it lets content show in the black bars but you can’t put anything there, so not really appropriate for games that have lots of player zooming in and out.
Anyhoo (not to steal this thread) one way devs could stick with zoomEven is how I did it; just re-adjusting any menu bars by adding their default y positions with the display.safeScreenOriginY. mycfavisit