Is there any update on this, im hitting this issue as well, hope someone can solve this issue, as it will give us some extra space to put some ads 
No news on my end from Google…
But somehow many apps in the corona showcase have worked around this problem, for instance the game “Freeze” doesnt have any problem even when we suspend and resume. Are these people having enterprise corona and did some hack around it?
I was just revisiting this problem to see if anything had changed with recent builds (unfortunately does not appear so)
however, I do have some new info to offer… (might be worth a quick re-read of the exchange between myself and Joshua Quick on 5 May 2015 as prep)
I’m going back to my original assertion that resizing of the view does NOT occur (following suspend/resume, restoring immersive sticky, bar hiding, black area remaining, and despite the resize event)
the “black bar at bottom” is NOT some leftover OS “overlay” remnant – it is a “void” area caused by the view not resizing to fill the full-screen immersive screen dimensions.
yes, a resize event occurs, and yes, the full screen dimensions are reported, but NO – the app’s view is NOT actually resized. (I’m willing to believe the the GL surface is being resized to fullscreen, but it must be getting cropped/clipped by the app’s view which is NOT resized to fullscreen.)
how do I know? android sdk monitor. See linked image. This is on a Nexus 7 2013 5.0.2. You see that the view’s size upon resume/restore immersive is less than (1824) fullscreen (1920) and there are no UI elements at all in that black void at screen bottom. (and you can’t see it, but at the bottom of the app’s blue background is a little “marker” rect that WOULD be visible if the entire surface were occupying the entire screen)
so, potentially: GL surface resizing, app view not resizing? does that perhaps offer any new clues to reopen the investigation of this? thanks for your consideration
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?
- Just for starters: Angry Birds, AB Transformers, Clash of Clans, Crossy Road, Cut The Rope, Doodle Jump, Fruit Ninja, Hill Climb Racing, Jetpack Joyride – ever hear of any of those?
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.
- I suspect that most (like me) just “give up” cuz it’s the best we can do with what we have to work with. fe Freeze! has 5M+ downloads (and congrats to them!) but apparently isn’t bothered by it. It may be that unless you happen to be unlucky enough to have one of the devices that easily replicates the problem, then it’s not a big deal. (tho there are a lot of Nexus’s out there!)
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.