Fixed
Status Update
Comments
uc...@google.com <uc...@google.com>
ax...@gmail.com <ax...@gmail.com> #2
Another use case for this is being able to exclude some specific native libraries on a per-flavor basis.
The alternative is to specify externalNativeBuild.cmake.targets for each productFlavor, but this causes common libraries to be built multiple times which is undesirable.
The alternative is to specify externalNativeBuild.cmake.targets for each productFlavor, but this causes common libraries to be built multiple times which is undesirable.
xa...@google.com <xa...@google.com> #3
Yes we want to do this. It's going to be a little while before we can do this cleaning from an API/DSL but we are currently working toward making this possible.
vi...@gmail.com <vi...@gmail.com> #4
This would help out React Native and RN-based apps, where we'd like to conditionally exclude one of two supported JSVMs and related native libraries.
xa...@google.com <xa...@google.com>
sp...@google.com <sp...@google.com> #5
This is possible now. You can set packagingOptions per buildType or variant like so:
androidComponents {
onVariants(selector().withBuildType("debug"), {
packaging.dex.useLegacyPackaging.set(false)
packaging.jniLibs.excludes.add('**/excludeMe.so')
packaging.resources.excludes.add('**/excludeMe.txt')
}
onVariants(selector().withName("fooDebug"), {
packaging.dex.useLegacyPackaging.set(false)
packaging.jniLibs.excludes.add('**/excludeMe.so')
packaging.resources.excludes.add('**/excludeMe.txt')
}
}
Description
Android Plugin Version: 3.0.1
Module Compile Sdk Version: 27
Module Build Tools Version: 27.0.1
Android SDK Tools version: 26.1.1
It would be great if we could define packagingOptions per buildType. Our use case is to avoid stripping native libraries for profiling, but keep stripping for release. There may be more.
Sample for Simpleperf tool adds packagingOptions inside a build type:
But when used this way, the debug info is kept also for debug and release build type, which is undesirable.