We're trying to meet all Amazon Kindle guidelines, particularly this one: 2.35 Orientation Lock Test: Ensure that the app's orientation is correct following device orientation setting. Expected Results: If device orientation is locked in device settings, app orientation should not change upon rotating the device. The app should open in its default orientation or as per the locked orientation in the device. The orientation should not change automatically on rotating the device if it is locked in the device. Does this mean that we need to prevent all orientation changes from occurring - including landscape to reverse landscape - when the orientation lock is ON? If so, how do we detect that the orientation lock is ON or OFF programmatically? Thanks in advance for your help!
Hi AmyKaroline, Thank you for the post. If your app supports landscape and portrait both the modes, you should check that if screen orientation is locked your app should not change orientation when device rotates. e.g. If you lock the screen in landscape mode, your app is supposed to be always in landscape orientation. When orientation lock is on, app is not going to receive any orientation change event in run time. Hope this helps.
The OP didn't follow up, but I'm also looking for an answer to the question "How do we detect that the orientation lock is ON or OFF programmatically?" I do this according to the Amazon docs: setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_SENSOR_LANDSCAPE); But the orientation will always change regardless of what the user has set for the system lock. The docs do not make mention of a function for reading the lock state.
I found the answer to this. You can detect system orientation lock using ACCELEROMETER_ROTATION. if (android.provider.Settings.System.getInt(getContentResolver(),android.provider.Settings.System.ACCELEROMETER_ROTATION, 0) == 1) // Rotation unlocked else // Rotation locked You can then use setRequestedOrientation() to actually lock the orientation using one of the following locked flags: SCREEN_ORIENTATION_PORTRAIT, SCREEN_ORIENTATION_LANDSCAPE, SCREEN_ORIENTATION_REVERSE_PORTRAIT, SCREEN_ORIENTATION_REVERSE_LANDSCAPE Then just set it back to one of the sensor flags when rotation is unlocked.
I'm getting a bit mad with all the Amazon-specific orientation, which doesn't follow the rest of the world standards. Once the device orientation is locked (by using the status bar lock button), far enough the app should not change orientation, which is easy to implement. But... why then the camera preview feed is given upside down? If I lock the device when orientation is in landscape mode and front camera on the top the device, then the camera preview feed is wrongly upside down. Not even changing the camera orientation parameters will correct this problem. I've tried to pass all possible angles to the camera properties but all are ignored. so even if I can detect if the device is locked yes I can change my UI not to rotate, but is useless for a camera app, as your preview feed is wrong, on the other hand if I lock the device also in landscape, but this time the front camera at the bottom of the device, remember holding the device in landscape mode. then the camera preview feed is correct. Any reasons or solutions? Thanks Message was edited by: ferran9
So we were able to narrow the problem. Correcting my previous statement, the camera preview orientation can be fixed by setting the correct orientation on the camera object parameters. So yes if you test any app which simply shows the camera preview without trying to play with the frames no problem at all. But there is a big problem. For camera apps which work with the "onPreviewFrame" callback, where byte array frames are given back so we can process them for real time effects, are given inverted. Their orientation doesn't correspond to the changes done to the camera orientation. That means we can render the real camera on a surface and will appear correctly, and then in a second surface have different render with the frames from the onPreviewFrame but will appear with an incorrect orientation. We can flip the byte frame data, but of course this gives an overhead plus we need to detect in which scenarios (rotation, or rotation + lock, etc) we need to do this byte array flip, which doesn't seem to be consistent on your devices. So seems your devices have orientation locking, possible fixes for orientation, etc. But have missed the part of correcting the frames byte arrays orientation in the onPreviewFrame callback.