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

Comment #14 seems to work when collecting a stateflow from a viewmodel :)

The release notes of Lifecycle stated that "lifecycle-*:2.8.0 requires a minimum Compose version of 1.7.0-alpha05". However when I run ./gradlew app:dependencies --configuration releaseRuntimeClasspath I couldn't find any Compose library resolved to alpha versions, the highest version was 1.6.5.

Is the statement correct? Or do I misinterpret it?

@ comment #17:

Lifecycle does not have a transitive dependency on Compose since it's not strictly related to Compose. It's more like Compose 1.7 has been adjusted to Lifecycle 2.8.0. So you need to explicitly update your Compose dependencies.

comment#17:

lifecycle-runtime-compose 2.8.* does not explicitly depend on compose-ui 1.7.* but there is a behavior compatibility issue between the versions - meaning standard POM dependency version checks will not detect the problem.

To understand the issue better, let’s go step by step on what happened:

• We have introduced a new LocalLifecycleOwner inside lifecycle-runtime-compose.
• We have inverted the dependency between compose-ui and lifecycle-runtime-compose.
  • Before: lifecycle-runtime-compose - depends on -> compose-ui.
  • After: compose-ui - depends on -> lifecycle-runtime-compose.
• We have changed the “old” LocalLifecycleOwner from compose-ui to return the new one in lifecycle-runtime-compose for binary compatibility.
  • compose-ui 1.6.*, sets up the “old” LocalLifecycleOwner at runtime.
  • compose-ui 1.7.*, sets up the “new” LocalLifecycleOwner at runtime.
• lifecycle-runtime-compose 2.7.* needs the “old” LocalLifecycleOwner.
• lifecycle-runtime-compose 2.8.* needs the “new” LocalLifecycleOwner.

Now, when combining compose-ui 1.6.* and lifecycle-runtime-compose 2.8.* or compose-ui 1.7.* and lifecycle-runtime-compose 2.7.*, they will reference to different LocalLifecycleOwner instances at runtime.

Since there's no direct dependency between them, standard POM checks cannot detect this issue. A call chain analysis would have been required to identify the behavior incompatibility between stable versions.

Looking at the changelogs from lifecycle 2.8.1 I assume this fix was not released?

Lifecycle 2.8.1 was released last week (May 29, 2024). The workaround was merged yesterday (June 4, 2024), so it is not included in version 2.8.1. Please note that the "Date: Wed May 29" in the CL header above is a metadata that indicates when the CL was created, not when it was merged.

We intend to include it in the very next release, Lifecycle 2.8.2.

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

• androidx.lifecycle:lifecycle-runtime-compose:2.8.2
• androidx.lifecycle:lifecycle-runtime-compose-android:2.8.2
• androidx.lifecycle:lifecycle-runtime-compose-desktop:2.8.2

Can confirm, the issue reproduces on release build

Same for me too. I updated the Lifecycle lib to v2.8.2 and Compose BOM to v2024.06.00 which incorporate v1.6.8 of Compose libs. Still, the app got this exception and crashed, but only in the release mode and not in debug mode. Unfortunately, I got the crash in the production app after its release. After downgrading the Lifecycle lib to v2.7.0, it is working fine in the production app. Immediately, I had to release another patch version, so the users do not complain about app not working.

Comment #26, Comment #27, Comment #28, Comment #29, Comment #30:

We have received a similar report at b/346808608, where the author suggests a workaround (adding -keep class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt { *; } to your ProGuard rules).

Although we have included a custom ProGuard rule as part of our fix, the rule is not working as intendend across all projects. We are currently investigating the problem, see here for more details.

I can confirm it's still an issue for me with Compose BOM "2024.06.00" and lifecycle 2.8.2.

I added these lines to proguard to fix the issue:

-if public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
    public static *** getLocalLifecycleOwner();
}
-keep public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
    public static *** getLocalLifecycleOwner();
}

Following up on the issue mentioned in comment#26: a fix for b/346808608 is scheduled to be included in our upcoming hot-fix release, version 2.8.3 -- for additional details, please refer to this comment.

Following up on the issue mentioned in comment#26: there was a mix-up, and the Lifecycle 2.8.3 artifacts won't be available until Monday.

Lifecycle 2.8.3 is now available on maven.google.com.

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

• androidx.lifecycle:lifecycle-runtime-compose:2.9.0-alpha01
• androidx.lifecycle:lifecycle-runtime-compose-android:2.9.0-alpha01
• androidx.lifecycle:lifecycle-runtime-compose-desktop:2.9.0-alpha01