As counter intuitive as this is going to sound... the best solution is simply
not to use Fullscreen Mode on Mobile Devices.
I think it's important to understand how Mobile OS work., as they're different to Desktop OS.
The Foreground Application is
ALWAYS Fullscreen., while Background Applications are
ALWAYS disabled from accessing most of the Hardware.
It doesn't strictly mean they're "Idle" per se, you still must program an Idle / Low Power State... as a note: Android Go 10, 11 and 12 have some issues you might want to avoid with Process Scheduling.
I have far too many Applications (usually games) that will trigger Scheduling Conflicts and Cache Overruns., so Timers help to detect when this occurs, and to deliberately halt various operations until the cache clears itself out.
In-fact I'd recommend if you detect such, to post a notification that a problem has occurred that requires the application to close.
While such can be frustrating to users., believe me... loosing even the ability to RESET the Device until you've manually closed an App causing such is much more problematic as it can take MINUTES to do.
I most commonly have said issue with Infinite Galaxy and Warhammer 40K Lost Crusade... fun games, but they do have a habit of bricking my phone; and I have a Handset capable of running Fortnite at 30FPS on Medium.
Still, as noted whatever App is in the Foreground can be treated as a Dedicated Application; just as you would on a Console.
Yes... other Applications are "technically" still running., but they're stripped down to a "Service" as opposed to a Runtime.
As such we can ignore things such-as "Immersive" or "Fullscreen"., these are really for Desktop, TV or Browser; where the Application isn't the dedicated Runtime.
Instead all you need to worry about is making sure that the Window and Virtual Resolution are set to a Divisible of the Maximum Device Resolution.
So, say for example the Target Handset is 1920x1080., then you should have the resolutions: 1920x1080, 960x540 or 480x270.
Always set the Screen Scissor to 0,0,0,0 by Default.
I'd add an option to the Options Menu called "Overscan Compensation" with a sliding scale bar to allow people to adjust to personal preference.
Maybe even add individual Width and Height compensation.
The reason I say this is because A LOT of devices now., will embed Cameras as well as curve the corners of the screens... so having it at the limits of the Display isn't always ideal.
Especially when the Touch Area of the Display is usually smaller than said total area of the Display.
Still this said it is always a good idea to have a "Deadzone" for Touch... there are various Whitepapers on Designing Game UI to work on Overscan Displays., I'd recommend a similar approach to Touch Support and Mobile UI as well.
This just ensures that your application is always controllable.
Again on my device if I accidentally swipe up, not enough to put the App into the App Manager but enough to bring up the Bar for it; sometimes it can get "Stuck" in a reduced touch area which doesn't match the Application Display Output (taking up the whole screen).
It's just a suggestion though., and a mistake I see from very established Mobile Developers with a myriad of titles under their belt still making.
Still taking such into account can add just that bit of polish that users will notice.
