I've tried doing abiFilters ["armeabi-v7a"] instead of abiFilters.add("armeabi-v7a") but that results in linking error and message:
Execution failed for task ':linkMyModuleArm64-v8aDebugSharedLibrary'
Basing on this message I suspect that project is still build for all platforms...
Inside your model block create android.productFlavors block (you should already have this). Then apply your abiFilter like this:
create("arm"){
dimension = "abi"
ndk.abiFilters.addAll(['armeabi'])
}
Adding abiFilters.addAll(['armeabi']) to your main ndk block, would set the default for all "Variants"
Have a look at http://tools.android.com/tech-docs/new-build-system/gradle-experimental#TOC-Other-Build-Options
Related
Android gradle plugin generates tons of .rawproto files in build/android-profile directory. What are they used for? Is there a way to disable this madness or automatically delete them?
I've been bugged by it for a long time, and now that I noticed there's gigabytes of this hogging my smallish SSD, I've decided to figure out a way to disable it. For me the most annoying thing before occupying too much space was gradlew clean leaving a build folder behind.
Only tested with com.android.tools.build:gradle:3.0.1, so YMMV.
TL;DR
For global application read last section, per-project use this in rootProject's build.gradle:
com.android.build.gradle.internal.profile.ProfilerInitializer.recordingBuildListener =
new com.android.build.gradle.internal.profile.RecordingBuildListener(
com.android.builder.profile.ProcessProfileWriter.get());
// and then `gradlew --stop && gradlew clean` to verify no build folder is left behind
Investigation
Thanks to https://stackoverflow.com/a/43910084/253468 linked by #JeffRichards mentioning ProcessProfileWriterFactory.java, I've put a breakpoint there and checked who's calling it by running gradlew -Dorg.gradle.debug=true --info (not to be confused with --debug) and attaching a remote debugger.
I followed the trail and found that ProcessProfileWriter.finishAndMaybeWrite creates the folder and writes. Backtracing on method calls I found that ProfilerInitializer.recordingBuildListener controls whether it's called ... and that is initialized directly by BasePlugin (apply plugin: 'com.android.*').
So in order to prevent anything from happening I opted to try to disable the guard, by pre-initialized that static field. Thankfully Groovy (and hence Gradle) doesn't give a * about JVM visibility modifiers, so without reflection here's the magic line:
com.android.build.gradle.internal.profile.ProfilerInitializer.recordingBuildListener =
new com.android.build.gradle.internal.profile.RecordingBuildListener(
com.android.builder.profile.ProcessProfileWriter.get());
I know, it's a bit verbose, but it works, and if you import stuff it looks better:
ProfilerInitializer.recordingBuildListener = new RecordingBuildListener(ProcessProfileWriter.get());
Applying the magic
In a single-project build (one build.gradle) you must apply this before
apply plugin: 'com.android.application'
In multi-project builds (most template projects: app folder, settings.gradle, and many build.gradles) I suggest you apply it around the buildscript block:
buildscript {
// ...
dependencies {
classpath 'com.android.tools.build:gradle:3.0.1'
}
}
// magic line here
Make sure it's before any apply plugin:s, and not inside a buildscript block.
Applying the magic globally
Obviously if it bothers us in one project, it will in all cases, so following Gradle's manual, create a file in ~/.gradle/init.gradle or %USERPROFILE%\.gradle\init.gradle (mind you this folder can be relocated with GRADLE_USER_HOME) with the following contents:
// NB: any changes to this script require a new daemon (`gradlew --stop` or `gradlew --no-daemon <tasks>`)
rootProject { rootProject -> // see https://stackoverflow.com/a/48087543/253468
// listen for lifecycle events on the project's plugins
rootProject.plugins.whenPluginAdded { plugin ->
// check if any Android plugin is being applied (not necessarily just 'com.android.application')
// this plugin is actually exactly for this purpose: to get notified
if (plugin.class.name == 'com.android.build.gradle.api.AndroidBasePlugin') {
logger.info 'Turning off `build/android-profile/profile-*.(rawproto|json)` generation.'
// execute the hack in the context of the buildscript, not in this initscript
new GroovyShell(plugin.class.classLoader).evaluate("""
com.android.build.gradle.internal.profile.ProfilerInitializer.recordingBuildListener =
new com.android.build.gradle.internal.profile.RecordingBuildListener(
com.android.builder.profile.ProcessProfileWriter.get());
""")
}
}
}
I have a multi-project test issue: I want one project to depend on another project's androidTestCompile.
I have tried this way:
androidTestCompile project(':CommonTest').sourceSets.androidTest
But android studio says it could not find property androidTest on SourceSet container.
Help
Here's an approach that might work. I've not tried it as I don't have a multi-project Android project. You'll need to tweak the code for your project names and specify the dependsOn in your current projects task for Android Tests.
task action(dependsOn: ":producer:action") << {
println("Consuming message: ${rootProject.producerMessage}")
}
See the topic 24.6.1.2. Declaring dependencies in https://docs.gradle.org/current/userguide/multi_project_builds.html
Another clue is in the Gradle Java Tutorial which explains how to establish dependencies between projects in a multi-project build https://docs.gradle.org/current/userguide/tutorial_java_projects.html#N14E23
dependencies {
compile project(':shared')
}
So I'd hazard a guess that something like
dependencies {
androidTestCompile project(':CommonTest')
}
(which you've tried, albeit with more parameters) is on the right track.
Consider the following method invokation containing in the gradle build script:
gradle.taskGraph.whenReady{taskGraph ->
println gradle.toString()
println "Ready"
}
It prints
build 'task_graph'
Ready
I thought we work in the scope of Project object, since gradle should be a property of that Project object. But there is neither property nor even method with such name. Why can we use it in the build script?
I may be wrong but I think your confusion is that there exists a getGradle() method on the Project interface but no such public field named gradle. This is a Groovy feature. In Groovy, getter and setter methods can by referenced as properties. For example:
println project.description // same as project.getDescription()
project.description = 'My java project' // same as project.setDescription('My java project')
I'd highly suggest familiarizing yourself with Groovy by checking out their documentation. You'll see a lot of differing syntax in Gradle examples simply because there are many different ways to accomplish the same thing in Groovy.
I'm totally new to this gradle, teamcity and groovy.
I'm tryign to write a plugin,which will get the value from svninfo. If the developer wants to override the value(in build.gradle) they can override something like this.
globalVariables{
virtualRepo = "virtualRepo"
baseName = "baseName"
version = "version"
group = "group"
}
Here i provide the extension called globalvariable.
Now, The jars to be produced shd hav the name according to the values from the build.gradle..
How to get the value from build.gradle in the plugin inorder name the jar???
Not sure I understand the question. It's the plugin that installs the extension object, and it's the plugin that needs to do something with it.
Note that the plugin has to defer reading information from the extension object because the latter might only get populated after the plugin has run. (A plugin runs when apply plugin: is called in a build script. globalVariables {} might come after that.) There are several techniques for deferring configuration. In your particular case, if I wanted to use the information provided by the extension object to configure a Jar task, I might use jar.doFirst { ... } or gradle.projectsEvaluated { jar. ... }.
Before you go about writing plugins, make sure to study the Writing Custom Plugins chapter in the Gradle user guide. A search on Stack Overflow or on http://forums.gradle.org should turn up more information on techniques for deferring configuration. Another valuable source of information is the Gradle codebase (e.g. the plugins in the code-quality subproject).
How can I stop a Gradle build after detecting a problem? I can use an assert, throw an exception, do a System.exit (bad idea), or use a dedicated function in Gradle (but I could not find one). What is the best way for Gradle (and why?).
I usually throw the relevant exception from the org.gradle.api package, for example InvalidUserDataException for when someone has entered something invalid, or GradleScriptException for more general errors.
If you want to stop the current task or action, and move on to the next, you can also throw a StopActionException
If you want to stop the build, throw:
throw new GradleException('error occurred')
or throw the subclasses for the above exception. Some of the subclass exceptions actually only fail the current task but continue with the build.
There is currently no dedicated method, although there have been discussions to add one.
The recommended way to stop a Gradle build is to throw an exception. Since Groovy doesn't have checked exceptions, and Gradle by default does not print the exception type, it's not that critical which exception is thrown. In build scripts, GradleException is often used, but a Groovy assertion also seems reasonable (depending on the circumstances and audience). What's important is to provide a clear message. Adding a cause (if available) helps for debugging (--stacktrace).
Gradle provides dedicated exception types StopExecutionException/StopActionException for stopping the current task/task action but continuing the build.
Another option if you don't have any desire to be able to catch the exception later on is to call the ant fail task. It's slightly easier to read in my opinion and you can give a nice message to the user without use of --stacktrace.
task (tarball, dependsOn: warAdmin) << {
ant.fail('The sky is falling!!')
}
Gives you a message like:
* What went wrong:
Execution failed for task ':tarball'.
> The sky is falling!!
Probably you can catch this (perhaps it throws ant's BuildException?) but if that's a goal then I wouldn't use ant.fail. I'd just make it easy to see what exception to catch by throwing standard gradle exception as tim_yates suggested.
Throwing a simple GradleException works in stopping the build script. This works great for
checking required environment setup.
GradleException('your message, why the script is stopped.')
Example:
if(null == System.getenv()['GRADLE_USER_HOME']) {
throw new GradleException('Required GRADLE_USER_HOME environment variable not set.')
}
Here is a code fragment that tries to emulate how the Gradle javac task throws errors:
task myCommand(type:Exec) {
... normal task setup ....
ignoreExitValue true
standardOutput = new ByteArrayOutputStream()
ext.output = { standardOutput.toString() }
doLast {
if (execResult.exitValue) {
logger.error(output())
throw new TaskExecutionException( it,
new Exception( "Command '${commandLine.join(' ')}' failed; "
+ "see task output for details." )
)
}
}
}
When the command returns 0 there is no output. Any other value will print the standardOutput and halt the build.
NOTE: If your command writes to errorOutput as well, you may need to include that in the error log.