Lately I came to know the power of Gradle as a build system and as an Android developer I wanna understand it deeply.
One article said the following:
You can execute all the build tasks available to your Android project using the Gradle wrapper command line tool. It's available as a batch file for Windows (gradlew.bat) and a shell script for Linux and Mac (gradlew.sh), and it's accessible from the root of each project you create with Android Studio.
To run a task with the wrapper, use one of the following commands:
On Windows:
gradlew task-name
Now I have some doubts which goes as follow:
What is Gradle Wrapper and gradlew.bat?
If I've got Android studio installed and it is using gradle to build my apps (so gradle is already installed on my system), do I still need to install gradle for build purpose from command line? As when i write any commend like gradle, gradlew on my command line I get error saying gradlew is not recognized as internal or external command (the same error for other commands). I may be using it on wrong path, help me on what path do I need to use Gradle related command?
If I need to download and install it, how and where can I find the file? And the other processes?
I am using a Windows machine for this.
The Gradle Wrapper is an optional part of the Gradle build system. It consists of four files that you check into version control system. The Unix start script <your root project>/gradlew, the <your root project>/gradlew.bat Windows start script, <your root project>/gradle/wrapper/gradle-wrapper.jar which contains the class files for the wrapper and is started by the start scripts and <your root project>/gradle/wrapper/gradle-wrapper.properties which contains some configuration for the wrapper, for example which Gradle version to use to build the project.
In my opinion, each and every Gradle project, even the tiniest, should make use of the Gradle wrapper.
The Gradle wrapper makes sure your build is always run with the same Gradle version, no matter who executes the build and where or that Gradle is installed or not, as long as the one uses the Gradle wrapper to build the project. This means you can design your build for that Gradle version and be sure that the build will not fail, just because someone is using a different version of Gradle and thus is also an important step in build reproducibility.
Also, someone wishing to build your project only needs to have Java installed and that's it. He does not need to have any Gradle version installed. Actually any already installed Gradle version is ignored. The Gradle wrapper checks whether in ~/.gradle/ the version that is necessary for the build is already present, because some Gradle wrapper of any project put it there already. If it is present already, it is used, otherwise it is automatically downloaded.
If you type gradlew on the commandline and the command is not found, that means you didn't put your root projects path to the PATH environment variable (I wouldn't recommend doing that either), nor are you currently in your root project's directory. To run a Gradle build, you have to be anywhere inside your project and call Gradle or the Gradle wrapper. But like with any executable file that is not on the path, you have to provide its path of course. So if you are in your root project directory, you can simply do gradlew. if you are in <root project dir>/foo/bar/, you would need to call ../../gradlew.
The Gradle Wrapper files are generated by the implicitly available Gradle task wrapper and then get checked into the VCS of the project in question. If those four files are not present for a project, it does not use the Gradle wrapper and you should post an improvement request to the project to add it.
If some project does not use the Gradle wrapper, but builds with Gradle, you can either install Gradle and use gradle instead of gradlew, or you can even call the Gradle wrapper of any other project that you have available on disk. The build will then be run with the Gradle version that wrapper or Gradle installation is using and thus might not behave as expected, which is why really each and every project should use the wrapper if it uses Gradle.
Edited after comments
Gradle is a build system.
This gradle-wrapper is kind of the primary interface to to build Android projects. It the part of Gradle-build-system and does some primary check if gradle in installed or not.
gradlew.bat - its a batch file used on Windows. You can even open it with a notepad to view the instructions in it. Batch files are like 'commands' written in a file to be executed. You use it (in case of Windows) to execute build commands. It also checks if gradle is installed or not. And in case it is not, it downloads and installs it.
Example : to build android app on Windows:
Open command prompt
Navigate to your project's root directory
execute gradlew.bat assembleDebug
It starts the wrapper, checks if Gradle is installed there and
executes all the 'gradle specific' commands to build your project.
Do you need to install Gradle ?
Actually, no. Its the job of this gradlew script to check for that. If gradle its not already there, it would automatically download it and use it for all later builds.
gradlew.bat IS the Gradle Wrapper (for Windows in this case). Gradle Wrapper is just a small utility that will ensure that Gradle is installed (or install it if necessary) so you can always build the project. Gradle itself allows you to manage dependencies and build configurations for your project.
If you have installed Android Studio, you have Gradle installed and are good to go. (Technically, each project will have it's own wrapper to handle installing/using Gradle)
As I mentioned above, you are good to go.
In the end Gradle is a command line tool that you use to build your project and you could very well use that directly (though you don't have to) since it is exactly what Android Studio uses to build your project.
Related
Currently, I am getting "Finished with error: Gradle task assembleDebug failed with exit code 1" while trying to build a Flutter project (flutter run). The logs do not help much. Therefore, i want to run "gradlew build" or similar manually with stacktrace option to see what is happening under the hood. What is the command for that ?
For posterity I will post my comment as an answer too and I'll elaborate it a bit.
When you create a flutter project there are two new folders created inside the main folder, one is android and one is ios.
The android folder contains the Android native code and all the android configurations, you can handle it as a native android project.
The ios folder contains the iOS native code and all the ios configurations, it also has the xcworkspace file which can be opened with Xcode like a normal ios project.
Now you can run platform specific commands in each folder, like i said, the folders contain actual native projects.
So for Android you could do:
cd android/
./gradlew clean
./gradlew build
(clean and build the project)
For iOS you could do:
cd ios/
pod repo update
pod install
(update the pod repo and install the pods)
Just a short reminder, if you want to create apk/ipa from the native folders, don't forget to run flutter build in the main folder, otherwise you might get outdated code in your apk/ipa.
Go to the folder where you have gradle installed(the place where your GRADLE_HOME variable points to).
Move inside the wrapper folder
Move inside the dists folder which is inside the wrapper folder
Delete everything that you can find inside the dists folder(cached gradle wrapper)
Run/launch your android flutter project again. It should re-download the gradle wrapper and if you don't have any connection problems your project should run correctly.
Note: I'm having the same problem because of my unstable internet connection. I'm ending up with a corrupted gradle wrapper file and the download doesn't restart.
If the download gets interrupted and fails to completely download and launch your project repeat all of the steps.
As described here in the Android Studio docs, one can build an Android app from the command line with the gradle wrapper generated by Android Studio. The command line window in Android Studio shows exactly this, i.e. a call to gradlew assembleDebug (or a similar task). However starting a terminal on macOS and calling the gradle wrapper with that exact call sometimes yields other results, i.e. either one is able to build from Android Studio, or the command line, or both (which is ideal, but unfortunately not always true).
Who can explain what other settings the Android Studio IDE sets for their environment and where to find them, how to reproduce these settings easily in a CI environment (e.g. Jenkins, Bamboo, ...) and how one would consistently store these settings in a VCS along an Android project.
In the root of the project you have gradlew.bat, which is how you can run it in the first place. If you open this file, you see the code for building and everything else Gradle does.
Whether you build from the command line or ANdroid Studio, the gradlew.bat file is used. So building and other stuff you do with the gradlew command all use the same file whether it is from the command line or Android Studio's integrated tools.
You can open the file(s, there's gradlew and gradlew.bat in the project root) and see how it works if you wanted too, though these files are usually automatically generated by Android Studio (it is possible to make your own config as well, though there's rarely a need for that). And for including in vcs, make sure the files aren't listed in .gitnore (or whatever vcs ignore extension you have)
I have a couple of Android project samples I am going to build via the commandline using ./gradlew build on Linux. Whenever I enter this command a message says "Downloading https://services.gradle.org/distributions/gradle-3.3-all.zip". I think I already have the latest gradle under my Android Studio installation path. Why does this have to download gradle every time? Can I specify gradle as an environment variable e.g. GRADLE_HOME so that all projects can use it?
What you have in your Android Studio installation path is not significant when using the Gradle Wrapper (gradlew). It downloads the exact version of Gradle that the current build is designed for and tested with if no other build downloaded it already. The downloaded distributions are stored under ~/.gradle/wrapper/dists/. So as long as you don't delete that folder and you have multiple builds that use the same gradle distribution in the wrapper configuration, that distribution will only be downloaded by the first build you execute. The others will use the already present distribution.
I have updated my gradle-wrapper.properties to 2.10 from 2.8. But I want to know that what its purpose in Android Studio. As we didn't see any gradle-wrapper properties in eclipse.
Gradle Wrapper is a type batch or shell script that downloads and automatically configures Gradle to execute tasks. Imagine that you want to run a Gradle build, well you need to download and install Gradle in your computer, so this concept allows is to distribute our project and build configurations with no need to have Gradle installed.
Also their official gradle webiste says :
Most tools require installation on your computer before you can use
them. If the installation is easy, you may think that’s fine. But it
can be an unnecessary burden on the users of the build. Equally
importantly, will the user install the right version of the tool for
the build? What if they’re building an old version of the software?
The Gradle Wrapper solves both these problems and is the preferred way
of starting a Gradle build.
I am trying to automate the android build process using Jenkins
I am using the following site to achieve this
Link to site
I am successfully able to Build it on my own machine. Initially i got error saying that build.xml file not found (build using ant requires this file). So i execute "android update project". So it automatically generate all necessary file for ant.
Now my problem begins when i tried to host my repo to remote server and tried to build from another machine. The error it is giving is the sdk.dir is not correct. When i analysed the project folder ther is a file called local.properties which contains the SDK path of my first machine which is wrong for other machines. So i add that file to gitignore. Now that file is not tracking and because of this the build is failing.
So is there any way to automatically generate the files that is necessary for ant after jenkins is cloning project from the remote repo?
From the website you link to, they precisely explain how to configure sdk.dir:
Configuring the environment
When jenkins builds your project with Ant, it needs to know where your
android sdk folder is. To do this, click Advanced on the Ant target
build step you just configured and add the following variable to the
Properties field. sdk.dir=/opt/android-sdk-linux/
Don’t forget to substitute the value of the variable with the correct
location where the Android SDK is installed on your build server.
Job configuration is done. Click Save. Time to test your build.
We also build android apps with Jenkins, and also need to edit the local.properties.
In my case, I have the file updated with the path to SDK by the Jenkins build itself. Just before the build starts.
You can use a simple sed command on linux or echo the content on windows (overwriting content).
Example flow:
SCM - get sources
Edit the local.properties (as suggested before)
Run ant build
Note - if you are using the "Invoke Ant", you should add an "Execute Shell" step before to deal with the editing of the local.properties.
I hope this helps.
Yes.
If you install the Android Emulator Plugin for Jenkins, you can add the "Create Android build files" build step to your job.
This will automatically detect any Android app, test or library projects in your Jenkins workspace and add/update the build.xml and local.properties files as necessary.
Alternatively, if you're using the Ant build step and already have the build.xml in your repository, you can ignore the need to create a local.properties file, by specifying the sdk.dir property yourself in the Advanced Ant options.
You can configure ant properties in jenkins. So you can specify all properties of your local.properties through the jenkins job configuration.
Of course you will have to install the android sdk on the jenkins build server.
Please read this for info on how setting ant properties with jenkins.
It's not a good practice to put the local.properties under source code management since multiple developers and CI will have different values for those properties.
you can edit the local.properties file in the jenkins workspace folder to the correct sdk path
I think you want to add the build step "Create Android build files" to your configuration. Place it before the ant build.
This invokes the android update project and android update lib-project. Make sure you referenced your library dependencies in the project.properties with relative paths. Like this:
# Project target.
target=Google Inc.:Google APIs:19
android.library.reference.1=../external-libs/google-play-services_lib
android.library.reference.2=../external-libs/android-support-v7-appcompat