"build.gradle（项目）和 build.gradle（模块）之间的区别"

Question

I am trying to add a dependency of Android Asynchronous Http Client into my project. So there are two build.gradle files in the project.

As per my understanding, there are different kind of dependencies:

1. One which defined on the root level of build.gradle (Project:My-app)
2. One inside the buildscript of the build.gradle (Project:My-app)
3. Another is build.gradle (Modules:app)

This question is about repositories for dependencies of the buildScript, explain a bit about first two types.

Also build.gradle (Project:My-app) says

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

So I guess the dependency code of Android Asynchronous Http Client should be added in build.gradle (Module:app).

How does it all fit together?

Answer 1

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'
}

Answer 2

It's a bit confusing because Android Studio by default shows both build.gradle files right next to each other (when using the Android view).

If you switch to the Project view you can see the actual structure and where the different build.gradle files are located.

The build.gradle (Project: MyApplication) file is in the root folder of the project and its configuration settings apply to every module in the project. A module is an isolated piece of the bigger project. In a multi-module project, these modules have their own jobs but work together to form the whole project. Most Android projects only have one module, the app module.

The build.gradle (Module: app) file here is in the app folder. Its build settings apply only to the app module. If there were another module, then that module would have its own build.gradle file, too. As an example , I made a library project with three modules: a library module, a demo app module, and another app module that I plan to use for testing. Each of them have their own build.gradle files that I can tweak.

In a basic project, almost everything you need to edit will be in the app module's build.gradle file. You can remember it like this:

You're making an app , so go to the build.gradle (Module: app ) file.

Further reading

• Configure Your Build (Android documentation--very readable and useful)
• Introduction to multi-project builds (Gradle documentation)

Answer 3

About the relation of the two gradle files, hrskrs made a very clear explanation，and I will make some supplement about it.

If your project only has one Module (such as app ), the advantage of the top build.gradle (Project:My-app) not show very clear. Because you can configure everything in build.gradle (Module:app) about the Module, and only modify one file when upgrading in the following days.

But if your project has five modules, and it happened that they have a same dependence A , if you don't use the top build.gradle (Project: My-app) you need to maintain five files in the following days.

By the way, the build.gradle (Module:app) can overwrite the build.gradle (Project:My-app) .

This design can improve the maintainability of the app.

Answer 4

[Project vs Module]

Projects' build.gradle file is used for common/shared logic. For example, you can define repositories here ( Maven , Google, JCenter , and custom) or specify ext {} with shared variables or classpath ^[About] .

Module's build.gradle is used for the current module, like dependencies, minSdkVersion, targetSdkVersion, compileSdkVersion ^[About] , ProGuard settings ^[About] . Usually as a developer you should take care of this file.

Answer 5

Things get more clear when you have multi project module, then differences of module vs project gradle are more clear.

You can use project gradle for defining required classpaths, plugins, source repositories (google, maven etc) to fetch dependencies from and module level Gradle with respective dependencies with top-level module having signing info, version details, build types, product flavours etc . Further lower-level modules mostly are concerned with the dependencies needed wrt that particular module, so in general we just use lower modules's build gradle for adding specific dependencies.