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

RE#12 31.3.15 uses build 9456632 so it should have included the fix. Let's sync up in chat.

Retried as per offline discussion with Weilun, sometimes the time adjusts automatically but sometimes it gets adjusted after interacting with AVD.

I think we can close the bug as verified.

I'm still seeing this issue in Emulator 32.1.10.

RE#16 Hi minyushov@, would it be possible to provide more details with what kind of host OS and what are the repro steps I can follow? Thanks!

Hi

I'm using MacBook Pro with Apple Silicon and macOS Ventura 13.0.1.

Steps are pretty straightforward:

1. Power adapter is plugged in. Energy mode is set to Automatic for both 'On battery' and 'On power adapter' options.
2. Run emulator.
3. Keep it running until macbook automatically goes to sleep.
4. Wake it up after ~10 minutes and observe the time in the emulator. It shows not the actual time but the time when macbook fell asleep.

I'm not sure that this happens all the time but often enough.

RE#18 Really appreciate it. I will start testing it.

#18

One more question: After step 4 Wake it up after ~10 minutes and observe the time in the emulator. It shows not the actual time but the time when macbook fell asleep., have you tried to move the emulator window? I think the time should be updated when you starting using the emulator.

I'm not sure that I've moved the emulator window but usually I install our app using Android Studio and see network errors due to time difference between the app and our servers. So it looks like the time isn't updated in this case.

RE#21 Another question, are you using the emulator in a tool window? I think it might be the specific scenario which still has bug.

I'm launching the emulator in a standalone window.

RE#24 Ok, I tried it myself and I could not reproduce unfortunately. With have you tried to move the emulator window? I think the time should be updated when you starting using the emulator. being said, would it be possible for you to try it again?

Sure, will try

Unfortunately, it happened again. Moving a window did not help.

Some additional info:

• I use a pair of external displays connected via Type-C, Bluetooth keyboard and mouse.
• Power adapter is plugged in. This way I can safely close a macbook lid and continue using it with the external displays. When macbook is sleeping I can wake it up by pressing a key on a keyboard or by clicking a mouse button.
• Today I left my workplace for 40-50 minutes. When I came back, external displays were in standby mode. After waking the macbook up, I've reproduced the issue.

RE#28 I realized what went wrong. My fix didn't merge into the 32 release. It's only available in the 31 release and the dev branch. Let me resolve that issue real quick and release a new version. Thanks for your input!

Thank you!

New CL merged. Will release a new version ASAP.

The fix is available in the next canary and stable release in June.

RE#36 To clarify, the bug is still reproducible for API 29 and API 30. Other APIs are working fine. We have an internal bug for tracking the API specific time update issue.

The new fix is merged

sivhuop@ Hi, the fix is not merge in (33.1.4-9936625). Would it be possible for you to upgrade your emulator the latest canary version or at least 33.3.14? Here is the link to the archived emualtor downloads.

RE#42 Thanks for the feedback on the emulator. To help us troubleshoot this issue further, we will need more information. Please share detailed reproduction steps as much as possible of the following information:

1, Run the emulator from command line with “$ANDROID_SDK_ROOT/emulator/emulator -avd <NameOfAVD> -verbose -wipe-data” and send the logs from terminal

2, Run adb bugreport and send the zip file.

I confirm 34.1.9 has no this issue anymore

https://developer.android.com/studio/releases/emulator#32-1-14