IssueTracker

Jeremy, is this still an issue? I think the problem was that you had two transitions targeting the same View for the same action (e.g. two Slide() transitions).

I have a similar issue with plain AnimatorSet:

set.start()
set.pause()
set.setCurrentPlayTime(100)
set.setCurrentPlayTime(0)
set.setCurrentPlayTime(100)
set.resume()

doesn't play animation in resume().

Should clarify that if I filter out setCurrentPlayTime(0) (or replace it with setCurrentPlayTime(1)) it works well.

Also even with setCurrentPlayTime(0), onAnimationEnd is notified with correct delay (as if the animation has played).

@ #4:

I think that is intended for Animator. If you set the currentPlayTime to 0 or the total duration the animator completes. We do some special checks in fragments to handle it.

Did some investigation on the Fragment side and it seems like the merged transition is targeting correctly.

Exiting Transition: Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
>>>>> ExitingViews <<<<<
View: android.widget.LinearLayout{f9add3d}
Entering Transition: Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
>>>>> EnteringViews <<<<<
View: android.widget.LinearLayout{b7f24bc}
Final merged transition: TransitionSet@7bc1c45: 
      TransitionSet@e133f9a: 
        Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
      Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
merged transition passed to controlDelayedTransition: TransitionSet@7bc1c45: 
      TransitionSet@e133f9a: 
        Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
      Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})

Still digging.

So I have isolated this outside of fragment into something much simpler and I think it breaks down when it comes to the adding and removing of Views with animateToStart.

The attached sample is a simple add that goes between two screens BLUE and GREEN. It has code for both the 1.5.0-alpha03 and 1.5.0-alpha04 versions, but I think alpha04 is currently broken in another way so I will upload the alpha03 version here.

This is integrated with predictive back similar to how fragment is, so upon cancelling we call animateToStart, then we do a beginDelayedTransition on a 0 duration Fade() and we reverse the view visibility back to what it was prior to starting the transition.

If you only do visibility, cancel always works the view never goes away, it is wonderful, but when you do adding and removing views like we need to in fragment it fails.

First the code for beginDelayedTransition goes from this:

TransitionManager.beginDelayedTransition(container, Fade().apply {
  duration = 0
})
reverseViews()

to this:

TransitionManager.beginDelayedTransition(container, Fade().apply {
  duration = 0
  addListener(onEnd = {
    reverseViews()
    blueScreen.visibility = View.VISIBLE
    greenScreen.visibility = View.VISIBLE
  })
})
reverseViews(useVisibility = true)

We need to make this change because after the animateToStart() view is still parented by the overlay, so we call reverseViews(useVisibility = true) to only change the visibility and then once the transition finishes we can call reverseViews() to parent the view properly, then we make both views visible again.

From our perspective after the 0 duration transition our views are back in the proper state, but they do not transition properly after a cancel.

If the app is doing this wrong and we can make the appropriate fixes, doing the same in fragment should resolve this. There is logging available that shows the state of the views when we start the transition.

The API has changed since that project was created in a way that makes the API more robust. I'm hoping that has fixed this...

There appears to be a problem with the order of operations. I'm going to look into fixing that.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.transition:transition:1.5.0-alpha05

You can only get here if your fragment has a view and the from method where this error happens doesn't even take null views (https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:fragment/fragment/src/main/java/androidx/fragment/app/SpecialEffectsController.java;l=407?q=SpecialEffectsController). So even if you were somehow able to remove the fragment's view before the transition was executed you should be getting an error when passing in the null view to from, not when the view calls getAlpha().

It is clear that the fragment definitely starts off with a view, but that view is removed prematurely by something. The only place fragments every clear out the view is when it is destroyed. Is is possible that your app is clearing the fragment view somewhere? It would be nice if we had some fragment manager logging to see what is actually going on, but without more information there isn't much we can figure out.

I was able to generate logs for activity leading up to the crash. See attached. (I am now able to reproduce the crash reliably within our application. I have not had time to prepare a standalone project that reproduces the crash.)

Meanwhile, I'll take a closer look at our Fragment-management code to see if we're clearing the fragment view somewhere. Thanks for the guidance on what might be happening here.

Based off of the logs we were able to identify the issue and get a fix.

Somewhere in the app you are popping the add of your GamecastFragment causing a remove and then attempting to do a hide() on the same fragment you just removed:

fm.beginTransaction()
  .hide(fragment1)
  .add(R.id.content, fragment2)
  .addToBackStack(null)
  .commit()

... sometime later

fm.popBackStack()
fm.beginTransaction()
  .hide(fragment2)
  .show(fragment1)
  .addToBackStack(null)
  .commit()

This is an issue because the popBackStack() kicks of the exit transition and then immediately after that the hide is enqueued. Now you have a currently removing fragment that the FragmentManager is preparing to hide. Since the hide is the last thing it sees, it doesn't know that the fragment is actually being removed and to ignore the hide until the remove is complete, so the states get mixed up and the view is destroyed. Had the app been using setReorderAllowed(true) on all of the transactions, the pop and last transactions would have been combined together and the FragmentManager would have calculated the final state and been able to avoid this. That being said it is unlikely that this behavior is actually intended cause hiding the view of a fragment that has been removed doesn't do anything.

I confirmed your findings. We have a hide that occurs earlier in code, which I think is there as a blanket measure to make sure that the fragment "behind" the fragment we're about to add doesn't remain visible:

final Fragment primaryFragment = fragmentManager.getPrimaryNavigationFragment();
if (primaryFragment != null) {
    fragmentTransaction
            .hide(primaryFragment);
}

In the scenario where we end up using popBackStack(primaryFragment.getTag(), FragmentManager.POP_BACK_STACK_INCLUSIVE) as part of our code to show the existing fragment, this hide is unnecessary. If I simply remove it, the crash goes away. If I call setReorderingAllowed(true) on the transaction, that also eliminates the crash and retains the desired effect.

I'm curious how you plan to address this, since this shouldn't lead to a NullPointerException. The hardest part about this crash is that our own code appears nowhere in the stack trace, making it very challenging to track down its cause when we see crash reports "in the wild". If this is an invalid combination & order of actions for a transaction, we would ideally find out via an IllegalStateException or something similar at the time we attempt to commit the transaction. But I can imagine that kind of validation at the time of commit could be costly. Perhaps it makes sense to discard the hide in this scenario?

Thanks for helping to understand what's going on here! This gives me a much better solution than turning off the new fragment management entirely.

This has been fixed internally and will be part of the Fragment 1.4.0-alpha03 release.

updated version 1.5.0 not fixed this.

java.lang.NullPointerException: Attempt to invoke virtual method 'float android.view.View.getAlpha()' on a null object reference at androidx.fragment.app.SpecialEffectsController$Operation$State.from(SpecialEffectsController.java:430) at androidx.fragment.app.DefaultSpecialEffectsController.executeOperations(DefaultSpecialEffectsController.java:62) at androidx.fragment.app.SpecialEffectsController.executePendingOperations(SpecialEffectsController.java:306) at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:1903) at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:1808) at androidx.fragment.app.FragmentManager.execPendingActions(FragmentManager.java:1751) at androidx.fragment.app.FragmentManager$5.run(FragmentManager.java:538) at android.os.Handler.handleCallback(Handler.java:938) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loopOnce(Looper.java:201) at android.os.Looper.loop(Looper.java:288) at android.app.ActivityThread.main(ActivityThread.java:7870) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)

Re comment#22 and comment#23 - please file a new issue that includes a sample project that reproduces your issue.

Re comment#25 - if you missed the advice in comment#24, please make sure you file a new issue that includes a sample project that reproduces your issue.