Android game does not support ScreenOrientation.FullUser

[dtaylorus]

KNI Android requires ScreenOrientation.FullSensor, which does not honor the user auto-rotate setting.

Expected: KNI Android should also allow ScreenOrientation.FullUser which honors the user auto-rotate setting.

See https://developer.android.com/develop/ui/compose/quick-guides/content/restrict-app-orientation-on-phones, specifically:

specifying fullUser matches more closely the behavior the user defined for the device: if the user has locked sensor-based rotation, the app follows the user preference; otherwise, the system allows any of the four possible screen orientations

[dtaylorus]

I'm getting intermittent InvalidOperationException "NaturalOrientation detection failed" crashes on startup in release builds on Android. My best guess is it's a timing issue with the splash screen, but I'm not sure.

My preference is to remove the code that throws this exception. It seems unnecessary to try to enforce an orientation setting and we really don't want a released game crashing without a good reason.

[nkast]

The full error message is "NaturalOrientation detection failed. Set ScreenOrientation in MainActivity to FullSensor." This is by design.
Removing the code would break the functionality of GraphicsDeviceManager.SupportedOrientations.

[dtaylorus]

What exactly is broken? I'm not seeing any issues in my testing with FullUser which is the recommended setting from the Android docs. We want to honor the user's "Don't rotate" setting, right? FullSensor explicitly ignores that setting per the documentation.

[nkast]

So you have a game that support both landscape and portrait?

If you want to propose extending SupportedOrientations and post a PR that implements it, we could get merged.
Personally I don't see much value to this for the majority of games.

[dtaylorus]

Yes, I have games that support both orientations. It’s especially useful on tablets. If you can tell me what doesn’t work if I just remove this check I’d be happy to work on a fix. I don’t see anything broken after simply removing it so far.

…

________________________________ From: Nikos Kastellanos ***@***.***> Sent: Saturday, February 15, 2025 10:09:06 AM To: kniEngine/kni ***@***.***> Cc: David Taylor ***@***.***>; Author ***@***.***> Subject: Re: [kniEngine/kni] Android game does not support ScreenOrientation.FullUser (Issue #2215) So you have a game that support both landscape and portrait? If you want to propose extending SupportedOrientations and post a PR that implements it, we could get merged. Personally I don't see much value to this for the majority of games. — Reply to this email directly, view it on GitHub<#2215 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS4U76TPNA6E5RON7KI7LD2P5KBFAVCNFSM6AAAAABXEYCWICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRQHE3DIMZYGQ>. You are receiving this because you authored the thread.Message ID: ***@***.***> [nkast]nkast left a comment (kniEngine/kni#2215)<#2215 (comment)> So you have a game that support both landscape and portrait? If you want to propose extending SupportedOrientations and post a PR that implements it, we could get merged. Personally I don't see much value to this for the majority of games. — Reply to this email directly, view it on GitHub<#2215 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS4U76TPNA6E5RON7KI7LD2P5KBFAVCNFSM6AAAAABXEYCWICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRQHE3DIMZYGQ>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[nkast]

Mainly, it's that you can control orientation by setting graphics.SupportedOrientations and call graphics.ApplyChanges() at any point.
For more information see: https://shawnhargreaves.com/blog/orientation-and-rotation-on-windows-phone.html
and also test the Orientation sample: https://github.com/kniEngine/XNAGameStudio/tree/main/Samples/Orientation/

SupportedOrientations was implemented early on, but then it was broken in flavor of setting the orientation directly on the Activity. I think their priority was to enable FullUser as well.
I reported the issue in 2018, that was about the time I was porting one of my WindowsPhone games to android. MonoGame#6605

Apparently another attempt to enable rotation lock was going on in parallel, as part of replacing OpenTK.
The code was using ACCELEROMETER_ROTATION and
wasn't quite right. However, it looks like it was in the right path.

The fix that revert all those changes was included in the first release of KNI, along with additional fixes and improvements.
8d97ce8

The code that handle orientation is very complicated. I did several rewrites to clean it up in order to make it more readable, instead of having to dig 4 methods deep. The work continues even to this day.
The goal is to not break anything in the process, but I'm now thinking that we should rewrite everything from scratch. ;-)

For example, it might be better to lister for orientation changes from Activity.OnConfigurationChanged(...) instead of detecting it from the accelerometer and set it explicitly on Activity.ScreenOrientation.

[dtaylorus]

@nkast Thank you for all the work you've put into this feature.

Honestly, though, I don't think orientation code belongs in the game engine at all. It's a completely unnecessary complication for me. In all my games I simply support all orientations as far as the game engine is concerned and control the orientation using native platform features such as the Android manifest or iOS info.plist instead.

I've never had a need to know the device orientation anyway--only the window bounds.

These days with multiple windows possible on mobile devices the effective orientation of the game window can be portrait while the actual device orientation is landscape. So device orientation is misleading anyway and I always go with the window orientation which you can't really control, unless you want to try to disable split screen mode, for example, on iPads.

So if it were up to me, I'd remove SupportedOrientations from the engine as well as CurrentOrientation and anything else related to DisplayOrientation.

In my opinion this feature in XNA was created for a world that doesn't exist anymore.

[dtaylorus]

On a related note, I think TitleSafeArea is the place to deal with differences related to the device orientation, such as the position of notches in the screen, or rounded corners, or OS controls overlaid on the screen, rather than making assumptions about these things using DeviceOrientation.

In my games I've had to handle adding appropriate title safe area bounds in fairly complicated native code that sure would be nice to move into the game engine.

For example, I use the window bounds to draw a full screen background which goes under the notches and system controls and rounded screen corners, but then make sure my game UI controls and any important visuals stay inside the native safe area bounds, which requires scaling the native bounds to game engine pixels and handling any changes while the game is running.

I expose this as a new SafeAreaBounds property in my games as a replacement for TitleSafeArea since TitleSafeArea has not been updated to account for the special cases with modern mobile screens and is essentially useless.

If TitleSafeArea were updated to accurately represent the appropriate window safe area bounds for modern mobile devices taking into account screen notches, etc., it sure would make it easier to implement full screen games on modern mobile devices, and I think it would help to remove the temptation for developers to make bad assumptions related to device or even window orientation in a new world of mobile devices with multiple windows.