前一篇里就说到了，要给至少一年前就没动过代码的 IG 解决个问题，问题解决完发现打包时候出现了新问题，有一个 so 文件，被检测出有两个来源，发生冲突需要解决。
在工程中寻找该 so 究竟是由谁带来，手动翻找比较费劲，找到这样一段代码，
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
tasks.configureEach { task -> if (task.name == 'mergeInternalDebugNativeLibs') { // 如果是有多个 flavor，则用 mergeFlavorDebugNativeLibs 的形式 task.doFirst { println("------------------- find so files start -------------------") it.inputs.files.each { file -> printDir(new File(file.absolutePath)) } println("------------------- find so files end -------------------") } } } def printDir(File file) { if (file != null) { if (file.isDirectory()) { file.listFiles().each { printDir(it) } } else if (file.absolutePath.endsWith(".so")) { println "find so file: $file.absolutePath" } } } |
但是，把找出的对应的依赖注释掉，问题照样还在。这个情况挺奇怪的，因为即便是两者有冲突，现在去掉一方也是应该可以解决的，然而打包阶段仍然会固执地把注释掉的依赖纳入其工作范畴。另一个位置的同名 so 也显示出来了，但是不知道来源。找来找去，找到这么一个办法，向构建脚本中增加这样的语句，
|
1 2 3 |
packagingOptions { pickFirst '**/libtnet-3.1.14.so' } |
确实有效。可是直觉不太保险啊，毕竟是盲选第一个遇上的。要是版本不一样，需要指定，那岂不抓瞎。
这个问题真正解决，是因为另一位小伙伴在另一个工程里做相同的依赖变更时处理掉了。那个不明出处的 so，其实就在工程中某个 jniLib 目录下。当时老夫急吼吼寻找常规的联机依赖源，没想到它潜伏在本地。灯下黑了属于是。把本地的文件删除，再把上面的 pick 操作也删除，构建果然顺利完成。
这过程中的两个小知识点，就留在这儿，说不定哪天还能用上。