Gradle/AGP升级后R8混淆致Retrofit与DemoApi类型转换异常

问题背景 #

我们有一个带有多继承关系的Retrofit接口，示例代码如下：

interface ApiInterface : AuthMobileApiInterface, DashboardApiInterface {

    ...

    @GET("rest/user/context")
    fun getUserContext(): Call<UserContext>

    ...

}

其中AuthMobileApiInterface和DashboardApiInterface同样包含带Retrofit注解的方法。此外，我们还有一个仅用于演示模式的DemoApi类，它实现了ApiInterface。

在将AGP从7.4.2升级到8.3.2、Gradle从7.5升级到8.4、Java从11升级到17后，出现了ClassCastException异常：

retrofit2.DefaultCallAdapterFactory$ExecutorCallbackCall cannot be cast to DemoApi.getUserContext.Call

该异常本身逻辑成立：ExecutorCallbackCall实现了Retrofit的Call接口，但DemoApi提供了自定义的Call实现。

反常的是，在开启混淆的Release构建中，所有使用ApiInterface的地方都被替换为DemoApi实例，而非retrofit.create()创建的服务实例。我们通过给所有相关接口添加@Keep注解解决了问题，现希望理解R8与Retrofit的相关机制，有以下疑问：

• 这是Retrofit的Bug吗？
• 我们是否遗漏了Retrofit文档中的相关内容？
• 为所有接口添加@Keep注解是合理解决方案，还是我们的配置存在问题？

补充信息：将Retrofit从2.9.0升级到2.11.0后异常未改变；当前环境：Gradle 8.4、AGP 8.33.2、Retrofit 2.11.0，android.enableR8.fullMode=false，开启混淆与资源压缩，关闭混淆可正常运行。

问题解答 #

1. 这是Retrofit的Bug吗？ #

不是Retrofit的Bug，问题根源在于R8的混淆优化逻辑。

当R8处理带有多继承的接口时，可能错误地认为DemoApi是ApiInterface的唯一实现（尤其是混淆后类名被修改，R8的数据流分析出现偏差），进而将所有对ApiInterface的使用替换为DemoApi实例——这属于R8的类型合并/实现替换优化误触发。Retrofit通过动态代理生成的实例在混淆后被R8误判为可被DemoApi替代，最终导致类型转换异常。

2. 是否遗漏了Retrofit文档中的相关内容？ #

Retrofit官方文档确实提到，需要确保Retrofit接口不被混淆，因为动态代理依赖接口的完整签名（包括注解、方法签名）。不过针对多继承接口+自定义实现类的场景，文档没有专门强调，但这属于R8混淆配置的通用注意事项：当一个接口同时存在动态代理实现（Retrofit生成）和静态实现（DemoApi）时，必须明确告知R8不要对该接口进行实现替换优化。

3. 添加@Keep注解是合理解决方案吗？ #

这是合理的解决方案，同时也有更精准的配置方式：

• @Keep注解方案：直接标记所有相关接口（ApiInterface、AuthMobileApiInterface、DashboardApiInterface），能彻底阻止R8对这些接口的混淆、合并等优化，确保Retrofit动态代理和DemoApi的实现都能正常工作，适合快速解决问题。
• 精准ProGuard/R8规则：如果不想使用@Keep，可以在混淆规则文件中添加以下配置：

  -keep interface com.yourpackage.ApiInterface
  -keep interface com.yourpackage.AuthMobileApiInterface
  -keep interface com.yourpackage.DashboardApiInterface
  -keepclassmembers interface com.yourpackage.*ApiInterface {
      @retrofit2.http.* <methods>;
  }
  

  该配置既保留了接口的方法签名和Retrofit注解，又不会完全禁止其他无关优化，比全局@Keep更精细。

需要注意：即使android.enableR8.fullMode=false，R8在处理多继承接口时依然可能触发这类优化，因为默认混淆规则未针对“同一接口存在动态代理+静态实现”的场景做特殊处理。

内容的提问来源于stack exchange，提问作者Aaron