IssueTracker

I was able to reproduce the issue from the dump, with -dontobfuscate and horizontal class merging disabled for easier debugging.

The method is replaced by throw null since R8 cannot find any calls that can possible dispatch to it. I tried disassembling the example.apk you shared. According to example.map, the class ScImageRenderer has been renamed to Fxe. When I lookup the definition of this class in example.apk, it has been made abstract. Presumably, R8 has not found any allocations of the class. This makes me wonder whether the class is only instantiated by reflection and you are missing a -keep rule to specify this?

Stack trace where the method is converted to throw null:

	at com.android.tools.r8.graph.ProgramMethod.convertToThrowNullMethod(ProgramMethod.java:131)
	at com.android.tools.r8.graph.ProgramMethod.convertToAbstractOrThrowNullMethod(ProgramMethod.java:110)
	at com.android.tools.r8.optimize.argumentpropagation.ArgumentPropagatorOptimizationInfoPopulator.setOptimizationInfo(ArgumentPropagatorOptimizationInfoPopulator.java:192)
	at com.android.tools.r8.optimize.argumentpropagation.ArgumentPropagatorOptimizationInfoPopulator.setOptimizationInfo(ArgumentPropagatorOptimizationInfoPopulator.java:172)
	at com.android.tools.r8.optimize.argumentpropagation.ArgumentPropagatorOptimizationInfoPopulator.lambda$setOptimizationInfo$1(ArgumentPropagatorOptimizationInfoPopulator.java:114)
	at com.android.tools.r8.graph.DexProgramClass.lambda$forEachProgramMethodMatching$12(DexProgramClass.java:289)
	at com.android.tools.r8.graph.MethodCollection.lambda$forEachMethodMatching$0(MethodCollection.java:134)
	at com.android.tools.r8.graph.MethodCollectionBacking.lambda$forEachMethod$0(MethodCollectionBacking.java:60)
	at com.android.tools.r8.graph.MethodMapBacking.traverse(MethodMapBacking.java:105)
	at com.android.tools.r8.graph.MethodCollectionBacking.forEachMethod(MethodCollectionBacking.java:57)
	at com.android.tools.r8.graph.MethodCollectionBacking.forEachMethod(MethodCollectionBacking.java:53)
	at com.android.tools.r8.graph.MethodCollection.forEachMethodMatching(MethodCollection.java:131)
	at com.android.tools.r8.graph.DexProgramClass.forEachProgramMethodMatching(DexProgramClass.java:288)
	at com.android.tools.r8.graph.DexProgramClass.forEachProgramMethod(DexProgramClass.java:283)
	at com.android.tools.r8.optimize.argumentpropagation.ArgumentPropagatorOptimizationInfoPopulator.setOptimizationInfo(ArgumentPropagatorOptimizationInfoPopulator.java:114)
	at com.android.tools.r8.optimize.argumentpropagation.ArgumentPropagatorOptimizationInfoPopulator.lambda$setOptimizationInfo$0(ArgumentPropagatorOptimizationInfoPopulator.java:96)

Noted. I'll do some digging to see if in this scenario we are instantiating through reflection.

I saw some code paths which do instantiate the class normally, but they may be effectively dead and the only remaining code path is through reflection. It'd be surprising that we've made it this far with the underlying issue without trouble if that's the case.

I just checked again, and in the APK you shared the Fxe class is instantiated (and not abstract!). I will try to build locally again using 8.6.27 and check if the class is also not abstract then.

I've confirmed that the class ScImageRenderer is not instantiated through reflection. Instead, it's instantiated in ScRenderersFactory

Sorry for the long turnaround, Ben. I expect this should be fixed by https://r8.googlesource.com/r8/+/5b6302ecfe7cda525ee986a95a4e9ae9fdfce7d4 (at least the repro is). I will get this cherry-picked to 8.6 to hopefully unblock you.

Landing in 8.7 is good enough for me. I've been testing that version and no other issue with that.

Tangential question,I saw from lastest commits that you may optimizing r8 runtime latency. Is that the case? Anything we can help test out there

We recently made a couple of build speed improvements to the evaluation of -if rules. This work aimed to improve the handling of rules on the form -if class * extends ... -keepclassmembers class * { <1> *; }, which were found to have a high build speed overhead in the platform (ref). This work should speed up -if rule evaluation in general, but whether it is observable probably depends on whether you have some -if rules that are expensive to evaluate.

As a side project Rico has been working recently on adding support for generating perfetto traces from R8 builds to get more insights into build speed.

You might also be interested to learn that Rico has integrated resource shrinking into R8, for improved conditional tracing from code to resources and resources to code that does not rely on -keep rules. This enables optimizations that cross the code/resource boundary, such as inlining of resource values.

Verified that ScImageRenderer.getName no longer throws with 8.6.31.

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 Ladybug | 2024.2.1 Patch 2
• Android Gradle Plugin 8.7.2

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!