Android:Configchanges="Orientation" Does Not Work with Fragments

android:configChanges=orientation does not work with fragments

Based on my experience with Honeycomb 3.0 and compatibility library (r1).

configChange="orientation" does work with fragments with respect to preventing the activity (to which it is applied) being re-created on an orientation change. If you want the fragment not to be re-created on activity re-creation then call setRetainInstance in onCreate.

Unless I'm missing something I don't quite get your second manifest entry, isn't AppListFragment a Fragment? If so then why is it listed as an entry in your manifest?

See SO Answer for new qualifiers which is likely to be causing this if you are targetting sdk 13, suggest trying android:configChanges="orientation|screenSize"

Enable display orientation change when certain fragments are visible and disable when others

You will have to do it manually.

1) add this line to your activity tag android:configChanges="orientation|screenSize"

2) Override config change callback in you fragmtn or activity

@Override
public void onConfigurationChanged(Configuration newConfig) {
        super.onConfigurationChanged(newConfig); 

   if (newConfig.orientation == Configuration.ORIENTATION_LANDSCAPE) {
        Toast.makeText(this, "landscape", Toast.LENGTH_SHORT).show();
    } else if (newConfig.orientation == Configuration.ORIENTATION_PORTRAIT){
        Toast.makeText(this, "portrait", Toast.LENGTH_SHORT).show();
    }

//Your fragment animation layout changing code

}

Fragment not re-added after orientation change

Turns out I did a Stupid Thing. I overrode the onSaveInstanceState(...) method in my activity, without calling super.onSaveInstanceState(), which resulted in the fragments not being recreated. Posting the answer here in hopes that I can save somebody else the time!

setting screenOrientation to portrait doesn't work

You can do it something like below.

After rootView in your java add this line

 getActivity().setRequestedOrientation (ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);  // programmatically

For example:

View rootView = inflater.inflate(R.layout.activityxml, container, false);       
getActivity().setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);

And also in your manifest change it:

android:configChanges="orientation|keyboardHidden"

as

android:configChanges="keyboardHidden"

<activity
    android:name="com.test.activity"
    android:label="@string/app_name" 
    android:screenOrientation="portrait"
    android:configChanges="keyboardHidden" >

Why not use always android:configChanges=keyboardHidden|orientation?

Quick Background

By default, when certain key configuration changes happen on Android (a common example is an orientation change), Android fully restarts the running Activity to help it adjust to such changes.

When you define android:configChanges="keyboardHidden|orientation" in your AndroidManifest, you are telling Android: "Please don't do the default reset when the keyboard is pulled out, or the phone is rotated; I want to handle this myself. Yes, I know what I'm doing"

Is this a good thing? We shall soon see...

No worries?

One of the pros you start with is that there is:

no need to worry about your activity been rotated

In many cases, people mistakenly believe that when they have an error that is being generated by an orientation change ("rotation"), they can simply fix it by putting in android:configChanges="keyboardHidden|orientation".

However, android:configChanges="keyboardHidden|orientation" is nothing more than a bandaid. In truth, there are many ways a configuration change can be triggered. For example, if the user selects a new language (i.e. the locale has changed), your activity will be restarted in the same way it does by an orientation change. If you want you can view a list of all the different types of config changes.

Edit: More importantly, though, as hackbod points out in the comments, your activity will also be restarted when your app is in the background and Android decides to free up some memory by killing it. When the user comes back to your app, Android will attempt to restart the activity in the same way it does if there was some other configuration change. If you can't handle that - the user will not be happy...

In other words, using android:configChanges="keyboardHidden|orientation" is not a solution for your "worries." The right way is to code your activities so that they are happy with any restart Android throws at them. This is a good practice that will help you down the road, so get used to it.

So when should I use it?

As you mentioned there is a distinct advantage. Overwriting the default configuration change for a rotation by handling it yourself will speed things up. However, this speed does come with a price of convenience.

To put it simply, if you use the same layout for both portrait and landscape you're in good shape by doing the overwrite. Instead of a full-blown reload of the activity, the views will simply shift around to fill the remaining space.

However, if for some reason you use a different layout when the device is in landscape, the fact that Android reloads your Activity is good because it will then load up the correct layout. [If you use the override on such an Activity, and want to do some magical re-layout at runtime... well, good luck - it's far from simple]

Quick Summary

By all means, if android:configChanges="keyboardHidden|orientation" is right for you, then use it. But PLEASE be sure to test what happens when something changes, because an orientation change is not the only way a full Activity restart can be triggered.

Effect of change of orientation on Fragments

Yes, normally Fragments have similar lifecycle events as activities do. They also get destroyed and recreated on orientation change.

But it is possible to set a fragment to retain instance, which means that it survives the orientation change via the setRetainInstance(boolean) methode. This introduces quite a lot of new problems, but sometimes it is still the way to go.

How can I disable landscape mode in Android?

Add android:screenOrientation="portrait" to the activity in the AndroidManifest.xml. For example:

<activity android:name=".SomeActivity"
          android:label="@string/app_name"
          android:screenOrientation="portrait" />

Since this has become a super-popular answer, I feel very guilty as forcing portrait is rarely the right solution to the problems it's frequently applied to.

The major caveats with forced portrait:

• This does not absolve you of having to think about activity
  lifecycle events or properly saving/restoring state. There are plenty of
  things besides app rotation that can trigger an activity
  destruction/recreation, including unavoidable things like multitasking. There are no shortcuts; learn to use bundles and retainInstance fragments.
• Keep in mind that unlike the fairly uniform iPhone experience, there are some devices where portrait is not the clearly popular orientation. When users are on devices with hardware keyboards or game pads a la the Nvidia Shield, on Chromebooks, on foldables, or on Samsung DeX, forcing portrait can make your app experience either limiting or a giant usability hassle. If your app doesn't have a strong UX argument that would lead to a negative experience for supporting other orientations, you should probably not force landscape. I'm talking about things like "this is a cash register app for one specific model of tablet always used in a fixed hardware dock."

So most apps should just let the phone sensors, software, and physical configuration make their own decision about how the user wants to interact with your app. A few cases you may still want to think about, though, if you're not happy with the default behavior of sensor orientation in your use case:

• If your main concern is accidental orientation changes mid-activity that you think the device's sensors and software won't cope with well (for example, in a tilt-based game) consider supporting landscape and portrait, but using nosensor for the orientation. This forces landscape on most tablets and portrait on most phones, but I still wouldn't recommend this for most "normal" apps (some users just like to type in the landscape softkeyboard on their phones, and many tablet users read in portrait - and you should let them).
• If you still need to force portrait for some reason, sensorPortrait may be better than portrait for Android 2.3 (Gingerbread) and later; this allows for upside-down portrait, which is quite common in tablet usage.

---

Related Topics