Fragments inflated after the Activity is RESUMED never get resumed [180538371]

Fixed

Bug

Status Update

No update yet.

Description

jb...@google.com

created issue #1

Feb 17, 2021 10:57PM

When using the new fragment state manager, if a fragment is inflated after the host activity is RESUMED, via either the deprecated <fragment> tag or FragmentContainerView, the fragment never makes it to a RESUMED state.

In the case of the <fragment> tag:

the fragment is moved to VIEW_CREATED and never makes it any further

for FragmentContainerView:

the fragment correctly moves to RESUMED the first time, but on configuration change, the view that inflates the fragment is never attached to the new view hierarchy, so the fragment is RESUMED but never actually visible.

We should address this issue for both components. aosp/1591056 and aosp/1593053 have been implemented for the <fragment> tag case. This bug will track the FragmentContainerView case.

Comments

ap...@google.com <ap...@google.com> #2Feb 18, 2021 11:42PM

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).

ap...@google.com <ap...@google.com> #3Feb 22, 2021 05:33PM

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().

jb...@google.com <jb...@google.com> #4Feb 22, 2021 10:16PM

Marked as fixed.

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).

ad...@gmail.com <ad...@gmail.com> #5May 4, 2021 11:50AM

@ #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.

ma...@gmail.com <ma...@gmail.com> #6Oct 4, 2022 08:21PM

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.

Issue 180538371