Wrong screen is resumed when popping screens sequentially [177590791]

Fixed

Bug

Status Update

No update yet.

Description

mi...@gmail.com

created issue #1

Jan 15, 2021 03:42AM

Library version used: 1.0.0-beta.1
Devices/Android versions reproduced on: Pixel 5/Android 11, DHU
Android Auto version reproduced on: 5.8.604354-release

Situation

Sample project to trigger the issue: https://github.com/themics/android-auto-screen-stack-bug

Let's say we have a screen stack of [A, B, C]. A is the root, and C is the top.

B is pushed by A for some result via screenManager.pushForResult(). So is C by B.

When C set the result and finish() itself, B also set that result and finish() itself to relay the result to A.

Now we have [A] and A is resumed properly. C and B is destroyed as well.

Problem

B's lifecycle is resumed again.

Log

(open an app)
12:35:00.566 I/AScreen: state: ON_CREATE
12:35:00.577 I/AScreen: state: ON_START
12:35:00.579 I/AScreen: state: ON_RESUME

(push B)
12:35:02.325 I/BScreen: state: ON_CREATE
12:35:02.326 I/BScreen: state: ON_START
12:35:02.326 I/AScreen: state: ON_PAUSE
12:35:02.327 I/AScreen: state: ON_STOP
12:35:02.327 I/BScreen: state: ON_RESUME

(push C)
12:35:03.521 I/CScreen: state: ON_CREATE
12:35:03.522 I/CScreen: state: ON_START
12:35:03.522 I/BScreen: state: ON_PAUSE
12:35:03.522 I/BScreen: state: ON_STOP
12:35:03.522 I/CScreen: state: ON_RESUME

(pop C & B)
12:35:04.441 I/BScreen: state: ON_START
12:35:04.442 I/CScreen: state: ON_PAUSE
12:35:04.442 I/CScreen: state: ON_STOP
12:35:04.442 I/AScreen: state: ON_START
12:35:04.442 I/BScreen: state: ON_STOP
12:35:04.443 I/BScreen: state: ON_DESTROY
12:35:04.443 I/AScreen: state: ON_RESUME
12:35:04.444 I/CScreen: state: ON_DESTROY
12:35:04.444 I/BScreen: state: ON_CREATE   <- problem
12:35:04.444 I/BScreen: state: ON_START    <- problem
12:35:04.444 I/BScreen: state: ON_RESUME   <- problem

Comments

jo...@google.com <jo...@google.com> #2Jan 20, 2021 07:29PM

Assigned to li...@google.com.

Thank you for the detailed report.

li...@google.com <li...@google.com> #3Jan 25, 2021 10:20PM

I found the issue. There is a bug where if you have nested screens pushed for result (as you do A pushing B and B pushing C), and you call finish inside of B's onScreenResultCallback, this causes the bug you see above.

We will be making a fix and rolling it out in an update of the library.

In the meantime, if you need to do this, you can get around the issue by calling ScreenManager#popTo(String) with a marker to Screen A.

jo...@google.com <jo...@google.com> #4Feb 2, 2021 05:27PM

The fix will be in the Jetpack version of the library, in the meantime, please use the workaround described in #3.

sh...@google.com <sh...@google.com> Feb 11, 2021 05:31PM

Marked as fixed.

ag...@gmail.com <ag...@gmail.com> #5Mar 4, 2021 06:17PM

Try reviewing the sequence in a group, from opening of an app Ascreen states ON_CREATE then ends in ON_RESUME.
Second group is (push b), Bscreen states ON_CREATE in first and close or ends states Bscreen ON_RESUME.
Third one states Cscreen in ON_CREATE also ends states with ON_RESUME.
So in (push c & b) states first at Bscreen in ON_CREATE, then it will states in ON_RESUME, even they are state in a middle part was ON_DESTROY, it will back in a ON_RESUME state at END of the bug.
Therefore, a rotation of sequence in a bug was sequentially.
Hope this help... 😇