Inconsistent start request codes after restoring [157584993]

Infeasible

Bug

NeedsInfo

Status Update

No update yet.

Description

an...@gmail.com

created issue #1

May 28, 2020 01:38PM

Problem description

There's the ClassCastException on Firebase from users after upgrading androidx.activity to 1.2.0-alpha05:

Fatal Exception: java.lang.ClassCastException: androidx.collection.ArrayMap cannot be cast to androidx.activity.result.ActivityResult
       at androidx.fragment.app.FragmentManager$9.onActivityResult(FragmentManager.java:2779)
       at androidx.activity.result.ActivityResultRegistry.dispatchResult(ActivityResultRegistry.java:304)
       at androidx.activity.ComponentActivity$2$1.run(ComponentActivity.java:151)
       ... the rest are just stacktrace from handler

After checking the source code, that might because of the change:

https://android-review.googlesource.com/c/platform/frameworks/support/+/1302324

The default start number of the request code is changed to 0xffff, but in onRestoreInstanceState the value will be reset to the key map size:

https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/activity/activity/src/main/java/androidx/activity/result/ActivityResultRegistry.java#263

It's used to be correct since the the change, the default request code start from 0.

Possible solution

Rewrite to use 0xffff+numKeys as the start number of the request code on restoring: https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/activity/activity/src/main/java/androidx/activity/result/ActivityResultRegistry.java#263

Comments

vi...@google.com <vi...@google.com> May 29, 2020 04:52AM

Assigned to vi...@google.com.

vi...@google.com <vi...@google.com> #2May 29, 2020 01:00PM

Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:

Device used -- Device Make, Model, Android OS Version
Which device did you use to reproduce this issue?

Please provide sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.

Expected output
What is the expected output?

Current output
What is the current output?

Android bug report (to be captured after reproducing the issue)
For steps to capture a bug report, please refer:

https://developer.android.com/studio/debug/bug-report#bugreportdevice

Alternate method
Navigate to “Developer options”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”. Capture bug report by holding the power button and selecting the “Take bug report” option.

Screen Record of the Issue
Please capture screen record or video of the issue using following steps:
adb shell screenrecord /sdcard/video.mp4
Subsequently use following command to pull the recorded file:
adb pull /sdcard/video.mp4
Attach the file to this issue.

Note: Please upload the bug report and screenshot to google drive and share the folder to android-bugreport@google.com, then share the link here.

vi...@google.com <vi...@google.com> #3Jun 5, 2020 06:11PM

Please provide the information as requested in

comment #2

, for us to further investigate this issue.

pp...@gmail.com <pp...@gmail.com> #4Jun 6, 2020 05:13PM

Hi, sorry for the delay. The stack I've posted merely came from the log on the Firebase, and unfortunately we also can't reproduce it. So I can't give the specific steps to reproduce the bug. But I can say it only occur on Android 7+.

We did try to injector the possible solution into the library source and seemed to solve it successfully, which only take within 2 steps on our side:

Prepare the function for reseting the mNextRc in the project.
Use Transform API to inject code at the end of onRestoreInstanceState() to call the function .

The function is:

fun afterOnRestoreInstanceState(rcSet: Set<Int>, nextRc: AtomicInteger) {
    // 0xffff is the default value of mNextRc
    val rc = (rcSet.max() ?: 0xffff) + 1    
    nextRc.set(rc)
}

Hope this would help, Thanks.

vi...@google.com <vi...@google.com> #5Jun 8, 2020 06:46PM

As the issue seems to have been solved. Can we close this issue?

an...@gmail.com <an...@gmail.com> #6Jun 9, 2020 02:38AM

Yeah, sure :). Thanks for your help

vi...@google.com <vi...@google.com> #7Jun 18, 2020 03:18PM

Status: Won't Fix (Infeasible)

Closing this issue as per

comment #6