I am trying to do a very simple thing. As gradle removes all files in the build dir when cleaning I want to move the apks somewhere else when creating release versions. So I added a copy task into the chain and I set it to be the last. Anything I tried did't work. So I simplified it and added some logging to make a point. I think it just doesn't work.
Using two variables, I can check that at task definition time and execution time the input and output paths are valid. I can also check that the task is executed. I put some more files in the input directory to make sure there is also something there in any case. This is the script:
def buildPath
def outPath
task copyApks(type: Copy) {
buildPath = "$buildDir\\outputs\\apk"
outPath ="$buildDir\\outputs\\apk2"
logger.error("Source Folder is $buildPath")
logger.error("Destination Folder is $outPath")
from buildPath
into outPath
}
assembleRelease.doLast {
android.applicationVariants.all { variant ->
println "Variant $variant.name"
logger.error("Source Folder is $buildPath")
logger.error("Destination Folder is $outPath")
copyApks
}
}
And this is the output, where one can see that the paths are correct (they exist and are valid) both at definition and execution time. Also one can see that the task is executed:
What is wrong?
Executing external task 'assembleRelease'...
Parallel execution with configuration on demand is an incubating feature.
Source Folder is C:\Users\Administrator\Projects\Gradle\MB6\app\build\outputs\apk
Destination Folder is C:\Users\Administrator\Projects\Gradle\MB6\app\build\outputs\apk2
................
some other gradle logs
................
:app:assembleRelease
Variant debug
Source Folder is C:\Users\Administrator\Projects\Gradle\MB6\app\build\outputs\apk
Destination Folder is C:\Users\Administrator\Projects\Gradle\MB6\app\build\outputs\apk2
Variant release
Source Folder is C:\Users\Administrator\Projects\Gradle\MB6\app\build\outputs\apk
Destination Folder is C:\Users\Administrator\Projects\Gradle\MB6\app\build\outputs\apk2
BUILD SUCCESSFUL
First of all, you have to know, that just adding the task name into your closure, in your case it's copyApks, doesn't really mean that this task should be executed. It's just the same, as you specified a variable, but do nothing with it.
And one more, note, the both variants paths are the same, that means that you are trying to copy tha same files twice. Actually, that not the only reason, you have to understand, that your copy task is configured yet in the configuration phase, when you are trying to call it during the execution phase, so you can't change it's from and into parameters, and this task will always behave the same.
If you want to call some tasks one after another, you have a number of choices, like task dependencies, task finalization or task ordering. You can read about it in the official user guide. There is a way to call some task like a method call, but this is a very poor solution and you have to avoid using it.
So, if you want to call a copy task, then you may try solution like this
assembleRelease.finalizedBy copyApks
This will call a copy task always every time assembling is done.
Related
I am using a gradle task to generate some code for my API and store this code into the build folder. When I am building my application the process deletes the build folder.
Is there a way to call my code generation task between the folder deletion and the start of the compilation?
I am not a Gradle expert, so their might be better answers!
In your build.gradle you can create custom tasks and make them depend on other tasks:
// this is your new task
task generateCode() {
description 'Generates some code...'
doLast {
println("generateCode")
// do your code generation here
}
}
// put the name of the task you wanna depend on, like: compileSources
project.task("compileSources").dependsOn generateCode
When you call this task ./gradlew compileSources you should see that the custom task generateCode gets executed first.
After allot of trying , i found the solution .
In the build.gradle i had to add the preBuild.finalizedBy(generateCode)
About Bintray-release plugin
I am using bintray-release to upload my library to maven.Its doc says how to use it:
Use the publish closure to set the info of your package:
publish {
userOrg = 'novoda'
groupId = 'com.novoda'
artifactId = 'bintray-release'
publishVersion = '0.3.4'
desc = 'Oh hi, this is a nice description for a project, right?'
website = 'https://github.com/novoda/bintray-release'
}
Finally, use the task bintrayUpload to publish
$ ./gradlew clean build bintrayUpload -PbintrayUser=BINTRAY_USERNAME -PbintrayKey=BINTRAY_KEY -PdryRun=false
In my case
Then I define my publish closure:
publish {
groupId = 'com.uniquestudio'
artifactId = 'parsingplayer'
publishVersion = '2.0.6'
website = 'https://github.com/TedaLIEz/ParsingPlayer'
Properties properties = new Properties()
InputStream inputStream = project.rootProject.file('local.properties').newDataInputStream() ;
properties.load( inputStream )
bintrayUser = properties.getProperty('bintrayUser')
bintrayKey = properties.getProperty('bintrayKey')
}
As you can see,out of safety I put bintrayUser and bintrayKey into local.properties.
My Question
First
I know I can put bintrayUser and bintrayKey in loacal.properties and gradle.properties.Is there any other way to store private data while I don't think is't suitable to store private data within current project ?
Second
Everything is ok but when I push my project to CI.I get error:
/home/travis/build/TedaLIEz/ParsingPlayer/local.properties (No such file or directory)
So I want to know How gradle task deal with extension objects,in my case,publish object.Is there any way to fix it?
First, I have to tell you that it is not recommended to ask two questions at once via StackOverflow, mainly because it may be hard to choose a correct answer, if two answers help you with the different questions you asked.
Anyhow, I'll try to answer both of your questions:
First
To use an additional properties file (local.properties in your case) is not a Gradle approach. It is in fact pure Java. You should only read properties on your own in very rare cases and never in a build script. If you really need an additional properties file, develop a Gradle plugin, which handles the file access.
Gradle automatically reads the gradle.properties file, but not only in the project directory, but also in the user-specific gradle home directory (e.g. C:\Users\*<User>*\.gradle). This is helpful to define private data, which won't find its way into version control, even if you forget to ignore the files manually. The defined data will be accessible to any project.
Second
Well, I assume the file local.properties does not exist, because you did neither put it under version control nor let your CI add it automatically. Where should the login data come from?
The solution is simple. Just add the required data to the CI user gradle home directories (e.g. /home/travis/.gradle) gradle.properties file. This way, you can also simply add access right management, by entering the login data of a CI user. Local builds will be published by your local user account (if allowed), CI builds by the CI system.
Appendix
Your question includes the Gradle specific term 'extension', but, to be honest, it got nothing to do with your question. It is correct, that most configuration in Gradle is done via so-called extension objects, that are added to the Project object, but it is an internal term, you do not need to understand it to fix this problem.
Edit: Comment answer
Now I can understand your confusion. Gradle distinguishes between the configuration phase and the execution phase. Nearly everything in your build script is executed during the configuration phase, only task actions (what a task does, e.g. copying, deleting ...), doFirst and doLast closures (so basically tasks) are executed during execution phase. If you define the list of tasks to be executed (via command line), it only affects the execution phase, but your configuration code will be executed at every single build, even if only one independent task is executed afterwards.
To solve this problem, follow the solution in the First block and add your private data to the user-specific Gradle directory gradle.properties file. It will be added to the project object and therefor, it will be accessible from the build file. But, since the file (or the data) does not exist on your CI, accessing it directly will raise an error when building on the CI. You can use the findProperty(propertyName) method as a fail-safe way to access the property value. If the property does not exist, it returns null (in the configuration phase), so no error occurs, as long as you don not execute the bintrayUpload task (which is not your goal on the CI).
In my gradle file I want to know which task triggered the code block. e.g. If I run
gradle assembleVanillaDebug
from the terminal, I want to know in my gradle file that assembleVanillaDebug task is being executed. This will also help me in figuring out I am running debug build type task or release build type task.
Can we know which task is being executed?
In the end,
gradle.startParameter.taskNames
proved to be my friend. gradle.startParameter.getTaskNames() would return you the list of all tasks being executed in current build.
e.g. For gradle clean assembleVanillaDebug, it will return you a list of tasks clean and assembleVanillaDebug.
Seeing this is still the first hit on google when you search for listing tasks, I thought I'd share the better way I found of getting all tasks that are being scheduled:
// Doc: Returns the tasks which are included in the execution plan.
// The tasks are returned in the order that they will be executed.
gradle.taskGraph.allTasks
As opposed to gradle.startParameter which is meant for finding out how gradle has been started, this gives you a list of actual task objects that gradle queues for execution.
Edit:
Make sure the graph is resolved before using it. It should be available when running a task action, for example in a doFirst {}, or try running your code in the whenReady{} closure like so:
project.gradle.taskGraph.whenReady {
println(project.gradle.taskGraph.allTasks)
}
I'd like to create a Gradle task that computes the classes.dex CRC, then writes the resulting value into a resource string. This value will be checked at runtime to determine whether the APK has been tampered or not. The problem is that beginning with Gradle plugin 1.4.+ it is not possible to access the dex task anymore. Instead, we should use Transform API. I found very little documentation about Gradle tasks in the Android environment, so I would ask a few questions:
What's the Gradle task that deals with the classes.dex file?
How should the Transform work with this task?
I've seen lots of threads about this argument, but none of these have a working solution. Thanks in advance!
According to Xavier Ducrohet:
You have to build twice. classes.dex contains R.class which is generate from the res compilation. So by the time you're computing the CRC32 it's too late to put it in.
In general you really shouldn't be modifying the model during task execution. In fact, Gradle will introduce task parallelization that really will require to not touch the model when the task are running. So we're going to (try to) fix this by making it impossible to do this. I just filed > https://code.google.com/p/android/issues/detail?id=82574
So I would do the following:
- in the evaluation phase of your project, read a file that contains the CRC and set it as a resources. Something like this (using Guava):
android.applicationVariants.all { variant ->
variant.resValue "string", "CRC", com.google.common.io.Files.toString(file("$buildDir/intermediates/checksum/$variant.dirName/classes.crc32"), Charsets.UTF_8)
}
setup a task that creates the file that contains the CRC32.
android.applicationVariants.all { variant ->
variant,outputs.each {
// create the task here. it depends on the dex task, and make the outputs.packageApplication task depend on it.
}
}
Note: this is not enough. What you know need to do is ensure that if the newly computed CRC32 is different than the current file, the build breaks, forcing you to build a 2nd time. This way you have the two cases:
- CRC32 file is missing or the content is incorrect. You compute the new CRC32, put it in the file and fail the build forcing to build again with this new value.
- CRC32 is already valid, which mean the resource contains the right value, the task does nothing more and the build continues.
https://groups.google.com/d/msg/adt-dev/W2aYLBSeGUE/fzOqyH8YibQJ
We have a gradle task that will automatically generate codes for us before building. See the following as an example,
task djinniTask(type: org.gradle.api.tasks.Exec) {
commandLine 'sh', './Djinni/run_djinni.sh'
}
assembleDebug.dependsOn djinniTask
Basically, the above run_djinni.sh is using a library djinni to generate JNI codes. The above works fine except that it will run this script every time we build even if we didn't update the script file, which is obviously not very efficient. We did a bit of research and found 17.9. Skipping tasks that are up-to-date. And as a result, the following works fine. It will skip this task if we didn't modify run_djinni.sh.
task transform {
ext.srcFile = file('./Djinni/run_djinni.sh')
ext.destDir = new File(buildDir, 'generated')
doLast {
commandLine 'sh', './Djinni/run_djinni.sh'
}
}
Now the problem is, the run_djinni.sh is not the only script file that we have. The project is big and we multiple scripts files like: run_foo_djinni.sh, run_bar_djinni.sh and etc. run_djinni.sh will call each of the other scripts. So is there a way to declare the inputs of a gradle task as multiple files, for example, in our case, every files that is under the Djinni folder?
Ok, according to gradle DSL you can define multiple inputs:
task transform {
inputs.files('file path', 'another file path')
}