IssueTracker

Woops, I should have had this for the fragmenttransaction instead.  I believe the other way would stop animations from working completely.

getSupportFragmentManager()
                                .beginTransaction()
                                .setCustomAnimations(
                                        R.anim.animate_in,
                                        R.anim.animate_out,
                                        R.anim.animate_in_pop,
                                        R.anim.animate_out_pop)
                                .addToBackStack(tag)
                                .replace(R.id.fragment_container, fragment, tag)
                                .commit();

[Comment deleted]

You can temporarily fix this by adding:
android:configChanges="orientation|screenSize"
to your FragmentActivity in the manifest.

Note the solution presented by Comment 3 only address configuration changes, it doesn't deal with the issue when saveInstanceState is caused by entering the background, i.e. via the Home key.  Then resuming in that scenario the animations are also lost in the same manner.

The problem here is not that the state isn't saved and restored, the problem is how the BackStackRecord is rebuilt.  The ops themselves do save and restore the state, the problem is in BackStackRecord#addOp.

    void addOp(Op op) {
        if (mHead == null) {
            mHead = mTail = op;
        } else {
            op.prev = mTail;
            mTail.next = op;
            mTail = op;
        }
        op.enterAnim = mEnterAnim;
        op.exitAnim = mExitAnim;
        op.popEnterAnim = mPopEnterAnim;
        op.popExitAnim = mPopExitAnim;
        mNumOp++;
    }

The enter, exit, popEnter and popExit animations are overwritten with whatever is currently in the record, which during the restoration process these are 0 so the values which were saved in the ops is lost.  Given that these variables are package private we could just do...

            op.enterAnim = mOps[pos++];
            op.exitAnim = mOps[pos++];
            op.popEnterAnim = mOps[pos++];
            op.popExitAnim = mOps[pos++];
            final int N = mOps[pos++];
            if (N > 0) {
                op.removed = new ArrayList<Fragment>(N);
                for (int i=0; i<N; i++) {
                    if (FragmentManagerImpl.DEBUG) Log.v(FragmentManagerImpl.TAG,
                            "BSE " + bse + " set remove fragment #" + mOps[pos]);
                    Fragment r = fm.mActive.get(mOps[pos++]);
                    op.removed.add(r);
                }
            }
            bse.mEnterAnim = op.enterAnim;
            bse.mExitAnim = op.exitAnim;
            bse.mPopEnterAnim = op.popEnterAnim;
            bse.mPopExitAnim = op.popExitAnim;
            bse.addOp(op);

OR, alternatively you could check the op anim's are NOT zero before copying them across in the first place.

Hope this helps someone else, and I hope we can have this fixed as this problem still exists in v9 of the support library, are there really not many people using custom animations???  

Note this issue is easily reproduced with the API demo app fragment custom animations.

One final comment, this doesn't just affect the support library it affects the native Fragment support as well.

Good discovered. Many apps sets the orientation to portrait or landscape and even more still only use activities when switching and using the back stack. I think that are the primary reasons it haven't been discovered before. I'm amazed google has over seen this.

This is still an issue in r11 of the support library.

yep this is an issue, it's surprising that not many people are complaining about this.

and as said r11 still has this problem, someone should change the issue title.

Also experiencing the same problem. All fragment transaction animations gone after configuration change.

Man... this sucks. I was debugging for a while until I found this bug already filed. I can't believe that this is still an issue. The way I see it I only have two options:
1) Rely on android:configChanges="orientation|screenSize" and not use custom layouts for landscape
2) Live with the lack of custom animations after config changes.

I might have to pick (2), which is really unfortunate. Looking forward to a fix soon (hopefully).

Still not fixed in revision 13. :(

James.w's approach works great as a fix if you're okay with patching the support library manually.

Looks like it's still a problem in r18.

Please tell a fix to this issue... i am also facing this same issue....

I'm not using support library and i have this issue too... :(

Support Library revision 18.0.0 still has this issue.

[Comment deleted]

As a workaround for this you can use onCreateAnimator/onCreateAnimation methods in your fragments.

For example for native fragments implementation:

    @Override
    public Animator onCreateAnimator(int transit, boolean enter, int nextAnim) {
        if (enter) {
            return AnimatorInflater.loadAnimator(getActivity(), R.animator.slide_in_top);
        } else {
            return AnimatorInflater.loadAnimator(getActivity(), R.animator.fade_out);
        }
    }
       
The same technique for support library fragments with Animation instead. In this case you also have more control over how would you like to play animation depending upon fragment state and/or arguments.

Support library 19.0.1 still has this issue

The native package in SDK 19 still has this problem.
:/

Are you guys going to fix this in upcoming releases?

Does that mean it's fixed?

Not necessarily...
Quoting https://source.android.com/source/life-of-a-bug.html
`Obsolete: Similar to Unreproducible, but with a reasonable certainty that the bug did exist in the reported version but was already fixed in a later release.´

BTW, i received notifications of many old bugs marked as obsolete, so it's more likely to be a "house cleanning"

Yes, consider it a house cleaning.

That said, we do have a patch contributed that needs some soak time. Reviving this.

Is this issue fixed yet? Workarounds aren't that great...

[Comment deleted]

What's new about that ? Still buggy in v21 (not testesd in v22)... are you kidding guys ? please..

still happening in 22.2.0

23.0.1 not fixed yet

Im having the same issue and still do not see a solution from google.

This issue was first reported well over 3 years ago, and 2 major revisions of the support library have been released since a patch was apparently contributed, yet it still contains this bug for which a solution has already been provided by another user. Android emphasizes the importance of interaction and motion in design, yet this significant user interaction bug that completely negates some of the most important aspects of material design still exists. Can you please provide an update on the status of this issue?

Support library 23.1; still exists.

This is still a thing in 23.2.1.

Sample app here https://github.com/consp1racy/android-support-preference

Click "Subscreen", rotate device, click back. Fragments should've crossfaded.

Please fix. It is much easier for you to implement the above change than it is for each individual developer to maintain their own copy of the support library.

This is fixed in version 23.3.0

I concur, the issue is not observed in 23.3.0.

Issue still exists in 23.4.0. Seriously, Google - fix this.

Why is this not being fixed?!!

Issue still exists. Hopefully we see a fix soon, as this is a pain to resolve manually.

Thank you for the feedback. We're closing this issue as Obsolete.
If it is still observed in the latest Android release, please open a new issue in https://goo.gl/TbMiIO along with a reference to this issue.