A basic build.gradle file

suggest change

This is an example of a default build.gradle file in a module.

apply plugin: 'com.android.application'

android {
    compileSdkVersion 25
    buildToolsVersion '25.0.3'

    signingConfigs {
        applicationName {
            keyAlias 'applicationName'
            keyPassword 'password'
            storeFile file('../key/applicationName.jks')
            storePassword 'keystorePassword'
    defaultConfig {
        applicationId 'com.company.applicationName'
        minSdkVersion 14
        targetSdkVersion 25
        versionCode 1
        versionName '1.0'
        signingConfig signingConfigs.applicationName
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])

    compile 'com.android.support:appcompat-v7:25.3.1'
    compile 'com.android.support:design:25.3.1'

    testCompile 'junit:junit:4.12'

DSL (domain-specific language)

Each block in the file above is called a DSL (domain-specific language).


The first line, apply plugin: 'com.android.application', applies the Android plugin for Gradle to the build and makes the android {} block available to declare Android-specific build options.

For an Android Application:

apply plugin: 'com.android.application'

For an Android Library:

apply plugin: 'com.android.library'

Understanding the DSLs in the sample above

The second part, The android {...} block, is the Android DSL which contains information about your project.

For example, you can set the compileSdkVersion which specifies the Android API level , Which should be used by Gradle to compile your app.

The sub-block defaultConfig holds the defaults for your manifest. You can override them with Product Flavors.

You can find more info in these examples:


The dependencies block is defined outside the android block {...} : This means it’s not defined by the Android plugin but it’s standard Gradle.

The dependencies block specifies what external libraries (typically Android libraries, but Java libraries are also valid) you wish to include in your app. Gradle will automatically download these dependencies for you (if there is no local copy available), you just need to add similar compile lines when you wish to add another library.

Let’s look at one of the lines present here:

compile 'com.android.support:design:25.3.1'

This line basically says

add a dependency on the Android support design library to my project.

Gradle will ensure that the library is downloaded and present so that you can use it in your app, and its code will also be included in your app.

If you’re familiar with Maven, this syntax is the GroupId, a colon, ArtifactId, another colon, then the version of the dependency you wish to include, giving you full control over versioning.

While it is possible to specify artifact versions using the plus (+) sign, best practice is to avoid doing so; it can lead to issues if the library gets updated with breaking changes without your knowledge, which would likely lead to crashes in your app.

You can add different kind of dependencies:

A particular attention should be dedicated to the aar flat dependencies.

You can find more details in this topic.

Note about the -v7 in appcompat-v7

compile 'com.android.support:appcompat-v7:25.3.1'

This simply means that this library (appcompat) is compatible with the Android API level 7 and forward.

Note about the junit:junit:4.12

This is Testing dependency for Unit testing.

Specifying dependencies specific to different build configurations

You can specify that a dependency should only be used for a certain build configuration or you can define different dependencies for the build types or the product flavors (e.g., debug, test or release) by using debugCompile, testCompile or releaseCompile instead of the usual compile.

This is helpful for keeping test- and debug- related dependencies out of your release build, which will keep your release APK as slim as possible and help to ensure that any debug information cannot be used to obtain internal information about your app.


The signingConfig allows you to configure your Gradle to include keystore information and ensure that the APK built using these configurations are signed and ready for Play Store release.

Here you can find a dedicated topic.

Note: It’s not recommended though to keep the signing credentials inside your Gradle file. To remove the signing configurations, just omit the signingConfigs portion.

You can specify them in different ways:

See this topic for more details : Sign APK without exposing keystore password.

You can find further information about Gradle for Android in the dedicated Gradle topic.

Feedback about page:

Optional: your email if you want me to get back to you:

Table Of Contents