Screen Shield Manifest

Question

In the documentation for the Android manifest, there are several ways to specify screenOrientation :

• landscape
• sensorLandscape added in API 9
• userLandscape added in API 18

How can I specify userLandscape , but in older versions of Android, sensorLandscape on sensorLandscape , and even older versions revert to landscape ? I could not find how to do this in the documentation.

Answer 1

I don’t think there is a way to implement the backup mechanism in the manifest itself.

I would suggest that you specify one of the {userLandscape, sensorLandscape, landscape} in the manifest. Then check the version at runtime and improvise.

Let's say you decide to go with android:screenOrientation="userLandscape" in the manifest.

In your onCreate(Bundle) activity before setting up the content:

 int sdkInt = Build.VERSION.SDK_INT; // if we're running on some API level within [9, 18), use `sensorLandscape` if (sdkInt >= Build.VERSION_CODES.GINGERBREAD /* 9 */ && sdkInt < Build.VERSION_CODES.JELLY_BEAN_MR2 /* 18 */) { setRequestedOrientation( ActivityInfo.SCREEN_ORIENTATION_SENSOR_LANDSCAPE); } else if (sdkInt < Build.VERSION_CODES.GINGERBREAD /* 9 */) { setRequestedOrientation( ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE); } // API 18 or above - handled in manifest setContentView(R.layout.whatever); 

Hope someone comes up with a better solution than this. It seems brute force.

Edit:

I tried a different approach - from what I know (and I could be wrong here), enums such as userLandscape , sensorLandscape , etc. will not change the value. As they currently stand:

 <attr name="screenOrientation"> <enum name="unspecified" value="-1" /> <enum name="landscape" value="0" /> <enum name="portrait" value="1" /> <enum name="user" value="2" /> <enum name="behind" value="3" /> <enum name="sensor" value="4" /> <enum name="nosensor" value="5" /> <enum name="sensorLandscape" value="6" /> <enum name="sensorPortrait" value="7" /> <enum name="reverseLandscape" value="8" /> <enum name="reversePortrait" value="9" /> <enum name="fullSensor" value="10" /> <enum name="userLandscape" value="11" /> <enum name="userPortrait" value="12" /> <enum name="fullUser" value="13" /> <enum name="locked" value="14" /> </attr> 

So, if you have to define an integer , for example:

 <!-- `0` for `landscape` -- defined in values/integers.xml --> <integer name="customScreenOrientation">0</integer> <!-- `6` for `sensorLandscape` -- defined in values-v9/integers.xml --> <integer name="customScreenOrientation">6</integer> <!-- `11` for `userLandscape` -- defined in values-v18/integers.xml --> <integer name="customScreenOrientation">11</integer> 

Then you can use @integer/customScreenOrientation as the value for android:screenOrientation in your activity tag.

Of course, at best it’s a hack. If someone can confirm the stable status of the enumeration values ​​for screenOrientation , this can be a viable workaround - it is preferable to include the code from my previous sentence in several actions.

Another edit:

The second approach I mentioned earlier can be improved:

Instead of multiple integers.xml files integers.xml create 3 styles.xml files. I think you already have one - values/styles.xml . Create values-v9/styles.xml and values-v18/styles.xml .

 <!-- values/styles.xml --> <style name="AppTheme" parent="@style/BaseTheme"> <item name="android:screenOrientation">landscape</item> </style> <!-- values-v9/styles.xml --> <style name="AppTheme" parent="@style/BaseTheme"> <item name="android:screenOrientation">sensorLandscape</item> </style> <!-- values-v18/styles.xml --> <style name="AppTheme" parent="@style/BaseTheme"> <item name="android:screenOrientation">userLandscape</item> </style> 

After that, create values/integers.xml (single file) and define an integer customScreenOrientation :

 <integer name="customScreenOrientation">?android:attr/screenOrientation</integer> 

The activity tag will look like this:

 <activity .... android:theme="@style/AppTheme" android:screenOrientation="@integer/customScreenOrientation"/> 

The advantage of this approach in the second is that we use enumerations instead of hard-coded values. Again, these two approaches are equivalent if enum values ​​are given in stone. If they change, the second approach will fail while the third continues to move.