Difference Between Build.Gradle (Project) and Build.Gradle (Module)

Difference between build.gradle (Project) and build.gradle (Module)

build.gradle (Project:My-app)

Top-level build file where you can add configuration options common to
all sub-projects/modules.

Each project contains a top-level Gradle file. It usually contains common configurations for all modules. Whatever is included in this top-level Gradle gile, it will affect all modules.

Example:

// Top-level build file where you can add configuration options common to all sub-projects/modules.

buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:2.0.0-alpha3'

//Maven plugin
classpath 'com.github.dcendents:android-maven-gradle-plugin:1.3'

// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}

allprojects {
repositories {
jcenter()
maven { url "https://jitpack.io" }
}
}

task clean(type: Delete) {
delete rootProject.buildDir
}

build.gradle (Module:app)

Build file of your specific module (where you add your dependencies, signing configurations, build types, flavors, etc.)

All modules have a specific Gradle file. Whatever is included in this gradle file, it will only affect the module that is included on.

Example:

apply plugin: 'com.android.application'

android {
compileSdkVersion 23
buildToolsVersion "23.0.2"

defaultConfig {
applicationId "com.hrskrs.gesturefun"
minSdkVersion 10
targetSdkVersion 23
versionCode 1
versionName "1.0"
}
buildTypes {
release {
zipAlignEnabled true
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
debuggable true
zipAlignEnabled true
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}

dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile project(':gesture-fun')
testCompile 'junit:junit:4.12'
compile 'com.android.support:appcompat-v7:23.1.1'
compile 'com.android.support:design:23.1.1'
compile 'com.jakewharton:butterknife:7.0.1'
}

What is the difference of two build.gradles in project root directory and in app folder?

The "app" folder is just one module. When writing more complex apps you may have multiple modules. The build.gradle at the module level relates only to that module whereas the build.gradle at the root relates to all modules in the project.

Example from project level build.gradle:

allprojects {
repositories {
jcenter()
}
}

This is saying all modules should use jcenter repository for resolving dependencies. Now a potentially confusing thing is a terminology clash between gradle and android studio. An android studio "module" is a gradle "project" hence "allprojects".

Difference between build.gradle and integration.gradle

One build.gradle file is automatically assigned to each (sub-)project in a Gradle build. The name is the default, but it can be changed in the settings.gradle file. This is the first possibility how the file called integration.gradle could be used. The second possibility is that the file provides functionality used by one or more projects and gets referenced via apply from: somewhere in a build.gradle file.

Difference between Settings gradle, property gradle and build gradle

mark the directory root of a tree of modules

The folder containing settings.gradle will be considered the root directory of your project. All modules are contained within this directory.

submodule lookup can be customized

I don't really know about this. The only two things I've seen declared in settings.gradle is include and custom dependency resolution rules (you can also put your buildscript {} there apparently).

Maybe it meant that with include you can specify any directory to be marked as a module? For example you can do :app:features:feature1 to declare the app/features/feature1 directory as a module.

There's a documentation page on settings.gradle if you're interested.

In the build.gradle file of the main module, you can use allprojects {} or subprojects {} to define settings for all other modules.

Wasn't that what settings.gradle was for? to define settings for all included sub-module

allprojects and subprojets are just a way to group duplicate code. For example, you declare dependencies in pretty much every module, and dependencies to be resolved from a repository. So in the root project's build.gradle, we usually have:

allprojects {
repositories {
jcenter()
mavenCentral()
// etc...
}
}

If you wanted, you could put a repositories block per module build script and the effect would be the same.

Why is this not in settings.gradle? I think because settings.gradle is more about configuring the project structure than the project itself. Also, since settings.gradle is executed first, the modules aren't defined yet so they can't really be configured.

gradle.properties in Android should be used more or less like environment file

Pretty much. People sometimes declare dependency versions there so they aren't repeated in each module. These properties will be available everywhere, even from settings.gradle.

Hope it helps. I wish I had more answers, this was meant to be a comment but it was a little long.

Why are there two build.gradle files in an Android Studio project?

<PROJECT_ROOT>\app\build.gradle is specific for app module.

<PROJECT_ROOT>\build.gradle is a "Top-level build file" where you can add configuration options common to all sub-projects/modules.

If you use another module in your project, as a local library you would have another build.gradle file:
<PROJECT_ROOT>\module\build.gradle

For example in your top level file you can specify these common properties:

buildscript {
repositories {
mavenCentral()
}

dependencies {
classpath 'com.android.tools.build:gradle:1.3.0'
}
}

ext {
compileSdkVersion = 23
buildToolsVersion = "23.0.1"
}

In your app\build.gradle

apply plugin: 'com.android.application'

repositories {
mavenCentral()
}

android {
compileSdkVersion rootProject.ext.compileSdkVersion
buildToolsVersion rootProject.ext.buildToolsVersion
}


Related Topics



Leave a reply



Submit