Status Update
Comments
lu...@google.com <lu...@google.com> #2
I just tested with 8.1.36-dev and 8.2.0-dev and the issue is still present.
lu...@google.com <lu...@google.com> #4
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?
sh...@adobe.com <sh...@adobe.com> #5
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)
am...@zee.com <am...@zee.com> #6
na...@gtempaccount.com <na...@gtempaccount.com> #7
I've attached a zip with those files in a restricted comment.
lu...@google.com <lu...@google.com> #8
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)
sh...@adobe.com <sh...@adobe.com> #9
I can repro on 8, 11, and 13. It crashes as soon as the app is opened.
ab...@gmail.com <ab...@gmail.com> #10
ju...@gmail.com <ju...@gmail.com> #11
Oh I'm sorry, I was using the wrong mapping file. I'll get you that information shortly.
ki...@gmail.com <ki...@gmail.com> #12
If you don't want to share it on this bug feel free to mail it to
lu...@google.com <lu...@google.com> #13
dh...@gmail.com <dh...@gmail.com> #14
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
Description
To reproduce:
Sample Runtime exception:
The issue is present both the old and new resource shrinkers. So this issue doesn't appear to be related to b/237783271 as that particular issue isn't present in the old resource shrinker.
The resource that is being reported as
android.content.res.Resources$NotFoundException
exists within the APK's resource table and as a file, however the contents are shrunk (empty tag xml file). In the repro case the drawable resource is declared and by an app compat library called by the MainActivity in the app (base module).