I distinctly remember what it felt like the first time I started Android development and opened up Android Studio (well, Eclipse back then). I sat, stupefied, looking at the vast array of different windows, dialogues, and files. There’s so much to learn here, that even knowing which window you’re meant to be looking at can be hard.
There’s plenty of introduction to help you muddle through Android Studio on this site. But one of the biggest pieces of the puzzle is Gradle. Just what are those Gradle files? And why do you always have to wait for it to finish syncing before you can do anything?
This post will serve as an introduction to Gradle for complete beginners, to help demystify this actually rather useful tool and help give you a starting point for when things go wrong.
An introduction to Gradle for Android
Gradle is what we call a build tool or build system. More specifically, it is a JVM-based build system.
Despite not being very newcomer-friendly, Gradle has managed to gain popularity owing to its open-source nature, as well as its versatility, and use of plugins.
As we’ve already discussed, there are a lot of files involved in an Android app. Your resources need to be compressed, your source code needs to be converted to DEX files (Dalvik Executable), the APK needs to be signed. It’s a lot.
And all of that needs to be arranged nicely if you’re going to create a working APK. The images that will go into your app, the layout files, the Java. Then there are the libraries you use to extend your code’s capabilities. You also need to think about version control, about the key signature. I could go on.
From Google
Is it possible to build an APK without using Gradle? Yes: you can do this using the command line (ADB Bridge), but you would need to understand what each tool in the Android SDK does and how it contributes to turning your code into an installable file. And, as Google is constantly changing things and adding new features, this would also likely be an ongoing learning process. There are also alternative options out there, such as Apache Ant, but Gradle is the one that Google chose to support.
Gradle will use the appropriate tools to compile your various source files, and to compress everything into one nicely packaged APK. And all you had to do was to hit “build,” and make sure that all your files were saved in the correct folders.
Gradle also does a lot of other useful stuff behind the scenes – helping to reduce the size of the APK for example, and letting us build debug apps for testing (this is a “build type”).
Sure, Gradle can often seem like the source of a thousand problems when it doesn’t work properly (when digging out an old piece of code from an older version of Android Studio for instance). But in fact, its presence makes life far simpler than it otherwise would be. In truth, Gradle is not the problem – it’s just the messenger.
What you need to know about Gradle
Gradle works by carrying out different scripts, which contain tasks. These tasks tell Gradle how to build your application – moving files located in specific folders, or compiling scripts in particular ways. You’ll find these scripts in your Gradle files, such as the two build.gradle files.
That’s right, there are (at least) two different build files – one for the entire project, and another for each module. The module generally refers to a single app build, and is where you’ll spend most of your time.
Here, you will be able to see a lot of the information that helps Gradle to do its job. That includes the target SDK, the package name, the version number, and more.
But perhaps the most common reason for a developer to dive into their build.gradle files themselves, is to handle dependencies – e.g. libraries.
Any time you want to add a new local or remote library to your project, you will add the dependencies to the “dependency block” found at the bottom of the module-level build.gradle file. Alternatively, you can do this through the menu system – which will update the relevant files for you.
Other Gradle files include:
- settings.gradle – Which defines the modules in a project.
- local.properties – Which points to your Android SDK.
- gradle.properties – Which can contain a range of configuration properties but starts out empty.
- gradle-wrapper.properties – Which defines and installs the correct version of Gradle needed for the project.
More uses for Gradle
You can also achieve other things by tinkering with your Gradle files. For example, Gradle offers support for multiple APKs, making it simple to create different versions of your app targeting different devices – these versions are called “flavors.”
Gradle will come into play if you want to create an instant app meanwhile, as you’ll need to create a feature module and then edit the build.gradle file to reflect that. That instant app Gradle file will also need a dependency pointing to the “:base” feature module. Instructions can be found here.
The good news is that instructions are readily available for anything you might want to do. If you should run into a problem, or if you should want to do something that involves different types of app “builds,” Google is your friend.
Sometimes an error will crop up if Gradle gets confused or can’t find a file, but this is increasingly rare. Hitting “clean project” will normally solve the problem.
If not, it may be that one of the files is using a deprecated configuration or other out-dated line. Android Studio will normally clue you in on how to solve the issue, as will another quick Google search.
Generally though, most of what you do in Gradle can be done through Android Studio’s own UI – meaning you rarely need venture down there. This is especially true if you’re creating an app with only one module.
That means the most important job for a new developer, is simply keeping Gradle and Android Studio up to date.
Let Gradle handle the rest!