Android Gradle for Android A basic build.gradle file
Example
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).
Plugins
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:
Dependencies
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.
signingConfig
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:
- storing in an external file
- storing them in setting environment variables.
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.
