IssueTracker

I updated Fragment to 1.3.2, but I still get this crash.

I can confirm it with Firebase Crashlytics, but I do not know the condition of occurrence yet, and there is no sample project yet.

Re #5 - if you have a sample project that reproduces this issue, we'd be happy to take a look.

Thank you, I'll try it.

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.