Missing Proguard rule for generated adapter for sealed class?

[mhelder]

After #626, I find myself circling back to #556. Although the PR fixes the malformed generated rules, and these rules cover R8 in compat mode, turning on R8 full mode (which is the default since Gradle 8) still raises an exception:

java.lang.RuntimeException: Unable to start activity ComponentInfo{com.example.app/com.example.app.MainActivity}: java.lang.IllegalArgumentException: Cannot serialize abstract class com.example.app.data.model.Message
	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:4164)
	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:4322)
	at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:103)
	at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:139)
	at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:96)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2685)
	at android.os.Handler.dispatchMessage(Handler.java:106)
	at android.os.Looper.loopOnce(Looper.java:230)
	at android.os.Looper.loop(Looper.java:319)
	at android.app.ActivityThread.main(ActivityThread.java:8919)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:578)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1103)
Caused by: java.lang.IllegalArgumentException: Cannot serialize abstract class com.example.app.data.model.Message
	at com.squareup.moshi.MapJsonAdapter$1.create(SourceFile:36)
	at com.squareup.moshi.Moshi.adapter(SourceFile:7)
	at com.squareup.moshi.Moshi.adapter(SourceFile:1)
	at com.example.app.MainActivity.onCreate(SourceFile:22)
	at android.app.Activity.performCreate(Activity.java:8975)
	at android.app.Activity.performCreate(Activity.java:8944)
	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1456)
	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:4146)
	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:4322) 
	at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:103) 
	at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:139) 
	at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:96) 
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2685) 
	at android.os.Handler.dispatchMessage(Handler.java:106) 
	at android.os.Looper.loopOnce(Looper.java:230) 
	at android.os.Looper.loop(Looper.java:319) 
	at android.app.ActivityThread.main(ActivityThread.java:8919) 
	at java.lang.reflect.Method.invoke(Native Method) 
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:578) 
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1103) 

Based on the strack trace, it seems like Moshi was unable to find the generated MessageJsonAdapter and ended up attempting to use MapJsonAdapter, which obviously doesn't work.

To confirm, I manually registered the MessageJsonAdapter:

class Factory: JsonAdapter.Factory {
    override fun create(type: Type, annotations: Set<out Annotation>, moshi: Moshi): JsonAdapter<*>? {
        return if (type == Message::class.java) MessageJsonAdapter(moshi) else null
    }
}

// usage:
Moshi.Builder()
    .add(MessageJsonAdapter.Factory())
    .build()

This indeed makes the crash goes away.

Looking at the (decompiled) code after minification, I noticed that the Message class itself is stripped of its @JsonClass annotation when R8 full mode is enabled. Since Moshi relies on this annotation to resolve the generated adapter, that would explain why it doesn't find the MessageJsonAdapter.

Because I haven't seen this issue with adapters generated by Moshi itself, I had a quick look there. It seems that Moshi generates an additional rule for every @JsonClass-annotated class:

// Keep the class name for Moshi's reflective lookup based on it
appendLine("-if class $targetName")
appendLine("-keepnames class $targetName")

Adding this rule for the Message sealed class, fixes the exception:

-if class com.example.app.data.model.Message
-keepnames class com.example.app.data.model.Message

Long story short: would you be happy with me opening another small PR to add this rule to moshi-proguard-rule-gen?

[ZacSweers]

We use moshi's proguard rule gen directly in the KSP plugin, I'm surprised that isn't a part of that 🤔. PR welcome but check that first

[mhelder]

It looks like it's behind a flag:

MoshiX/moshi-proguard-rule-gen/src/main/kotlin/dev/zacsweers/moshix/proguardgen/MoshiProguardGenSymbolProcessor.kt

Lines 123 to 125 in 7907c00

	if (enableMoshi) {
	config.writeTo(writer)
	}

So effectively moshi.generateCoreMoshiProguardRules determines whether the -keepnames rule is added or not (by Moshi's Proguard rule gen). According to the accompanying comment this flag "should only be used if using moshi-ir". Why's that?

I feel like I don't have enough context to determine how to proceed. Enabling Moshi's Proguard rule gen is potentially one option. It probably means MoshiProguardGenSymbolProcessor will have less rules to generate, but I would need to look into that a bit better. But we could also replicate the rules Moshi outputs in MoshiX rule gen.

What are your thoughts?