Android Gradle:Windows下原生SO库名称大小写冲突解决方案咨询
解决方案:Windows环境下适配大小写冲突的SO库(开发阶段)
针对你遇到的Windows大小写不敏感导致两个SO库互相覆盖的问题,结合开发阶段仅需保留最新mylibname.so的需求,提供以下几个实用方案:
方案1:构建脚本自动清理旧SO(推荐)
在模块的构建脚本中添加前置任务,编译前自动删除旧版本的MyLibName.so,从根源避免Windows上的覆盖问题。
Groovy 版本(build.gradle)
tasks.whenTaskAdded { task -> // 匹配合并JNI库的任务 if (task.name.startsWith('merge') && task.name.endsWith('JniLibs')) { task.doFirst { // 删除本地目录中的旧SO fileTree(dir: 'src/main/jniLibs', include: '**/MyLibName.so').each { file -> file.delete() } // 如果旧SO来自远程依赖,排除其JNI库 configurations.all { config -> config.resolutionStrategy.eachDependency { details -> if (details.requested.name == '旧库的模块名') { details.useTarget(group: details.requested.group, name: details.requested.name, version: details.requested.version) { exclude module: 'jniLibs' } } } } } } }
Kotlin DSL 版本(build.gradle.kts)
tasks.whenTaskAdded { if (name.startsWith("merge") && name.endsWith("JniLibs")) { doFirst { // 删除本地旧SO fileTree("src/main/jniLibs") { include("**/MyLibName.so") }.forEach { it.delete() } // 排除远程旧库的JNI依赖 configurations.all { resolutionStrategy.eachDependency { if (requested.name == "旧库的模块名") { useTarget(group = requested.group, name = requested.name, version = requested.version) { exclude(module = "jniLibs") } } } } } } }
发布前只需注释或删除这段脚本,再移除旧库依赖即可。
方案2:手动重命名旧SO并修改加载逻辑
如果旧库是本地引入的,直接将MyLibName.so重命名为MyLibName_old.so,同时修改旧库代码中加载SO的语句:
将旧库中的System.loadLibrary("MyLibName")改为System.loadLibrary("MyLibName_old"),这样两个SO文件名完全不同,Windows不会覆盖。
若旧库是远程依赖,可先下载到本地修改后作为本地库引入,适合临时开发场景。
方案3:用构建变体隔离环境
创建dev(开发)和release(发布)两个构建变体,开发时用dev变体仅引入新版本库,发布前切换到release变体调整依赖:
Groovy 版本示例
android { flavorDimensions "environment" productFlavors { dev { dimension "environment" implementation 'com.example:新版本库:1.0.0' } release { dimension "environment" // 发布前按需配置依赖,移除旧库 implementation 'com.example:新版本库:1.0.0' // implementation 'com.example:旧版本库:0.9.0' } } }
内容的提问来源于stack exchange,提问作者Vetalll
相关产品推荐
相关产品推荐

