如何排除重复Ç共享库(.so)在多项目的Android构建?
我建立一个父项目有两个库模块,它利用相同的的libc时收到重复文件冲突++ _ shared.so
共享库。
I get a "duplicate files" conflict when building a parent project with two library modules, which make use of the same libc++_shared.so
shared library.
(注意:请不要认为这是一个重复的问题:我已看过一些相关的帖子,这帮助我走到这一步然而,没有职位提供,在工作的一个答案。我的情况,涉及的 NDK的文物的。)
(NOTE: Please do not consider this a "duplicate question". I have read several related posts, which have helped me get this far. However, no posts have provided an answer that works in my case involving NDK artifacts.)
构建正确地工作时,我只用了1这样的库模块。加入第二库模块的现在创建冲突
The build was working correctly when I only had 1 such library module. The addition of the second library module is now creating the conflict.
考虑以下项目结构:1父项目,2个子工程 - 但每个项目都位于相同的目录级别(即不分层嵌套)
Consider the following project structure: 1 parent project, 2 "child" projects - but each project is located at the same directory level (i.e. Not nested hierarchically)
ProjectA/ (Parent)
LibraryModuleA1/
build/exploded-aar/com.package.name/
LibraryModuleB1/<version>/jni/armeabi-v7a/libc++_shared.so
LibraryModuleC1/<version>/jni/armeabi-v7a/libc++_shared.so
build.gradle (bgA1)
Test_APK_Module A1T/
build.gradle (bgA1T)
build.gradle (bgPA)
ProjectB/
LibraryModuleB1/ (Uses NDK)
build/lib/armeabi-v7a/libc++_shared.so
build.gradle (bgB1)
build.gradle (bgPB)
ProjectC/
LibraryModuleC1/ (Uses NDK)
build/lib/armeabi-v7a/libc++_shared.so
build.gradle (bgC1)
build.gradle (bgPC)
库模块A1取决于双方库模块B1和放大器; C1。
A1 - > B1
A1 - > C1
Library Module A1 depends on both Library Modules B1 & C1.
A1 -> B1
A1 -> C1
项目B和C都具有NDK为基础code和构建/测试正常。双方取决于的libc ++ _ shared.so
共享库。
Projects B and C both have NDK-based code and build/test correctly. Both depend on the libc++_shared.so
shared library.
然而,建设项目A的时候,我得到了在以下错误:LibraryModuleA1:packageDebugTest
任务:
However, when building Project A, I get the following error during the :LibraryModuleA1:packageDebugTest
task:
Error: duplicate files during packaging of APK /ProjectA/LibraryModuleA1/build/apk/LibraryModuleA1-debug-test-unaligned.apk
Path in archive: lib/armeabi-v7a/libc++_shared.so
Origin 1: /ProjectA/LibraryModuleA1/build/exploded-aar/com.package.name/LibraryModuleB1/<version>/jni/armeabi-v7a/libc++_shared.so
Origin 2: /ProjectA/LibraryModuleA1/build/exploded-aar/com.package.name/LibraryModuleC1/<version>/jni/armeabi-v7a/libc++_shared.so
You can ignore those files in your build.gradle:
android {
packagingOptions {
exclude 'lib/armeabi-v7a/libc++_shared.so'
}
}
* What went wrong:
Execution failed for task ':LibraryModuleA1:packageDebugTest'.
> Duplicate files copied in APK lib/armeabi-v7a/libc++_shared.so
File 1: /ProjectA/LibraryModuleA1/build/exploded-aar/com.package.name/LibraryModuleC1/<version>/jni/armeabi-v7a/libc++_shared.so
File 2: /ProjectA/LibraryModuleA1/build/exploded-aar/com.package.name/LibraryModuleC1/<version>/jni/armeabi-v7a/libc++_shared.so
:LibraryModuleA1:packageDebugTest FAILED
我已经试过到目前为止
- 我试图建议关闭添加到我的
build.gradle
文件,但build.gradle
文件做我把它添加到?我已经加入了封闭bgA1
,bgB1
和bgC1
(一次一个),但没有成功。 - 建议的闭合表示使用
排除'的lib / armeabi-V7A /的libc ++ _ shared.so
。每个孩子库模块构建的libc ++ _ shared.so
文件中的建立/ lib目录
路径下。然而,我注意到,母库模块复制的libc ++ _ shared.so
文件下的JNI / armeabi-V7A /的libc ++ _ shared.so
的建设/爆炸-AAR
目录结构中。 (见上文)应该关闭,而不是读排除JNI / armeabi-V7A /的libc ++ _ shared.so
(即JNI
与LIB
)? - 由于我使用的摇篮插件0.9.1,我尝试使用
PICKFIRST
代替的排除
,但不成功无论是。
- I attempted to add the suggested closure to my
build.gradle
file, but whichbuild.gradle
file do I add it to? I have added the closure tobgA1
,bgB1
, andbgC1
(one at a time), with no success. - The suggested closure says to use
exclude 'lib/armeabi-v7a/libc++_shared.so'
. Each "child" library module builds thelibc++_shared.so
file under thebuild/lib
path. However, I noticed that the parent library module copies thelibc++_shared.so
file underjni/armeabi-v7a/libc++_shared.so
inside thebuild/exploded-aar
directory structure. (See above) Should the closure instead readexclude 'jni/armeabi-v7a/libc++_shared.so
(i.e.jni
vs.lib
)? - Since I am using Gradle plugin 0.9.1, I tried using
pickFirst
in place ofexclude
, but that wasn't successful either.
有人能帮助决定如何,我应该配置`packagingOptions封我的特定情况下?
Can someone help determine how I should configure the `packagingOptions' closure for my given case?
感谢您的帮助!
我遇到了同样的问题,也没有运气排除或PICKFIRST。所以我用了一个有点丑陋的解决方法。我们的想法是建立在主要项目的构建目录中的本机库文件夹,从NDK库项目有复制所有必需的* .so文件,然后告诉构建系统包中的APK这些库。
I ran into the same problem and had no luck with exclude or pickFirst. So I used a somewhat ugly workaround. The idea is to create a 'native-libs' folder in the build directory of the main project, copy all required *.so files from ndk library projects there and then tell the build system to package those libs in the apk.
在我的主要项目(应用工程),我明确地定义包含NDK codeS上,我靠
In my main project (the app project), I explicitely define the list of modules that contain ndk codes on which I depend
// Ndk stuff. We have to explicitely manage our NDK dependencies
ext.jniProjects = [project(':ndklib1'), project(':ndklib2'), project(':ndklib3')]
apply from: '../depend_ndk.gradle'
和然后,'depend_ndk.gradle'是一个包含一个摇篮外部脚本
And then, 'depend_ndk.gradle' is a gradle external script that contains
// Build helper for projects that depends on a native library with a NDK part
// Define the list of ndk library you depend on in project main file :
// ext.jniProjects = [project(':ndklib1')]
// apply from : 'depend_ndk.gradle'
buildscript {
repositories {
jcenter()
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.12.+'
}
}
import com.android.build.gradle.tasks.PackageApplication
// As a workaround, we create a new 'native-libs' folder in the current project and
// copy all the .so we depend on into it
def ndkLibsDir = new File(buildDir, 'native-libs')
ndkLibsDir.mkdir()
task copyDependingNativeLibs(type: Copy) {
// Doc for copy http://www.gradle.org/docs/current/dsl/org.gradle.api.tasks.Copy.html
println 'jniProjects ' + jniProjects
jniProjects.each {
from(new File(it.buildDir, 'native-libs')) {
include '**/*.so'
}
}
into ndkLibsDir
}
tasks.withType(PackageApplication) { pkgTask ->
pkgTask.jniFolders = new HashSet<File>()
pkgTask.jniFolders.add(ndkLibsDir)
pkgTask.dependsOn copyDependingNativeLibs
}