nah, fwiw Freeze! has same problem, just tested. u just need a device that easily reproduces it (fe Nexus 7 2013)
(tho it’s perhaps less “obvious” with Freeze! since it has so much “filler” background at bottom of screen, so it has little if any loss of functionality despite the black bar on resume immersive)
I just checked Freeze! indeed it is also having same problem, infact once it is suspended and resumed lot of elements go off screen.
But it not noticeable since there are not many important elements at the bottom of the screen and since freeze doesnt have any banner ads it doesnt affect much.
In my game i have banner ads and i need to utilize bottom of the screen as well. so i cant use immersive sticky.
Currently im displaying the banner ads only on the start screen and game over screen, because if i enable it while the game is in progress user might accidentally click the banner ads.
it will be great if corona fixes this. i will be able to use the extra to put my banner ads on, and usually the on screen controls at the bottom of the screen distracting and there is a chance of accidental taps.
Thanks,
Nischal Y
This issue has been a headache for me. I’ve found a workaround for Android 4, a semi-workaround for Android 5, and no workaround yet for Android 6 (for which I just use “lowProfile”). Luckily, very of my users are on 6 at the moment. I can post more details if you’re interested.
I believe this is an Android OS issue at it’s core, but I also believe some other engines out there have found a workaround.
any details are very much appreciated
I’m not a believer in the “blame the OS” explanation. i regularly browse new games – partly just as a matter of “research”, but also because I (and the kids) just like to play games! 
– and have been through perhaps hundreds since immersive came out… and from my perspective the problem is NOT widespread, at all.
In fact, the only immersive apps that I myself have ever witnessed to have this problem are those made with Corona. (at least on android, where it’s easy to snag an apk and check its contents for the telltale signs of a Corona build)
So far in this thread I’ve tried to stay away from the “nyah, nyrah, tool ‘x’ solved it, so why can’t Corona?” blame game, because that tone rarely makes friends and inspires helpful attitudes, but… perhaps “a bit” of it might nag the developers into reinvestigating it?
apparently Gideros had the same symptom (though perhaps not necessarily the same cause) though I myself never saw a Gideros app with the flaw – probably because they fixed it within 2 days of being reported, see:
https://github.com/gideros/gideros/issues/37
specifically:
https://github.com/gideros/gideros/commit/65dc35a11881ef1f376dae55eaf96da9c4c77d85
I’ve read threads of this problem also being reported in Unity, LibGDX, and native. Can you give an example of an app or two that doesn’t face this problem?
I agree with you overall. If I were on Corona’s engineering team, I would focus on issues like this one (affects most apps whether developers realize it or not) until it was resolved. That is presupposing there is in fact some solution out there that other engines have discovered.
I know the Corona team has limited time and resources, but somehow the Corona voting system just fails in cases like this. Obviously this problem doesn’t show up in the Corona simulator - this likely has something to do with it. Do only seasoned developers discover this problem? Those of us that do thorough testing?
I could go on, but the list is huge. All of these are immersive, and all properly restore immersive without black bar when resumed via task list – on the same exact device that DOES exhibit the problem with Corona apps, including Freeze! (lest someone think it’s just my sloppy coding to blame)
I think the burden of proof should be the other way: find any non-Corona “A-list” immersive title that DOES have the problem.
Touche.
is there an issue/bug reported or a feature request for this, if there is one can someone share the link so that i can upvote it
doubt there’s an active bug since effectively categorized as “OS defect/won’t fix”
the existing feature request(s) “add immersive” are marked complete so can’t vote
guess you could add a new feature request “fix immersive”
I’d be curious to see what you came up with - even if perhaps i’ve already tried it. (incl all the “obvious” hacks: toggling it off/on, with/out timer.performWithDelay(), etc) cuz maybe something that’s working for you just didn’t work for me just due to some app-specific setting or whatever, but might shed some light on some aspect of the problem if it at least works for you. thx
Here is some code from main.lua. I found it’s important to not do any canvas drawing prior-to for it to work properly (do it all in whatever scene is loaded next).
For my games, this has resolved the issue with Android 4 in all cases, and Android 5 except for when the users presses the square soft-button to reenter the app, but if the user uses the app icon to reenter the game (i.e., pressed the circle soft-button first and then app icon) it works fine. Too many problems on Android 6, so I left it as lowProfile (only about 1 percent of my users are on Android 6).
One last note: I set the onResizeTimer to 2000ms. I did some testing here - 1000ms seemed to work in most cases, 1500ms in all cases I tested, so I did 2000ms to be safe. Obviously, the longer this number is, the longer the app will take to load for Google users for whom immersiveSticky doesn’t apply.
[lua]
G_screenW, G_screenH, G_halfW, G_halfH = display.contentWidth, display.contentHeight, display.contentWidth*0.5,
–etc, put other global positioning vars here
local onResizeTimer, onResize, onResizeFix, fixTimer
function onResizeFix( event )
if fixTimer then timer.cancel(fixTimer) fixTimer = nil end
fixTimer = timer.performWithDelay(1000, function() native.setProperty( “androidSystemUiVisibility”, “immersiveSticky” ) end)
end
function onResize( event )
G_screenW, G_screenH, G_halfW, G_halfH = display.contentWidth, display.contentHeight, display.contentWidth*0.5,
--etc, put other global positioning vars here
Runtime:removeEventListener( “resize”, onResize )
if onResizeTimer then
timer.cancel( onResizeTimer )
onResizeTimer = nil
Runtime:addEventListener( “resize”, onResizeFix ) --we do this here because if the timer isnt nil, then we know the game loaded via a resize event and will need the resize fix applied
end
composer.gotoScene( “loadingScene” )
end
local androidVersion = tonumber(string.sub(system.getInfo(“platformVersion”),1,1))
if platform == “google” and system.getInfo(“environment”) == “device” and androidVersion then
if androidVersion >= 4 and androidVersion < 6 then
Runtime:addEventListener( “resize”, onResize )
native.setProperty( “androidSystemUiVisibility”, “immersiveSticky” )
onResizeTimer = timer.performWithDelay( 2000, function() onResizeTimer = nil; onResize() end )
else
native.setProperty( “androidSystemUiVisibility”, “lowProfile” )
onResize()
end
elseif platform == “google” then
native.setProperty( “androidSystemUiVisibility”, “lowProfile” )
onResize()
else
onResize()
end
[/lua]
cool, thx, i’ll experiment with it.
>> I found it’s important to not do any canvas drawing prior-to
Ditto here. My main.lua(s) just “sets up the system”.
>> except for when the users presses the square soft-button to reenter the app
ahh, but that *IS* the problem! Everything else (seems to) work for me. But suspend then…
resume from icon = no problem
resume from power sleep = no problem
resume from task list (aka square button) = BLACK BAR PROBLEM
>> Too many problems on Android 6,
Yikes, haven’t yet dealt w 6.
>> function onResize( event ) G_screenW, G_screenH, G_halfW, G_halfH =
I do similar on resize, tho in a dedicated class module. But you appear to be doing this only on the INITIAL resize during startup.(after which onResizeFix is the one listening) So if you get a immersive resize do you just “pretend” (for purposes of screen layout) throughout app duration that immersive is maintained and those stored dimensions remain valid?
fwiw I haven’t noticed any *startup* problems, so I only have the one resize listener. (ie, not doing your delayed-load via resize, then setting up a new listener)
aside: you have a potential bug in not calc’ing your halfH
Oh right, I didn’t put all of my positioning vars on my post because I have a lot… halfH is getting calculated
“except for when the users presses the square soft-button to reenter the app”
The problems vary from Android 4 to 5. I think Android 4 even had black bar problems when a volume button was pressed… I don’t recall if 5 had this problem. It’s a convoluted issue overall and I don’t remember all of the particulars now, but I do know that this at least fixed some issues with 5, and all issues with 4.
“I do similar on resize, tho in a dedicated class module. But you appear to be doing this only on the INITIAL resize during startup.(after which onResizeFix is the one listening) So if you get a immersive resize do you just “pretend” (for purposes of screen layout) throughout app duration that immersive is maintained and those stored dimensions remain valid?”
Correct. In all reality, the Android 5 black bar issue is affecting a very, very small percentage of users at this point (I would venture to guess that, like my wife who has a Nexus 5, a good percentage of users with those soft keys rarely use the square). In my own apps, even when the black bar issue does still occur, it’s never a showstopper in terms of gameplay.
for corona tech staff – wonder if there’s anything to learn by how android itself toggles immersive?? (if you were to force it by policy as opposed to dev requesting it by code)
this is the version (5.0.2) i’m running that reliably reproduces the black-bar-on-resume-immersive-from-task-list problem w corona builds, so potentially any diff tween it and your implementation might be worth investigating?? say, between lines 65-111 (-ish, the rest is mostly policy support stuff)
tho in truth i can’t say how “robust” that policy is either, since it can’t add any event listeners that might also be necessary if app didn’t otherwise support immersive, so perhaps just as a double-check for view/layout flags and such.
Functional Immersive mode is required by Google for featuring certain games (e.g. kids apps). I have one app blocked from featuring just because of this issue.
Reported bug 44169, referencing this post.
This is a Google bug. https://code.google.com/p/android/issues/detail?id=170752
It happens to native developers, Unity developers and just about everyone else. We have tried to work around this. If Google is rejecting you because of them, point them to their own bug. We really can’t do more until Google provides an official solution.
Rob
The “blame the OS” story is just hard to accept, the evidence simply isn’t there, when there are sooo many apps and sooo much evidence that it works fine for the VAST majority of apps (on those same devices where Corona consistently fails)
Your engineers should carefully study the history of that bug report.
I assume they’ve seen similar reports of “real” bugs where hundreds of ppl complain day and night?
This bug report had A SINGLE REPORTER (dan) from April thru October. And note that the whopping four people (jure,mark,landon,alex) that have contributed since then, all appear to be “home grown” or indie-type developers (no big name corporate email accounts or sigs present). No offense to those individuals, but isn’t it is just as likely that they simply all made the same coding error?
If you want to perhaps blame Google’s poor developer documentation for “fooling” these 5 devs with obscure implementation details, then that’d be an easy target. I’m not suggesting it’s an easy fix, but it is clearly and obviously fixable.
Besides, isn’t it a bit rash to blame an OS used by uncounted thousands when a mere 5 developers worldwide have complained about this issue in the entire time since 4.4 was released?!
For example, I note that the original reporter makes no mention of having a focus listener at all – just as an example, as that’s one of things you’d want to properly implement immersive – did they forget even that? And if so what ELSE might they have missed?
Because there are hundreds upon hundreds of “A-list” apps that restore immersive just fine on the same exact devices where Corona apps consistently fail – that doesn’t suggest an unsolvable flaw in the OS.
A great and overwhelming preponderance of evidence is not in Corona’s favor if your engineers just throw up their hands in defeat and jump in with these other 5 who “blame the OS”.
Dave, I get it. You want the immersive feature to work without issue. We do too.
I’m one of the developers here and after a full day of testing and experimenting, yes, I’ve confirmed this to be a bug in the Android OS. Google has confirmed it too. That’s why it’s an open/assigned bug in Google’s issue tracker that Rob linked you to.
The problem is that the OS is drawing a black bar on top of the application at the bottom of the screen when it shouldn’t. We have no control over that. Nor have we found a way to detect that this is happening. ***That’s the problem.***
The OS is in a bad state and drawing a black rectangle where the navigation bar used to be, but it also acts like it isn’t there either.
I’m sure that there must be a work-around for this issue. Or perhaps it only works for very particular app activity configurations (the rumor is landscape-only apps). Unfortunately, we don’t know what it is. Nor do many other native Android developers. But until Google/someone provides an official solution for this issue, we’re all stuck.
Sad to hear that :(,
I was hoping there would some kind of hack or workaround over this issue.
Guess i have to live with the on screen controls for now.
Have been holding my release for this fix.