IssueTracker

Component used: Fragment

Version used: 1.2.4, 1.3.0-beta01

Devices/Android versions reproduced on: Pixel 4XL

Hello, my app currently uses Fragment 1.2.4, which we have been using to replace "top-level" Fragments in the app within a single Activity. When we do a replace FragmentTransaction from FirstFragment to SecondFragment, this is the order of events we observe:

FirstFragment	onStart()
FirstFragment	onResume()
FirstFragment	onPause()
FirstFragment	onStop()
SecondFragment	onStart()
SecondFragment	onResume()

The behavior we have implicitly been depending on is that the previous fragment has been paused, before the next Fragment has been resumed.

However when trying out the AndroidX Navigation library, which always sets setReorderingAllowed(true), we observe a different ordering. Even though we are just executing a single standard replace operation.

FirstFragment	onStart()
FirstFragment	onResume()
SecondFragment	onStart()
SecondFragment	onResume()
FirstFragment	onPause()
FirstFragment	onStop()

In this case, both FirstFragment and SecondFragment are briefly in the resumed state at the same time, which was an unexpected change for us. I have been testing the 1.3.0-beta01 release, and noticed that this behavior changes yet again, depending on if the new fragment store manager is enabled. Here are my findings:

1.2.4, allow-reordering = false

FirstFragment	onStart()
FirstFragment	onResume()
FirstFragment	onPause()
FirstFragment	onStop()
SecondFragment	onStart()
SecondFragment	onResume()

1.2.4, allow-reordering = true (UNEXPECTED)

FirstFragment	onStart()
FirstFragment	onResume()
SecondFragment	onStart()
SecondFragment	onResume()
FirstFragment	onPause()
FirstFragment	onStop()

1.3.0-beta01: enableNewStateManager = false, allow-reordering = false

FirstFragment	onStart()
FirstFragment	onResume()
FirstFragment	onPause()
FirstFragment	onStop()
SecondFragment	onStart()
SecondFragment	onResume()

1.3.0-beta01: enableNewStateManager = false, allow-reordering = true (UNEXPECTED)

FirstFragment	onStart()
FirstFragment	onResume()
SecondFragment	onStart()
SecondFragment	onResume()
FirstFragment	onPause()
FirstFragment	onStop()

1.3.0-beta01: enableNewStateManager = true, allow-reordering = false

FirstFragment	onStart()
FirstFragment	onResume()
FirstFragment	onPause()
FirstFragment	onStop()
SecondFragment	onStart()
SecondFragment	onResume()

1.3.0-beta01: enableNewStateManager = true, allow-reordering = true

FirstFragment	onStart()
FirstFragment	onResume()
FirstFragment	onPause()
FirstFragment	onStop()
SecondFragment	onStart()
SecondFragment	onResume()

Note: All of these were determined by adding a log in the overridden method, just before the super call in both Fragments.

My questions are:

1. What is the intentional order of lifecycle events for a standard replace transaction, and should we expect it to be different when the setReorderingAllowed flag is enabled?

2. Can we reliably depend on the order of these lifecycle events going forward, or is this seen as an implementation detail that application code should never depend on.