Android Gradle Series - Advanced articles

Last article we have introduced the use Gradle base again, so to speak, as long as you have read my Gradle this series, then your Gradle will cross the border, has been developed to deal with the normal work is not a problem.

I would like to introduce you to this article is about how to use Gradle dependencies between more elegant management of multiple module.

I am sure you have this experience: the main project depends on multiple sub-projects, projects or inter-dependent on each other. Third-party library version dependencies between different sub-projects has not been uniform, a version upgrade of all dependent projects should be modified; even minSdkVersion and targetSdkVersion not the same.

Today we'll solve this problem, let Gradle more elegant version management.

Google Recommended

Previous article Android Gradle series - use articles in dependencies using the basic reference. If you have a new project kotlin experience, then you will see Google-recommended solutions

buildscript {
    ext.kotlin_version = '1.1.51'
    repositories {
        google()
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.0.0'
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}
复制代码

In build.gradle rootProject in ext to define the version number of global variables. So that we can directly reference these defined variables in build.gradle module's. Reference as follows:

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation"org.jetbrains.kotlin:kotlin-stdlib-jre7:$kotlin_version"
}
复制代码

You can use these variables java understood as a static variable. In this way, the configuration can achieve unity in a different module, but the limitation is that a configuration but too many entries, all configurations will be written build.gradle rootProject project, resulting in build.gradle bloated. This is not in line with our module development advocated, so you should think of ways to configure separate out ext.

This time before I have to use the article Android Gradle series - Principle chapter apply functions described. Previous article, we use the plugin only apply one of the three cases (a plug-in application, by id or class name), only in build.gradle subproject.

apply plugin: 'com.android.application'
复制代码

This time we need to use it from , it is primarily the role of application a script file . The next action we need to do is to put a gradle ext configure a separate script file.

First we create a script file gradle in rootProject directory, I have here named version.gradle.

Then we define the variables used in version.gralde file ext. For example kotlin previous version you can use the following manner

ext.deps = [:]
 
def versions = [:]
versions.support = "26.1.0"
versions.kotlin = "1.2.51"
versions.gradle = '3.2.1'
 
def support = [:]
support.app_compat = "com.android.support:appcompat-v7:$versions.support"
support.recyclerview = "com.android.support:recyclerview-v7:$versions.support"
deps.support = support
 
def kotlin = [:]
kotlin.kotlin_stdlib = "org.jetbrains.kotlin:kotlin-stdlib-jre7:$versions.kotlin"
kotlin.plugin = "org.jetbrains.kotlin:kotlin-gradle-plugin:$versions.kotlin"
deps.kotlin = kotlin
 
deps.gradle_plugin = "com.android.tools.build:gradle:$versions.gradle"
 
ext.deps = deps
 
def build_versions = [:]
build_versions.target_sdk = 26
build_versions.min_sdk = 16
build_versions.build_tools = "28.0.3"
ext.build_versions = build_versions
 
def addRepos(RepositoryHandler handler) {
    handler.google()
    handler.jcenter()
    handler.maven { url 'https://oss.sonatype.org/content/repositories/snapshots' }
}
ext.addRepos = this.&addRepos
复制代码

Because gradle using groovy language, so the above syntax is groovy

Kotlin example, version control, which means that the above code will have associated version dependency kotlin kotlin into the variable deps while deps placed in ext. Other true.

Since the definition Well, now we begin the introduction to the project, in order to allow all sub-projects have access to, we use apply from its introduction into the build.gradle in rootProject

buildscript {
    apply from: 'versions.gradle'
    addRepos(repositories)
    dependencies {
        classpath deps.gradle_plugin
        classpath deps.kotlin.plugin
    }
}
复制代码

Then build.gradle on the default variable ext has declared, use it as a reference dependencies of the same.

We look at the above addRepos method, the article on the principles of Gradle have analyzed the repositories will be performed by RepositoryHandler, so here we directly define a unified approach to call RepositoryHandler. So that we do not need to use the following way build.gradle, the method can be called directly addRepos

    //之前调用
    repositories {
        google()
        jcenter()
    }
    //现在调用
    addRepos(repositories)
