Hello,
This is just some feedback of my experience of upgrading our build scripts
from Android Gradle plugin 1.0 to the latest one (2.2).
First of all I was always happy with Android Gradle built tools and how
superior they are for complex builds comparing with ant-based ones. I
remember that with ant tools our build process was like making copy of
source files, apply manifest patching, repeat - it was slow, error-prone
and had a lot of scripting to support. With Gradle we were able to remove
most of that and build scripts become much more clean despite of the new
requirements.
However I am upgrading now to latest version of Gradle plugin and I feel
like it became less flexible for our tasks when it comes to packing native
libraries.
Our setup that we have a native libraries built in some dir and then we
build two project "Foo" and "Bar" picking up native libraries. In old
Gradle plugin when there were no .so support we had full control on which
native libraries to include for each variant:
In "Foo" project:
// Configure all builds
android.applicationVariants.all { variant ->
// Package the .so from native code into the Jar files
def taskJniJar = project.tasks.create "jarJni${variant.name.capitalize()}",
Jar
taskJniJar.from(fileTree(dir: getNativeLibsPath(project, variant), include:
"**/*.so")) {
if (variant.name.toLowerCase().contains('rootless')) {
exclude("**/librootutils.so") // Do not include root support in some
build variants
}
exclude("**/libfootests.so") // Do not package native tests to release
exclude("**/libbar*.so") // Do not package "Bar" libraries
into "lib"
}
taskJniJar.baseName = "jni-${variant.name.capitalize()}"
artifacts.add('archives', taskJniJar);
variant.javaCompile.dependsOn taskJniJar
variant.outputs.each { output ->
// Add .so to APK using packagedJars property (now removed from API)
output.packageApplication.packagedJars += taskJniJar.archivePath
}
}
The similar code we had for android.testVariants to add native test
libraries to test APK.
This allowed us the following:
- The library directory depend on variant and can evaluated for each
variant: getNativeLibsPath(project, variant), e.g. debug/release, brand,
etc.
- We can include *.so based on some rules for variants
- We can exclude native test *.so files from product build and include
them in test variants.
Now the packagedJars property has been removed and if I understood it
correctly we only have jniLibs.srcDirs=[] to specify the directory that
contains native libraries and PackagingOptions {excludes} to exclude some
of the native libraries for all variants and test variants. If we have 2
dimensions (2*3 = 6) and 2 build types (release/debug) we would have to
specify jniLibs.srcDirs=[] 12 times. Fortunately we could avoid this in our
case.
What I think we cannot avoid is to have some *.so to be excluded from
product build, but to be included in test APK (native tests). It looks like
the only reliable approach now is to copy *.so to the variant jniLibs
directory, which reminds me the ant-based build system where we have things
to copy multiple times to make the ant script happy. Perhaps I am not aware
of some feature, so any advise would be welcome.
Upd: While writing this I have found that there is plug-in that could help
us: https://github.com/Jween/android-soexcluder,
from
http://stackoverflow.com/questions/35548217/packaging-options-based-on-product-flavor-in-gradle.
The strong side of the Gradle build system that it has DSL for typical
built tasks and some advanced low level Gradle API when there something
unusual is required. Now as far as I can see from API it looks like much
more restrictive, e.g. when I attempted to use PackageApplication.jniDir it
said me that this is read-only.
On the bright side, during update I have found that there are new features
like having applicationIdSuffix for flavors that helped to remove a lot of
code from our current Gradle script.
Thanks for listening!
--
You received this message because you are subscribed to the Google Groups
"adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
