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

Wrote a post on how to get fragment tests to work in the jvm without breaking release builds. Essentially just add a junit assumption to skip fragment tests if it's not a debug variant:

    @Before
    fun setup() {
        assumeTrue("Skipping non-debug test", BuildConfig.DEBUG)
    }

Any update would be appreciated :)

For a bit of context: The androidx.fragment:fragment-testing library declares an activity named androidx.fragment.app.testing.FragmentScenario$EmptyFragmentActivity in its AndroidManifest.xml file. The problem is that activities defined in a project's androidTest/AndroidManifest.xml file or in the AndroidManifest.xml file of any of the project's androidTestImplementation dependencies are not merged into the project's main AndroidManifest.xml file and therefore not available for use in the instrumentation tests. This, I believe, is the reason why the androidx.fragment:fragment-testing library has to be declared as a debugImplementation dependency instead of an androidTestImplementation dependency.

It would be great if Android testing offered a way for manifest entries defined in the project's androidTest/AndroidManifest.xml file or in the AndroidManifest.xml file of any of the project's androidTestImplementation dependencies were available for use in the instrumentation tests.

Unfortunately, there is nothing we can do about this. And modifying for test code will continue to be required.

Could a separate fragment-testing-manifest artifact be shipped that only defines the Activity manifest entries? That way only the manifest get merged into non test code, and not fragment-testing and all its test dependencies like androidx.test.core.

This is how we worked around similar issues in androidx.test.core

I'd be willing to take this on if the androidx.fragment maintainers agree with this approach.

See https://github.com/android/android-test/issues/1587 for a recent re-manifestation of this issue.

In Fragment 1.6.0-alpha04, we've added a new fragment-testing-manifest artifact. This means that instead of adding fragment-testing as a debugImplementation, you can now instead add fragment-testing-manifest as a debugImplementation and keep fragment-testing as androidTestImplementation.

debugImplementation "androidx.fragment:fragment-testing-manifest:$fragment_version"
androidTestImplementation "androidx.fragment:fragment-testing:$fragment_version"

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

• androidx.fragment:fragment-testing:1.6.0-alpha04

Please file a new bug with a minimal project that reproduces the issue.