I’ve done tests it seems to work but I need some more in-depth tests on other apps.
I’ll be back as soon as I’m sure
Two of my test devices that suffer from the issue are Samsung Galaxy A7, running Android 9, and Samsung Galaxy S9+, running Android 10.
I’ll be testing your code a bit later today and I’ll post back with the results. Thanks, Ed!
Alright, I added Samsung Galaxy A6, running Android 9, to the list of my test devices.
Using roaminggamer’s apk, I got the following results:
By adding the suggested function to my test, I got the following (I changed the grey rect into a circle and added another one to the centre to monitor for distortions):
So, the function did seem to address the issue in that the background was clearly wider (I’d wager wide enough to cover the screen, as expected), so safeActualContentWidth/Height do seem to provide the coordinates to the actual required coordinates. However, the amount of offset seems to be wrong.
I also didn’t seem to get the “if ( fixScale ) then” to fire, it always went for else. Another thing that is worrying me a bit is that while safeActualContentWidth/Height do seem to work for now, they should stop working once AndroidX support is added, i.e. when these APIs should return the display area not affected by the rounded corners.
Sorry for the fast and scatter brain responses, I’m trying to juggle several projects at the moment and trying to finish them before the weekend.
It looks like there may be a sub-pixel rounding error for that last screenshot.
You might edit the code I gave you and print out the values for fixScale and fixOffset after they get set, then get the values from log cat.
If the offset value is odd you may need to add a pixel to the offset before using it.
Note: The ‘if ( fixScale ) then’ part of the code had to run once (and only once) or the other part of the code would have crashed with a nil reference error.
I’d add print statements throughout the code to see what it is doing and when. I usually add my initials when debugging to make it super easy to find these messages.
Note 2: In case there were any question, I suspect this code won’t run at all in the simulator so you can only test it on device.
We are left to ourselves … For months …
What devices are you guys seeing this on and what versions of Android are you running?
I have a Google Pixel 3aXL running Android 10 and I don’t see this issue, but I suspect this is because in my case, the navigation bar(s) overlay the app and don’t actually shrink it like you used to see with prior Android versions.
I’ll re-charge an old device with an older version Android and see if I can replicate this. However till then, a downloadable (tiny) demo or very clear instruction on how to replicate this would help me and others.
This is the demo I made to try to replicate this (no luck on Android 10):
https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2020/03/androidShrinkage.zip
APK:
https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2020/03/androidShrinkage_apk.zip
Run, then tap screen for instructions.
There are a few issues.
First of all, I set the display’s default background colour to pink so that it is easy to spot. I then add a green rectangle on top of it that should cover the entire screen. I also add a grey rectangle to the top left corner.
As I hide the Android navigation bar, I see two pink bars on both sides of the display. However, my green rect was supposed to cover the entire screen, which means that display.actualContentWidth and display.actualContentHeight did not return proper values. Also, since there are two pink bars, it means that Corona automatically offset all display objects. This is also evident from how the grey rectangle has moved, see the image below:
Now, I can get around the pink rectangles by just making the green rect twice as wide (or tall, depending on orientation), but we can still see that the grey rect has been moved in the picture below:
So, we’d essentially need to get the height of the navigation bar so that we’d know what the actual size of the screen is. Now, we’d still need to know what the amount of offset is, I’m guessing it is half the height of the navigation bar, and then we’d need to manually add to this offset and move all display objects or groups in resize events to manage this event as it is intended to be handled.
Here’s the code that I used:
display.setStatusBar( display.HiddenStatusBar ) display.setDefault( "background", 0.9, 0, 0.7 ) local bigRect = display.newRect( display.contentCenterX, display.contentCenterY, display.actualContentWidth, display.actualContentHeight ) bigRect:setFillColor( 0, 0.5, 0 ) local smallRect = display.newRect( display.screenOriginX+1, display.screenOriginY+1, 100, 100 ) smallRect:setFillColor( 0.1 ) smallRect.anchorX, smallRect.anchorY = 0, 0 if system.getInfo("platform") == "android" then native.setProperty("androidSystemUiVisibility", "immersiveSticky") endI mean… there must be some API that gives that value??
Or if there isn’t then wouldn’t it be pretty easy to write such a plugin? Or something
What devices and versions of Android are you guys seeing this for.
I am using samsung galaxy serieswith latest android versions
I believe I’ve encountered this on all devices that have these virtual navigation bars on Android. The images above were taken from Samsung Galaxy A7.
You guys are both using Android 10? Please be specific. This may help narrow the issue down. You can get this info under
Settings --> About Phone --> Android Version
I have version 9 but as said XeduR@Spyric I don’t think it’s a version problem
With regards to Android versions and devices, more data is more data. Maybe Android version doesn’t matter, but I suspect it does since I don’t see this issue on my device with Android 10.
However… I could be wrong.
Important
I just updated the demo app to use the ‘pink background’ method suggested above.
Can one or both of you, (re-) download the project and install it on your device or just use the APK link and run that?
I’l like to know if the sample demonstrates the problem. Without something to debug from as a base it’s hard to help.
I am still digging for a device that shows this problem, but no luck.
> Pixel 3A XL (Android10) - Does not have this issue
> Galaxy Tab 4 - Has on bezel buttons so can’t use device to test this out.
> Nexus 7 Gen 1 (Android as yet unknown) - Currently trying to recharge, but so far it is a brick. However, if I can get it charged I’ll keep digging using this device.
Interesting discussion here: https://forums.coronalabs.com/topic/76330-android-10-soft-navigation-key-problem/ Seems the behavior I’m seeing may be because of Android 10 and/or because I’m using a Pixel 3aXL.
Yay. Got my Nexus 7 to charge and boot.
My Gen 1 Nexus 7 running Android 5.1.1 demonstrates the issue, so I can now try to help.
OK. I think I have a solution.
Please add this code to the very top of main.lua OR at least before you do any scaling or object creation.
local function androidShrinkageFix() local beforeViewableContentHeight = display.safeActualContentHeight local afterViewableContentHeight local fixScale local fixOffset = 0 local currentStage = display.getCurrentStage() local function onResize() if( fixScale ) then currentStage:scale(fixScale,fixScale) currentStage.y = -fixOffset/2 else afterViewableContentHeight = display.safeActualContentHeight fixScale = afterViewableContentHeight/beforeViewableContentHeight fixOffset = afterViewableContentHeight - beforeViewableContentHeight currentStage:scale(fixScale,fixScale) currentStage.y = -fixOffset/2 end end Runtime:addEventListener( "resize", onResize ) end androidShrinkageFix()
Then, proceed as you have been, and use the same code you have to hide the navigation bar as needed.
Try it out for a bit and write back with your results. I’ll post again after that.
I’ve done tests it seems to work but I need some more in-depth tests on other apps.
I’ll be back as soon as I’m sure
Two of my test devices that suffer from the issue are Samsung Galaxy A7, running Android 9, and Samsung Galaxy S9+, running Android 10.
I’ll be testing your code a bit later today and I’ll post back with the results. Thanks, Ed!