Android应用与第三方依赖同一库版本冲突及多版本使用方案问询

首先可以明确：存在可行方案实现同一依赖库的两个版本在项目中独立运行，核心逻辑是通过*包名重定向（字节码修改）*隔离不同版本的类加载路径，避免全类名冲突导致的覆盖问题。

具体实现方案 #

• 方案1：手动重打包隔离高版本依赖

  1. 先提取第三方依赖内置的5.0.0版本目标库的AAR/JAR包
  2. 使用jarjar工具对该5.0.0版本库的包名做批量重命名，例如将原包名com.xxx.targetlib修改为com.xxx.targetlib.v5
  3. 在项目的Gradle依赖配置中，给第三方依赖添加排除规则，屏蔽其内部的目标库传递依赖，同时引入你需要的4.0.0版本和重打包后的5.0.0版本，配置示例如下：

  dependencies {
      // 项目代码直接使用的4.0.0版本
      implementation 'com.xxx.targetlib:lib:4.0.0'
      // 引入第三方依赖，排除内部自带的目标库
      implementation ('com.xxx.thirdpart:lib:2.1.0') {
          exclude group: 'com.xxx.targetlib', module: 'lib'
      }
      // 引入重打包后的5.0.0版本供第三方依赖调用
      implementation files('libs/targetlib-v5-repackaged.aar')
  }
  

  4. 如果第三方依赖内部硬编码了原目标库的类全路径、资源ID，需要同步修改第三方依赖的字节码对应引用，适配重命名后的包名。

• 方案2：Gradle插件自动处理
  可以使用shadow等重打包插件，在构建阶段自动完成指定依赖的包名重定向、引用修改操作，不需要手动处理字节码，适合依赖逻辑复杂度较高的场景。

注意事项 #

• 如果目标库包含Native SO文件，需要同时修改重打包版本的SO库命名和加载逻辑，避免同名SO文件覆盖冲突
• 如果目标库包含自定义View、四大组件、ContentProvider等需要在AndroidManifest中注册的组件，需要同步修改重打包版本的组件注册名称，避免清单文件合并冲突
• 重打包后的版本无法直接接收原库的官方更新，后续如果要升级5.0.0版本需要重新执行重打包流程

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