FEATURE_ACTIVITY_TRANSITIONS vs. FEATURE_CONTENT_TRANSITIONS

Question

I am having some trouble understanding the difference between these two Window flags and am not 100% certain when each needs to be used and why.

The docs for Window.FEATURE_ACTIVITY_TRANSITIONS say:

Enables Activities to run Activity Transitions either through sending or receiving ActivityOptions bundle created with makeSceneTransitionAnimation(Activity, Pair[]) or makeSceneTransitionAnimation(Activity, View, String).

And the docs for Window.FEATURE_CONTENT_TRANSITIONS say:

Flag for requesting that window content changes should be animated using a TransitionManager.

The TransitionManager is set using setTransitionManager(TransitionManager). If none is set, a default TransitionManager will be used.

The documentation states that the following Window methods require the FEATURE_ACTIVITY_TRANSITIONS flag to be enabled, but say nothing about whether or not the FEATURE_CONTENT_TRANSITIONS needs to be enabled as well (note that according to the source code, FEATURE_ACTIVITY_TRANSITIONS is true and FEATURE_CONTENT_TRANSITIONS is false for material-themed applications by default):

• get{Enter,Exit,Return,Reenter}Transition()
• set{Enter,Exit,Return,Reenter}Transition()
• getSharedElement{Enter,Exit,Return,Reenter}Transition()
• setSharedElement{Enter,Exit,Return,Reenter}Transition()
• getTransitionBackgroundFadeDuration()
• setTransitionBackgroundFadeDuration()

In other words, it seems like based on this information FEATURE_ACTIVITY_TRANSITIONS is the feature flag that applications will need to enable in order to use Lollipop's new Activity Transition APIs. What confuses me, however, is that this article from the Android Developers site states that enabling the FEATURE_CONTENT_TRANSITIONS is required in order to implement custom activity transitions.

So here are my questions:

1. What is the difference between these two flags? What is the difference between an "activity transition" and a "content transition" in this context?
2. Why is FEATURE_ACTIVITY_TRANSITIONS enabled and FEATURE_CONTENT_TRANSITIONS disabled by default? When is enabling the FEATURE_CONTENT_TRANSITIONS flag actually required?
3. Would it ever make sense to sense to disable FEATURE_ACTIVITY_TRANSITIONS and enable FEATURE_CONTENT_TRANSITIONS? Or does FEATURE_CONTENT_TRANSITIONS require FEATURE_ACTIVITY_TRANSITIONS to be enabled as well?

Thanks!

Mccusker

Solely based on code digging in the past 10 minutes: 1. Looks like FEATURE_CONTENT_TRANSITIONS is used when content inside a window changes. For instance, if you call setContentView(...) multiple times. Its also used when when you have shared components between activities, say a TextView. 2. FEATURE_CONTENT_TRANSITIONS could be disabled because it isn't appropriate for every scenario. If you don;t have shared components (or if your ui isn't setup that way), it wouldn't do anything. FEATURE_ACTIVITY_TRANSITIONS being enabled kind of makes sense: default transitions and all. – Shamrock

3. Take a look at PhoneWindow#setContentView(int). 4. I don't think these flags are needed for Fragment transitions. You do need to set up the transition using FragmentTransaction api. – Shamrock

Yeah, I can see a lot of what you mean by looking at the source code for PhoneWindow.java... but the difference between the two still is unclear for me. I still can't really tell whether the two flags are totally independent from each other or not. For example, would it ever make sense to enable FEATURE_CONTENT_TRANSITIONS but disable FEATURE_ACTIVITY_TRANSITIONS, or is this not allowed? – Mccusker

Either way, it seems to me that the Window documentation and the developer site article, so that is mostly the reason why I am asking for clarification here... – Mccusker

I'll code this up tomorrow. That should make things clear. At the moment, the options do look independent. – Shamrock

Answer 1

I'm glad I have an opportunity to answer these questions as the documentation is less than clear.

Early-on, there was one flag FEATURE_CONTENT_TRANSITIONS that handled both of the features. We split them when Material applications got unexpected behavior when it was enabled. So some older documentation may still say that you have to enable FEATURE_CONTENT_TRANSITIONS to get activity transitions when they mean FEATURE_ACTIVITY_TRANSITIONS.

1. What is the difference between these two flags? What is the difference between an "activity transition" and a "content transition" in this context?

An activity transition in this context means that you call startActivity with a bundle created from ActivityOptions.makeSceneTransitionAnimation or, your activity was started with that bundle. Activity Transitions modify your layout (e.g. fading in elements, moving shared elements), so if your activity doesn't like that, you should disable FEATURE_ACTIVITY_TRANSITIONS.

Content transitions use a TransitionManager when you call setContentView (other than the first time). Typically, you'll get a cross-fade, but if your Activity's content has things in common, such as sharing IDs or using transitionName, you'll get ChangeBounds behavior between those Views. You can change the details of your transitions by customizing the TransitionManager associated with your Window either using XML or code.

2. Why is FEATURE_ACTIVITY_TRANSITIONS enabled and FEATURE_CONTENT_TRANSITIONS disabled by default? When is enabling the FEATURE_CONTENT_TRANSITIONS flag actually required?

FEATURE_CONTENT_TRANSITIONS uses a TransitionManager when your content changes. By default, this is a cross-fade and that was very bad for some applications. On the other hand, FEATURE_ACTIVITY_TRANSITIONS doesn't do anything to most applications by default. You have to opt into starting an activity that way, so it is safe to turn on.

3. Would it ever make sense to sense to disable FEATURE_ACTIVITY_TRANSITIONS and enable FEATURE_CONTENT_TRANSITIONS? Or does FEATURE_CONTENT_TRANSITIONS require FEATURE_ACTIVITY_TRANSITIONS to be enabled as well?

Yes, but it is unlikely. If your application likes FEATURE_CONTENT_TRANSITIONS, it should work well with FEATURE_ACTIVITY_TRANSITIONS. If you want to explicitly limit people from calling your activity with shared elements or you don't like the standard enter transition effect, you can disable it to prevent the effect when another applications calls into yours.

Trottier

Thanks for all of this info! So just to clarify, it sounds like this documentation is incorrect in stating that enabling FEATURE_CONTENT_TRANSITIONS is required in order to use custom activity transitions? Just wanted to make sure... – Mccusker

Yes. FEATURE_ACTIVITY_TRANSITIONS is required, but FEATURE_CONTENT_TRANSITIONS is not. – Trottier

@GeorgeMount ~"You have to opt into starting an activity that way". What do you mean by that? – Sepaloid

In order to launch an activity with an activity transition, you must use ActivityOptions.makeSceneTransitionAnimation(...) and pass the bundle into the startActivity call. If someone doesn't call an activity with that, you will get no special animation behavior. – Trottier

@GeorgeMount my legacy v21/styles.xml has <item name="android:windowContentTransitions">true</item>. Not sure for what it has been added. But now I want to implement activity to activity shared element transition. Can v21/styles.xml have both windowContentTransitions and windowActivityTransitions ? My issue is here #47074527 – Dawson