I am wondering if it is possible to automatically set the “screenOrientation” activity tag to “portrait” rather than “sensorPortrait” in the AndroidManifest,xml file generated by lime.
Indeed, currently, setting the window orientation tag to “portrait” in project.xml results in a “sensorPortrait” value in the AndroidManifest file.
The only way to circumvent this seems to be to override the whole AndroidManifest.xml file (whith the drawback that any further change you will make in your project.xml file would not be taken into account if you forget to update your AndroidManifest.xml template…).
So maybe it would be worth adding a “autoRotation:true/false” tag to the project.xml window tag so that if orientation is set to portrait and autoRotation turned to true, it would result into a “sensorPortrait” value in AndroidManifest.xml and if “autoRotation” is set to false, to a “portrait” one (same thing for sensorLandscape/landscape and sensor/nosensor)
Also, I am wondering what would be the behaviour on IOS with window orientation set to “portrait” (I do not own an IOS device to test it, yet). Would it also also flip upside down if the device is rotated 180° or not?
Apple changed the submission policy a while back – it was required to allow orientations that were the flip of the original, at least for landscape. I might be wrong about the policy for portrait, so perhaps landscape should be sensor landscape, and portrait should just be portrait. Does anyone have any more information about this?
Apple or Google? They both prefer that you support all possible orientations, but I didn’t find a statement from either one saying that you have to.
Yeah, I think Apple started rejecting applications that supported landscape left, but not landscape right. I forget if this applied to portrait up and portrait down (or not)
And you’re bringing up Apple because you want to keep the Android version in sync with the iOS version? I wouldn’t worry. Android’s system UI only uses three orientations, while iOS’ UI uses all four. Android users are used to only having one portrait orientation available.
Or how about this as a solution? Allow users to set any orientation using <android screenOrientation="xyz" />, where xyz is any of these strings. This should only require one extra condition in the AndroidManifest.xml template, plus a couple lines of code in ProjectXMLParser.
Ah, found some of it: (this is from Apple)
- Launch your app in your supported orientation, regardless of the current device orientation. For example, if your game or media-viewing application runs in landscape only, it’s appropriate to launch your app in landscape, even if the device is currently in portrait. This way, if people start your application in portrait, they know to rotate the device to landscape to view the content.
- Support both variants of an orientation. For example, if your application runs only in landscape, people should be able to use it whether they’re holding the device with the Home button on the right or on the left. And, if people rotate the device 180 degrees while using your application, it’s best if you can respond by rotating your content 180 degrees.
On iPad, strive to satisfy users’ expectations by being able to run in all orientations. The large iPad screen mitigates people’s desire to rotate the device to landscape to “see more.” And, because people don’t pay much attention to the minimal frame of the device or the location of the Home button, they don’t view the device as having a default orientation. This lack of awareness of an app’s default orientation leads people to expect apps to run well in the device orientation they’re currently using. As much as possible, your application should encourage people to interact with iPad from any side by providing a great experience in all orientations.
I believe that landscape should always be both landscape orientations – I have had a lot of trouble where different games and applications expect you to use landscape, but opposite rotations. I see no good reason for supporting only one 
I am, however, open to supporting right-side-up portrait only when using “portrait” orientation, and never upside-down. Based on Apple’s recommendations, this seems like it should support both on Apple platforms, but if enough people agree, then right-side-up-only portrait for Android might be acceptable
I think that whatever the mobile platform (and when technically possible), openfl should offer the option to:
- choose the orientation: portrait, landscape, both. This option already exist. This is the windows orientation tag.
- choose to lock automatic screen rotation or not (so, if locked, when the game is started in one portrait orientation, it should stick to it, whether when unlocked, it can flip between the two portrait orientations if the orientation is forced to portrait or between the 4 possible orientations if the orientation is not specified). A new tag should be added to project.xml to allow this.
This, regardless the apple or android policies. Indeed, these policies can change, but also, some people can want to developp applications not meant to be put into the official stores (applications for jailbreaked and rooted phones, personnal applications…), in which cases the stores acceptation policies do not apply 
I think it is up to the developper to ensure that the options he choose do not break the store policies, but, by default, openfl should allow him as much liberty as possible.
The other solution would be the one suggested by player_03 and have platform specific tags in the project.xml file that allow to choose the orientation for a specific target and that accept all the possible orientations for it (for example, for android, it would accept all the android:screenOrientation values: http://developer.android.com/guide/topics/manifest/activity-element.html)
It is possible to have “full” control by overriding the AndroidManifest.xml template
I agree, though, we should have better APIs for controlling runtime locking, as an application might want to allow portrait, sometimes, but otherwise run in landscape mode
In general, I see no harm in supporting both landscape orientations, and think it is a best practice. For portrait, maybe it’s up in the air. For a tablet, I think that both is probably better. For a phone, I think it could go either way?
It is possible to have “full” control by overriding the AndroidManifest.xml template
I know but it is not really convenient as you loose the automatic AndroidManifelst.xml generation based on Project.xml parametters
In general, I see no harm in supporting both landscape orientations, and think it is a best practice.
It can be an issue if the user interaction with your apllication is based on mobile rotation (for example: https://github.com/HaxeFlixel/flixel-demos/tree/dev/Input/FlxAccelerometer where you control gravity direction by rotating your device)