IssueTracker

I just tested with 8.1.36-dev and 8.2.0-dev and the issue is still present.

Can you share a reproduction of this, if possible a compiler dump, see https://r8.googlesource.com/r8/+/refs/heads/main/doc/compilerdump.md

If not publicly, then with ricow@google.com and christofferqa@google.com

I can't share a repro, and the full dump contains a lot of proprietary info. Is there a subset of the dump I can share that would be helpful?

Can you share the resulting apk and then the androidx.profileinstaller.ProfileInstallerInitializer$Choreographer16Impl class file from the dump (it should be in the program.jar inside the dump)

I've attached a zip with those files in a restricted comment.

I can't repro the verification error with the attached apk, how do I repro, and what version of android did you repro on (dex2oat will fully compile this without issues on 6 and 12)

I can repro on 8, 11, and 13. It crashes as soon as the app is opened.

I get instead:

04-18 14:28:37.071 10648 10648 E AndroidRuntime: java.lang.VerifyError: Verifier rejected class cm3: void cm3.a() failed to verify: void cm3.a(): [0x11] 'this' argument 'Reference: java.lang.Object' not instance of 'Reference: android.content.Intent' (declaration of 'cm3' appears in /data/app/~~TahAr3SAlXyYMWqtCcVJdQ==/co.twenty.stop.spread.dev-BEXOTcDwQQRwcFf-P0JT0w==/base.apk)

Can you retrace that name and get me the corresponding class for cm3 and DV0 - if possible, share the mappingfile so that we can see the original signatures when looking into this.

Oh I'm sorry, I was using the wrong mapping file. I'll get you that information shortly.

If you don't want to share it on this bug feel free to mail it to ricow@google.com and christofferqa@google.com

The code for ProcessRestarterImpl has a very strange pattern, probably from your dependency injection, where it will generate an array of type android/content/Intent

It will then call the Function0, which returns an Object, and store that into the array, which we pass on to call into ProcessPhoenix. This will actually type check, even when the types don't match, since you are allowed to put anything into the array (if the type is wrong, it would fail at runtime though when using the value)

R8 will inline the call to 'Lcom/jakewharton/processphoenix/ProcessPhoenix;triggerRebirth(Landroid/content/Context;[Landroid/content/Intent;)V', and since we track that only a single element was in the array it will simply reuse the value already in that register (i.e., not load from the array and check, simply use the 'java/lang/Object' value)

In this case, we should not do the elimination of the array load, since we can't guarantee the type