复制代码

On the other hand, if there are multiple Module1, module1 for example, can now be directly used in the definition of module1 good configuration in build.gradle

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    // support
    implementation deps.support.app_compat
    //kotlin
    implementation deps.kotlin.kotlin_stdlib
}
复制代码

We also defined above and tools sdk version, so it can be unified together, the effect is as follows

android {
    compileSdkVersion build_versions.target_sdk
    buildToolsVersion build_versions.build_tools
    defaultConfig {
        applicationId "com.idisfkj.androidapianalysis"
        minSdkVersion build_versions.min_sdk
        targetSdkVersion build_versions.target_sdk
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    ...
}
复制代码

Once achieve a unified configuration, so then we want to amend the relevant version of it can simply modify the version.gradle our definition. No longer used for module one by one to modify the unified configuration.

BuildSrc&Kotlin

If your project uses kotlin, then buildSrc & Kotlin unified management solution will be more suitable for you.

Gradle project will identify buildSrc default directory, and will inject the directory configuration to build.gradle in that it makes build.gradle can directly reference the configuration items buildSrc.

With this feature, we can directly before version.gradle configuration to buildSrc put in, let's begin implementation.

First, create a new directory in the root directory buildSrc (with the app at the same level), then the new directory src / main / java directory, the directory is the directory where the configuration items after you; at the same time and then a new build.gradle.kts file, and the document added kotlin-dsl

plugins {
    `kotlin-dsl`
}
 
repositories {
    jcenter()
}
复制代码

After re-sync project, the final directory structure as follows

Build a good catalog, and now we use in src / main / java kotlin New Dependencies file (any file name), configuration items will be before the file is put to, just use kotlin syntax to achieve it, the following code into

object Versions {
    const val support = "26.1.0"
    const val kotlin = "1.3.31"
    const val gradle = "3.4.1"
    const val target_sdk = 26
    const val min_sdk = 16
    const val build_tools = "28.0.3"
}
 
object Dependencies {
    val app_compat = "com.android.support:appcompat-v7:${Versions.support}"
    val kotlin_stdlib = "org.jetbrains.kotlin:kotlin-stdlib-jdk7:${Versions.kotlin}"
    val kotlin_plugin = "org.jetbrains.kotlin:kotlin-gradle-plugin:${Versions.kotlin}"
    val gradle_plugin = "com.android.tools.build:gradle:${Versions.gradle}"
    val addRepos: (handler: RepositoryHandler) -> Unit = {
        it.google()
        it.jcenter()
        it.maven { url = URI("https://oss.sonatype.org/content/repositories/snapshots") }
    }
}
复制代码

Then you can directly use the Dependencies and Versions in various build.gradle cited, for example, under the app build.gradle

android {
    compileSdkVersion Versions.target_sdk
    buildToolsVersion Versions.build_tools
    defaultConfig {
        applicationId "com.idisfkj.androidapianalysis"
        minSdkVersion Versions.min_sdk
        targetSdkVersion Versions.target_sdk
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    ...
}
dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    // support
    implementation Dependencies.app_compat
    //kotlin
    implementation Dependencies.kotlin_stdlib
}
复制代码

build.gralde also true root

buildscript {
    Dependencies.addRepos.invoke(repositories)
    dependencies {
        classpath Dependencies.gradle_plugin
        classpath Dependencies.kotlin_plugin
    }
}
 
allprojects {
    Dependencies.addRepos.invoke(repositories)
}
 
task clean(type: Delete) {
    delete rootProject.buildDir
}
复制代码

In fact, we really need to get to is an idea, unified configuration management. As for the use of which in the end, this depends on personal preference, but if your project uses kotlin, I suggest you use buildSrc mode because for Groovy syntax, I believe you are still more familiar with the Kotlin.

Source Address: github.com/idisfkj/and...

If you want to know more about my article, you can scan the next Fanger Wei code, I am concerned about the number of public ~

Reproduced in: https: //juejin.im/post/5cfe4a905188250b6d63360e