Android项目集成多版本Lottie出现依赖冲突导致文件无法渲染

方案1：优先保留主项目3.6.1版本Lottie #

Lottie官方对低版本API的兼容性优化比较完善，绝大多数2.7.0版本的公开API在3.6.1版本中都做了保留。你可以先直接运行项目，同时测试两个核心场景：

• 主项目原有Lottie动画的渲染是否正常
• 活体检测SDK的全流程功能是否正常运行，是否出现NoSuchMethodError、ClassNotFoundException等类找不到异常、或是SDK内部的Lottie动画渲染异常

如果两个场景都无问题，不需要做任何额外调整，当前Gradle默认的版本仲裁规则已经自动用更高的3.6.1版本覆盖了SDK依赖的2.7.0版本，可直接使用。

方案2：排除SDK内部的Lottie依赖做针对性适配 #

如果方案1测试发现SDK功能异常，你可以在引入第三方SDK时，主动排除它内部依赖的Lottie包，再做适配：

1. 修改app模块build.gradle的依赖配置：

implementation ('cl.toc.LivenessAndroid:sdk:1.12.1') {
    exclude group: 'com.airbnb.android', module: 'lottie'
}

2. 排查2.7.0到3.6.1版本之间Lottie修改/废弃的API，若SDK是开源的可直接修改SDK内部的Lottie调用逻辑适配3.6.1版本；若SDK是闭源的，可通过反射、动态代理的方式兼容异常API调用。

方案3：依赖隔离实现双版本共存（终极方案） #

如果出现主项目动画必须用3.6.1才能渲染、同时SDK只能运行在2.7.0版本Lottie下的双向不兼容场景，可通过Shadow插件做依赖包名重定向，让两个版本Lottie同时存在不冲突：

• 新建独立的Android Library模块，仅引入cl.toc.LivenessAndroid:sdk:1.12.1依赖
• 配置Shadow插件的打包规则，将SDK依赖的com.airbnb.android:lottie包名重命名为自定义包名（比如custom.lottie.v270）
• 主项目依赖你重新打包后的Library模块即可，两个版本Lottie的类路径完全隔离，不会互相影响

注意：无论选择哪种方案，都需要完整测试主项目原有功能、第三方SDK全流程功能的稳定性，避免出现隐藏异常

内容的提问来源于stack exchange，提问作者Diez de Ulzurrun Rafael Emmanu