IssueTracker

Thanks for reporting this on the issue tracker.

Note that the two constructors that you are comparing are likely not the same constructor from the original app. Indeed, the one in good smali.png is assigning the parameters to the instance fields, but the one in bad smali.png is creating an instance of org.jsoup.parser.d and assigning it to an instance field.

This is most likely explained by R8 merging a class from org.jsoup.parser with your class PickupStepViewHelper_Factory.

In order to diagnose this issue, it would be great if you could generate a zip dump of the inputs to R8 by running the below command (on the revision of the app that has the bug).

./gradlew assembleRelease --no-daemon -Dcom.android.tools.r8.dumpinputtodirectory=/path/to/dumps

This contains the class files, keep rules, etc. from the app and should allow us to reproduce the build.

It would be great if you could also share the resulting APK so that we can reproduce the stack trace and try to understand what might be causing this.

You can share this privately with christofferqa@google.com and sgjesse@google.com.

Hi thanks for your reply. I will be happy to generate this for you and send it over.

FYI, though, I am not able to reproduce the problem again even rebuilding the same code in the same conditions. I will share everything today. Thanks

Hi, files have been shared with the above emails. We were finally able to reproduce the issue with an old Gradle cache so hopefully you are able to see the issue with the shared files.

One detail I forgot to share if relevant at all, but I doubt. the build was generated with the new experimental dex layout optimization:

experimentalProperties["android.experimental.r8.dex-startup-optimization"] = true

Thanks for sharing the relevant artifacts.

I was unable to reproduce the issue from launching the APK from the rebuild-old-cache-broken! directory. Would it be possible for you to share the steps needed to reproduce the crash on a device?

I also tried building the dump (dump841321845439500.zip) in the same folder to validate if I got the same DEX files out of this as in the above APK. Building this dump artifact leads to 6 DEX files (excluding the desugared library DEX file), but the broken APK has 9 DEX files (including the desugared library DEX file).

I then checked the compilation marker of the APK, which reveals that the APK is apparently built using D8 version 2.1.7-r1 (??), but the dump shows that you are using R8 version 8.2.33 for shrinking.

(Note that when you run D8 on the DEX generated by R8 you ruin the DEX startup optimization).

Another strange thing is that the desugared library file in your APK is classes3.dex instead of classes9.dex.

Could you maybe shed some light on what is happening here?

Thanks for the detailed report.

About the dex number question I think I reproduced the problem which can explain also the weird D8 version problem:

we use a analytic tool called FullStory: they use a gradle plugin that instrument the code after is dexed/minified. Running the broken build without this tool, produced an APK with 6 dexes, and the smali in the apk looks correct.

I've uploaded the apk and the dumps inside the build-without-fullstory folder in the shared Google Drive, if there is anything you want to look at, but I believe we can close this issue. I will report all the findings to them.

Thanks!

Thanks for the update! Please don't hesitate to reopen this issue if you believe this is not caused by the FullStory instrumentation.

You may also want to make sure that FullStore uses a newer version of D8 and inform them that the tool is potentially breaking the dex startup optimization.

Hi, sadly I think we need to reopen this issue. Today we got hit by this problem again. Fullstory has been disabled for about a couple of weeks now.

I am uploading a new set of files in the same Drive folder I have shared previously, in a zip file "new crash report.zip":

• broken build CI folder contains the original apk and mapping built from our CI we ended up shipping to production, including the de-obfuscated stacktrace
• working local build folder contains a local working rebuild of a different commit (but where the breaking code was not changed) together with the R8 dumps, apk, and mapping
• broken build local - with baselines folder contains the data for the build from the same commit that we shipped to production. it contains R8 dumps, apk, mapping and obfuscated stacktrace.
• broken build local - no baseline same as above, but without baseline and startup layout optimization.
• smali broken build where I highlight the point where the stacktrace throws the exception
• smali working build the smali from the working build where the code looks correct

additional notes: I could repro the crash constantly from a given commit but not from a different commit that had nothing to do with the breaking code. not sure whats going on but I cant find any way to find the problem on our side at this moment.

This should be fixed in R8 version 8.2.39. You can build with this version by making the following changes to settings.gradle.

pluginManagement {
    buildscript {
        repositories {
            mavenCentral()
            maven {
                url = uri("https://storage.googleapis.com/r8-releases/raw")
            }
        }
        dependencies {
            classpath("com.android.tools:r8:8.2.39")
        }
    }
}

Remember to remove this again when AGP bundles a newer version of R8 than this (e.g., AGP 8.2.1, AGP 8.3.0).

thanks! updated locally and I will let you know if anything happens. thanks for your time. FYI 8.2.39 is not available in the tags list here https://r8.googlesource.com/r8/+refs

Tag for 8.2.39 pushed as well.

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Hedgehog | 2023.1.1 Patch 1
• Android Gradle Plugin 8.2.1

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

Comment added by automation: A postmortem has been automatically requested for this issue. Please author a postmortem on IRM. See go/android-postmortem-guidance for more context and details, including how to handle the case when this issue does not need a postmortem. If you have any questions not answered by go/android-postmortem-guidance, please email android-hygiene-tpm@, instead of reassigning the fixed bug. Thank you.