关于Android Studio的Gradle各项配置

Gradle 构建概览

Android 应用通常使用 Gradle 构建系统构建。在深入了解如何配置 build 之前，我们先来探索 build 背后的概念，以便您全面了解系统。

什么是 build？

构建系统会将源代码转换为可执行应用。构建通常涉及多个工具，用于分析、编译、链接和打包应用或库。Gradle 使用基于任务的方法来整理和运行这些命令。

一、Gradle基础概念

Gradle是什么

Gradle是Android项目的构建工具，支持自动化编译、依赖管理和多环境打包3。它使用Groovy或Kotlin DSL（领域特定语言）编写构建脚本。

核心文件结构

build.gradle （项目级）：定义全局构建配置和插件依赖

build.gradle （模块级）：配置当前模块的编译参数、依赖等

gradle-wrapper.properties ：指定Gradle版本和下载路径4

二、环境配置与基础操作

下载Gradle

打开Android Studio → 项目 → gradle/wrapper/gradle-wrapper.properties ，修改distributionUrl字段指定版本：

distributionUrl=https://services.gradle.org/distributions/gradle-8.4-bin.zip

如果因为网络问题可以使用国内镜像或者直接下载到本地

进入 Gradle 官网下载，网址可选下面中的任何一个：

https://services.gradle.org/distributions/

https://gradle.org/releases/

修改 gradle-wrapper.properties 文件：

设置

distributionUrl=file:///C:/Users/Administrator/Downloads/gradle-7.6-bin.zip

这样子它就会从本地下载

一方面也可以使用国内镜像下载

Gradle镜像地址：https://mirrors.cloud.tencent.com/gradle/

修改

distributionUrl=https://mirrors.cloud.tencent.com/gradle/gradle-8.0-bin.zip

华为云镜像‌

Gradle镜像地址：https://mirrors.huaweicloud.com/gradle/

配置方法同样是将distributionUrl替换为华为云的镜像地址。

其中Gradle 在构建时会优先检测本地是否存在指定的版本，如果不存在才会触发下载。具体机制如下：

---

1. Gradle Wrapper 的检测逻辑
   • 默认缓存路径：Gradle Wrapper (gradlew) 会优先检查本地缓存目录 ~/.gradle/wrapper/dists/ 是否存在项目指定的 Gradle 版本。
   • 版本匹配：如果本地缓存中存在与项目配置完全一致的 Gradle 版本（如 gradle-8.7-bin.zip），则直接使用本地文件；否则会从 gradle-wrapper.properties 中指定的 distributionUrl 下载。

---

2. 如何配置本地 Gradle 路径
   • 强制使用本地版本：在 Android Studio 中，可通过以下步骤设置：
     1. 打开 File → Settings → Build, Execution, Deployment → Gradle。
     2. 选择 Use local Gradle distribution，并指定本地 Gradle 的安装目录（例如 C:\gradle\gradle-8.7）。
   • 手动下载并替换：如果下载失败，可手动从 下载对应版本，解压后放置到 ~/.gradle/wrapper/dists/ 对应子目录中，Gradle 会自动识别。

---

3. 离线模式与网络行为控制
   • 离线模式：通过命令行添加 --offline 参数（如 gradlew build --offline），强制 Gradle 仅使用本地缓存，避免联网下载。
   • 代理或镜像配置：若需从网络下载，可通过修改 init.gradle 文件配置国内镜像（如阿里云）加速下载。

---

4. 常见问题与解决
   • 版本不一致报错：若本地版本与项目配置的 Gradle 版本不匹配，需修改 gradle-wrapper.properties 中的 distributionUrl 或更新项目配置。
   • 缓存损坏：删除 ~/.gradle/wrapper/dists/ 下的对应版本目录，重新触发下载。

---

通过上述机制，Gradle 在保证版本一致性的同时，兼顾了灵活性和网络问题的容错能力。

distributionBase=GRADLE_USER_HOME distributionPath=wrapper/dists

distributionUrl=https://services.gradle.org/distributions/gradle-8.9-bin.zip

networkTimeout=10000 validateDistributionUrl=true

zipStoreBase=GRADLE_USER_HOME zipStorePath=wrapper/dists

以下是 gradle-wrapper.properties 文件各配置项的含义解析：

1. distributionBase=GRADLE_USER_HOME

   • 作用：定义 Gradle 解压后的主存储目录。默认值为 GRADLE_USER_HOME，即用户目录下的 .gradle 文件夹（如 C:\Users\用户名\.gradle）。
   • 示例：如果未修改，解压后的 Gradle 文件会存放在 .gradle/wrapper/dists 目录下。

2. distributionPath=wrapper/dists

   • 作用：指定 Gradle 解压后的子目录路径。结合 distributionBase，完整路径为：
     <distributionBase>/<distributionPath>（如 .gradle/wrapper/dists）。

3. distributionUrl=...

   • 作用：定义 Gradle 分发包的下载地址。可以是远程 URL 或本地路径：
     • 远程地址：如 https://services.gradle.org/distributions/gradle-8.9-bin.zip 会从官方服务器下载。
     • 本地路径：若改为 file:///路径/gradle-8.9-bin.zip，则直接使用本地文件（避免下载）。
   • 注意事项：若下载失败，可替换为国内镜像（如阿里云）或手动下载后配置本地路径。

4. networkTimeout=10000

   • 作用：设置网络请求超时时间（单位：毫秒）。此处为 10 秒，超过时间未完成下载会报错。

5. validateDistributionUrl=true

   • 作用：是否验证 distributionUrl 的有效性。若设为 false，即使 URL 无效也会跳过检查（不推荐）。

6. zipStoreBase=GRADLE_USER_HOME

   • 作用：定义下载的 Gradle 压缩包（.zip）存储的主目录，默认同 distributionBase（即 .gradle 目录）。

7. zipStorePath=wrapper/dists

   • 作用：指定压缩包的存储子目录路径。完整路径为：
     <zipStoreBase>/<zipStorePath>。

---

常见问题与解决建议

1. 下载速度慢或失败：

   • 修改 distributionUrl 为国内镜像（如阿里云 https://mirrors.aliyun.com/gradle/...）。
   • 手动下载 Gradle 包并配置本地路径（如 file:///D:/gradle-8.9-bin.zip）。

2. 文件权限问题：

   • 确保 .gradle 目录有写入权限，避免因权限不足导致解压失败。

3. 版本兼容性：

   • 检查 Gradle 版本是否与项目要求的插件版本兼容，避免构建错误。

如需进一步调试，可运行 ./gradlew --stacktrace 查看详细错误日志。

三、Gradle配置使用

AndroidStudio中的Gradle

在AndroidStudio中的Gradle主要使用2个对象：

build.gradle 对应 Project对象

setting.gradle 对应 Setting对象

1，Setting.gradle

这个 settings.gradle 配置文件是 Gradle 项目中用来定义项目结构和插件管理的部分，尤其是当项目中涉及多个子项目（multi-module）时，它会对整个项目的构建和依赖管理做一些配置。

我们来逐行分析这个文件，帮助你全面理解它的作用和配置项。

---

🧠 文件整体结构

pluginManagement {
    repositories {
        google {
            content {
                includeGroupByRegex("com\\.android.*")
                includeGroupByRegex("com\\.google.*")
                includeGroupByRegex("androidx.*")
            }
        }
        mavenCentral()
        gradlePluginPortal()
    }
}

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.name = "My Application"
include ':app'

🔸 pluginManagement {}

这个部分定义了如何获取 Gradle 插件，尤其是在多模块项目中或是有定制插件的情况下非常有用。它实际上告诉 Gradle 在构建过程中需要从哪里获取插件。

pluginManagement {
    repositories {
        google {
            content {
                includeGroupByRegex("com\\.android.*")
                includeGroupByRegex("com\\.google.*")
                includeGroupByRegex("androidx.*")
            }
        }
        mavenCentral()
        gradlePluginPortal()
    }
}

• pluginManagement ：用于定义插件管理的配置，这部分是告诉 Gradle 到哪些仓库去找 插件 （例如 com.android.tools.build:gradle）。
• repositories ：配置用于获取插件的仓库。
  • google() ：从 Google 的仓库拉取插件。通常这是 Android 插件（如 com.android.tools.build:gradle）的来源。
    • content {}：这个部分通过 includeGroupByRegex 设置了拉取插件时的过滤条件，只会获取符合正则表达式的插件。例如，com.android.*、com.google.* 和 androidx.* 都会被纳入搜索范围。
  • mavenCentral()：Maven 中央仓库，适用于其他插件或库。
  • gradlePluginPortal()：这是 Gradle 官方插件的默认仓库，适用于一般的插件。

🔧 这种做法的好处是，只会从特定的仓库拉取特定的插件，避免不必要的依赖冲突。

---

🔸 dependencyResolutionManagement {}

这个部分用于管理 项目依赖 的解析方式，它可以控制如何拉取依赖、哪些仓库可以用等等。主要影响 所有模块的依赖解析策略。

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}

• repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)：

  • 这行的作用是控制当 Gradle 搜索依赖时，是否允许从项目本地仓库拉取依赖 。如果设为 FAIL_ON_PROJECT_REPOS，则意味着如果本地项目中有任何依赖仓库，它会报错，要求只能从官方仓库拉取。
  • FAIL_ON_PROJECT_REPOS ：如果有任何模块在本地配置了自己的仓库，Gradle 会抛出错误，要求使用标准仓库。常见的标准仓库就是 Google 和 Maven Central。

• repositories {}：

  • 这里列出了两个常用的依赖仓库：
    • google()：Google 官方仓库，通常用于 Android 相关依赖。
    • mavenCentral()：Maven 中央仓库，适用于所有通用 Java 或 Kotlin 库。

---

🔸 rootProject.name = "My Application"

这一行指定了 根项目的名称。

rootProject.name = "My Application"

• rootProject.name 用于定义项目的根名称，通常在多模块项目中使用。这个名称会出现在构建输出的日志中以及生成的构建报告中。
• 为什么需要指定根项目名称？ ：
  • 这是一个标识符，帮助 Gradle 明确标识和识别这个项目，特别是在多模块项目中，方便管理和构建。

---

🔸 include ':app'

这一行告诉 Gradle 包含一个名为 app 的子模块。

include ':app'

• include ':app' ：这是一个 多模块项目（multi-module project） 中常见的配置，表示这个项目有一个子模块 :app，它是根项目的一部分。这个子模块通常包含应用的主代码。
• 子模块 的定义可以有多个，通常这种配置出现在需要将项目拆分为多个独立模块的情况下。

💡 扩展：如果项目有更多的子模块，可以这样写：

include ':app', ':library', ':network'

---

🧩 组合起来的效果

这个配置文件做了以下几件事情：

1. 插件管理：定义了从哪些仓库获取 Gradle 插件，并且使用正则表达式过滤插件来源（如 Google、AndroidX、Google）。
2. 依赖解析管理 ：明确要求 Gradle 只从 Google 和 Maven Central 拉取依赖，且如果有本地仓库（projectRepos），则构建失败，防止依赖来源不明。
3. 项目名称 ：将根项目的名称设置为 "My Application"，方便识别。
4. 多模块 ：将 :app 模块作为根项目的一部分包含在内，说明这是一个多模块构建项目。

---

🎯 总结

• pluginManagement 配置插件仓库和插件获取策略。
• dependencyResolutionManagement 配置项目的依赖解析方式，确保依赖从官方仓库获取，避免本地仓库问题。
• rootProject.name 设置了项目名称。
• include ':app' 表示项目包含一个名为 app 的子模块，适用于多模块项目。

---

在国内可能会遇到的问题，就是网络问题，导致我们没法正常下载到所需的插件和以来，因而我们通常会添加镜像源

pluginManagement {
    repositories {
        google() // Google仓库，主要用于 Android 相关的插件
        mavenCentral() // Maven 中央仓库
        gradlePluginPortal() // Gradle 官方插件仓库

        // 阿里云 Maven 镜像
        maven { url 'https://maven.aliyun.com/repository/public' }

        // 腾讯云 Maven 镜像
        maven { url 'https://mirrors.cloud.tencent.com/nexus/repository/maven-public/' }

        // 华为云 Maven 镜像
        maven { url 'https://mirrors.huaweicloud.com/repository/maven/' }
    }
}

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) // 只允许使用官方仓库
    repositories {
        google() // Google仓库，适用于Android相关依赖
        mavenCentral() // Maven中央仓库
        maven { url 'https://maven.aliyun.com/repository/public' } // 阿里云仓库
        maven { url 'https://mirrors.cloud.tencent.com/nexus/repository/maven-public/' } // 腾讯云仓库
        maven { url 'https://mirrors.huaweicloud.com/repository/maven/' } // 华为云仓库
    }
}

rootProject.name = "My Application"
include ':app'

🧠 Maven 是什么意思？

Maven 是一个构建和依赖管理工具，最常用于 Java 项目。它通过 POM (Project Object Model) 文件来管理项目的构建、依赖、插件等。Maven 还提供了中央仓库（Maven Central）来存储常用的库和构建插件，Gradle 就是利用 Maven 仓库来获取依赖的。

问题

Maven可以放到前面吗？他们搜寻插件的顺序是怎么样的？

🏗️ 插件仓库的搜索顺序：

Gradle 中插件仓库的搜索顺序是非常重要的，它决定了 Gradle 会先在哪些仓库中查找插件和依赖。如果你把 maven 放到前面，它会优先搜索这些仓库。

在 pluginManagement 中定义的 仓库顺序 确定了 Gradle 在构建时查找插件的先后顺序。先定义的仓库会被优先搜索。

🎯 搜索顺序规则：

1. 按顺序搜索 ：Gradle 会按照 pluginManagement.repositories 中仓库的出现顺序来搜索插件。

   • 先定义的仓库会优先被搜索。

2. 仓库优先级：

   • Google仓库 ：通常优先配置，因为它包含了 Android 构建相关的插件（比如 com.android.application 等）。
   • Maven Central：是很多 Java 和 Android 库的默认仓库。
   • 自定义仓库（如 阿里云、腾讯云、华为云）：这些可以在国内加速插件的下载，尤其在国内网络环境下，它们比 Google 和 Maven 中央仓库的访问速度更快。

---

🧑‍💻 示例配置 - 放在前面：

如果你希望将 Maven 镜像仓库 放在 最前面，确保它优先被搜索，可以像下面这样配置：

pluginManagement {
    repositories {
        // 先配置国内镜像源
        maven { url 'https://mirrors.cloud.tencent.com/nexus/repository/maven-public/' }
        maven { url 'https://maven.aliyun.com/repository/public' }
        maven { url 'https://mirrors.huaweicloud.com/repository/maven/' }

        // 然后配置 Google 和 Maven 中央仓库
        google {
            content {
                includeGroupByRegex("com\\.android.*")
                includeGroupByRegex("com\\.google.*")
                includeGroupByRegex("androidx.*")
            }
        }
        mavenCentral()
        gradlePluginPortal()
    }
}

📌 详细说明：

1. Maven 镜像源优先：国内的 Maven 镜像源（腾讯云、阿里云、华为云）会被最先搜索，如果插件在这些源中找到，Gradle 就会直接使用。
2. Google 和 Maven 中央仓库：如果在上面的 Maven 镜像源中没有找到，Gradle 会继续搜索 Google 和 Maven Central。

这种方式特别适合中国大陆用户，因为它们的访问速度更快，可以减少因访问国外仓库慢而导致的构建时间延迟。

⚡ 总结：

• Gradle 会按顺序搜索配置的仓库，先定义的仓库会优先被搜索。
• 如果你把 Maven 仓库放到前面，它会优先搜索这些仓库。
• 配置国内的镜像仓库（如腾讯云、阿里云、华为云）通常可以提升下载速度，特别是在国内环境下。

希望这样解释清楚了！如果还有其他问题，随时告诉我～ 💡

2，Build.gradle

项目级 build.gradle 和 模块级 build.gradle 的配置详解

Gradle 构建系统采用分层结构，项目级（project-level）和模块级（module-level）build.gradle 文件各自承担不同的责任。项目级的 build.gradle 主要用来配置全局构建设置、插件和依赖库，而模块级的 build.gradle 则负责定义与具体应用或库相关的构建过程、依赖关系和任务。

一、项目级 build.gradle 配置详解

项目级 build.gradle 是整个 Gradle 构建系统的入口，通常用于设置全局插件和仓库，并管理与项目相关的通用配置。

1. 主要功能：

• 定义构建脚本所需要的插件。
• 配置全局仓库，例如 JCenter、MavenCentral 等。
• 管理所有模块的共用依赖版本。
• 配置全局的 Gradle 版本。

2. 示例代码：

// 项目级 build.gradle 文件
buildscript {
    // 定义构建脚本依赖和仓库
    repositories {
        google()       // 使用 Google Maven 仓库
        mavenCentral() // 使用 Maven Central 仓库
    }
    
    dependencies {
        // 定义构建工具的依赖，通常是 Android Gradle 插件
        classpath 'com.android.tools.build:gradle:8.5'  // Android Gradle 插件的版本
    }
}

allprojects {
    // 所有子项目都会使用这些仓库
    repositories {
        google()       // 使用 Google Maven 仓库
        mavenCentral() // 使用 Maven Central 仓库
    }
}

// 配置根项目的属性，比如设置项目名称
rootProject.name = "MyApplication" // 根项目的名称

// 指定需要包含的模块
include ':app' // 包含子模块，通常是应用模块

3. 解释：

• buildscript ：用于配置构建脚本所需的插件依赖和仓库地址。通常用于配置像 com.android.tools.build:gradle 这样的插件依赖。
• allprojects：定义所有项目（即包括子模块）都会使用的仓库地址。在这里配置的仓库会被传递到每个模块中。
• rootProject.name：指定项目的根目录名称，通常与实际的文件夹名一致。
• include ':app' ：配置需要包含的子模块，这里是 :app 模块。实际应用中可能会有多个模块。

---

二、模块级 build.gradle 配置详解

模块级 build.gradle 文件负责具体模块的构建过程。在这个文件中，你可以配置 Android 特有的构建选项，如 android 配置块、构建类型、依赖关系等。

1. 主要功能：

• 配置 Android 特有的构建设置（如 SDK 版本、构建类型、Flavors 等）。
• 定义模块的具体依赖关系。
• 设置构建任务和自定义任务。

2. 示例代码：

// 模块级 build.gradle 文件
apply plugin: 'com.android.application' // 应用 Android 应用插件

android {
    compileSdkVersion 33 // 设置编译 SDK 版本

    defaultConfig {
        applicationId "com.example.myapp"  // 设置应用的 ID
        minSdkVersion 21                   // 设置最低支持的 SDK 版本
        targetSdkVersion 33                // 设置目标 SDK 版本
        versionCode 1                      // 设置应用的版本号
        versionName "1.0.0"                // 设置应用的版本名称
    }

    buildTypes {
        release {
            minifyEnabled true  // 开启代码压缩和混淆
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
        debug {
            debuggable true    // 启用调试模式
        }
    }

    productFlavors {
        free {
            applicationIdSuffix ".free"  // 免费版应用的 ID 后缀
            versionNameSuffix "-free"    // 免费版版本名称后缀
        }
        paid {
            applicationIdSuffix ".paid"  // 付费版应用的 ID 后缀
            versionNameSuffix "-paid"    // 付费版版本名称后缀
        }
    }
}

dependencies {
    // 配置模块所需的依赖
    implementation 'com.android.support:appcompat-v7:28.0.0'  // 引入 Android 支持库
    implementation 'com.squareup.retrofit2:retrofit:2.9.0'   // 引入 Retrofit 库进行网络请求
    testImplementation 'junit:junit:4.13.2'  // 引入 JUnit 库进行单元测试
}

3. 解释：

• apply plugin: 'com.android.application' ：应用 Android 应用插件，表示该模块是一个 Android 应用。若是 Android 库，则应使用 com.android.library 插件。
• android ：此配置块包含了与 Android 构建相关的设置，如 compileSdkVersion（编译 SDK 版本）、defaultConfig（默认配置），以及 buildTypes 和 productFlavors（构建类型和产品风味）。
• buildTypes ：定义不同构建类型的配置，常见的有 debug 和 release。每个构建类型可以有不同的设置，如混淆、压缩等。
• productFlavors：定义不同版本的应用，例如免费版和付费版。可以在此配置不同版本的 ID、版本号等。
• dependencies ：定义该模块所需要的库依赖。可以使用 implementation、api、testImplementation 等关键字来指定依赖类型。

---

三、如何理解项目级和模块级的 Gradle 配置

1. 项目级 build.gradle 文件：

• 负责配置与所有模块共用的设置，如全局的仓库、插件依赖等。
• 例如：配置项目级的仓库（Google、Maven Central），和所有模块共用的构建工具依赖（如 Android Gradle 插件）。

2. 模块级 build.gradle 文件：

• 负责定义每个模块（如 app 模块）特有的构建配置，包括 Android SDK 版本、构建类型、依赖关系等。
• 例如 ：compileSdkVersion、minSdkVersion、dependencies 等配置都是模块特有的。

四、项目级和模块级配置的作用及优先级

• 项目级 build.gradle ：通常是所有模块的全局配置，负责配置 构建脚本 以及 所有模块的共用依赖，如仓库地址、插件版本等。
• 模块级 build.gradle ：负责模块具体的构建配置，通常涉及 与特定模块相关的设置，如 SDK 版本、构建类型、依赖关系等。

如果在项目级和模块级 build.gradle 中有重复配置，通常 模块级配置会覆盖项目级配置。例如：

• 在项目级配置了全局的仓库，但模块级如果重新定义了不同的仓库地址，那么模块级配置会优先使用。
• 项目级 dependencies 可以配置全局依赖，但具体模块也可以定义自己的依赖。

---

结论

Gradle 的 项目级 和 模块级 配置各自承担不同的任务：

• 项目级：配置全局的构建脚本、仓库、插件等。
• 模块级：配置特定模块的 SDK 版本、构建类型、依赖关系等。

这种分层配置的结构，使得多个模块可以独立管理，同时也能保证项目整体的一致性和灵活性。

如果 Gradle 使用的是较老的 TLS 协议版本，目标服务器（如 Google Maven 仓库）可能不再支持该协议。解决方案包括：

检查服务器配置：确保 Gradle 能够与仓库建立安全连接，并且仓库支持 TLS 1.2 或更高版本。

尝试不同的仓库源：您可以临时替换或添加其他仓库源，确保 Gradle 能够访问到依赖。

groovy

复制

编辑

repositories {

maven { url 'https://dl.google.com/dl/android/maven2/' }

maven { url 'https://repo.maven.apache.org/maven2/' }

maven { url 'https://jcenter.bintray.com/' } // 添加备用仓库源

}

Gradle 构建系统采用了分层的配置结构，使得可以根据不同的需求在不同的层次（项目级 和模块级 ）配置构建选项。项目级 build.gradle 和模块级 build.gradle 在功能上有不同的作用，某些配置只允许在模块级的 build.gradle 中进行，而不能在项目级 build.gradle 中进行。下面是一些常见的配置差异以及它们的作用。

1. 构建类型（Build Types）

• 不能在项目级配置 ：buildTypes 仅适用于模块级 build.gradle 文件，指定不同构建类型（如 debug 和 release）的配置。项目级配置无法设置 buildTypes，它是 模块特定的。
• 模块级配置 ：
  • 用来定义不同的构建类型（例如，debug 和 release）。
  • 用于配置构建类型相关的选项，如 ProGuard、R8 混淆、签名、构建优化等。

示例（模块级 build.gradle）：

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
        debug {
            debuggable true
        }
    }
}

2. Flavors（构建风味）

• 不能在项目级配置 ：productFlavors 也是模块级配置，用于创建多个不同版本的应用（例如，免费版和付费版），可以定义不同的 API 密钥、资源文件、代码库等。它与模块级的 buildTypes 配合使用，允许你在不同的构建风味和构建类型之间创建多个组合。
• 模块级配置 ：
  • 配置不同的产品风味，可以用于构建多个应用变体。
  • 主要用于为不同用户群体定制应用，具有不同的资源、功能或依赖。

示例（模块级 build.gradle）：

android {
    productFlavors {
        free {
            applicationId "com.example.myapp.free"
            versionName "1.0-free"
        }
        paid {
            applicationId "com.example.myapp.paid"
            versionName "1.0-paid"
        }
    }
}

3. 签名配置（Signing Configs）

• 不能在项目级配置 ：签名配置 signingConfigs 必须在模块级 build.gradle 文件中定义。项目级 build.gradle 文件不能直接配置签名信息，因为签名是与模块级构建过程相关的。
• 模块级配置 ：
  • 用于定义构建时如何对 APK 或 AAB 进行签名。
  • 只有在模块级构建过程中需要应用签名时，才会使用签名配置。

示例（模块级 build.gradle）：

android {
    signingConfigs {
        release {
            storeFile file("release.keystore")
            storePassword "password"
            keyAlias "myKey"
            keyPassword "password"
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

4. 资源与依赖配置

• 模块级才可以配置 ：虽然在项目级 build.gradle 中可以声明全局仓库和依赖（例如通过 allprojects），但每个模块级 build.gradle 才能配置具体的资源、依赖版本等。
  • dependencies ：项目级 build.gradle 只能配置全局依赖，不能为单个模块配置特定的依赖版本。
  • 模块级配置 ：每个模块的 build.gradle 可以根据其功能需求，指定它的依赖、版本等。

示例（模块级 build.gradle）：

dependencies {
    implementation 'com.squareup.retrofit2:retrofit:2.9.0'
    implementation 'com.google.dagger:dagger:2.34.0'
}

5. 构建脚本插件的应用

• 不能在项目级配置 ：apply plugin 和 plugins 配置是用于应用特定的构建插件。项目级 build.gradle 文件可以定义 classpath 来配置插件，但每个模块的 build.gradle 文件才是 实际应用插件 的地方。例如，apply plugin: 'com.android.application' 应该在模块级 build.gradle 中配置，而不是项目级 build.gradle。

示例（模块级 build.gradle）：

apply plugin: 'com.android.application'

android {
    compileSdkVersion 30
    defaultConfig {
        applicationId "com.example.myapp"
        minSdkVersion 21
        targetSdkVersion 30
    }
}

6. Android 构建配置（Android Block）

• 不能在项目级配置 ：整个 android 配置块只对模块级 build.gradle 文件有效。你不能在项目级 build.gradle 文件中配置 compileSdkVersion、defaultConfig 等 Android 构建设置。这些配置必须在每个模块的 build.gradle 文件中定义。
• 模块级配置 ：模块的构建配置与 Android 的 SDK 版本、构建类型、版本号、资源管理等密切相关，必须在模块级 build.gradle 中进行。

示例（模块级 build.gradle）：

android {
    compileSdkVersion 30

    defaultConfig {
        applicationId "com.example.myapp"
        minSdkVersion 21
        targetSdkVersion 30
    }
}

7. 任务配置（Custom Tasks）

• 不能在项目级配置 ：虽然在项目级 build.gradle 文件中可以定义通用的任务（例如，clean 任务），但是某些特定于模块的任务配置只能在模块级 build.gradle 中进行。
• 模块级配置 ：模块级 build.gradle 配置可以用于定义模块特定的任务，例如构建 APK 或 AAB 时，某些模块的构建过程可能需要特定的任务。

示例（模块级 build.gradle）：

task customTask {
    doLast {
        println 'This is a custom task for the module!'
    }
}

8. 插件的应用顺序

• 项目级配置 ：项目级 build.gradle 可以配置插件，但它主要用于应用构建相关的插件（如 com.android.application、com.android.library 等），并且定义插件版本。
• 模块级配置 ：模块级 build.gradle 才是实际 应用插件 的地方。项目级 build.gradle 配置的是 插件的版本与来源，而具体应用插件的任务和设置则需要在模块级配置。

🔧 总结：哪些配置是项目级 build.gradle 不能配置而模块级可以配置的

• buildTypes 和 productFlavors ：与构建类型、风味相关的配置只能在模块级 build.gradle 配置。
• 签名配置（signingConfigs）：签名配置在模块级定义。
• Android 构建配置（android） ：例如 compileSdkVersion、minSdkVersion、defaultConfig 等。
• 模块特定的依赖配置 ：如 dependencies，每个模块的依赖应该在各自的 build.gradle 中配置。
• 插件的应用 ：apply plugin 和 plugins 只在模块级配置，项目级 build.gradle 主要配置插件版本和来源。

这些设计能够使得 项目级和模块级配置的分离 ，提升 灵活性 和 可维护性。每个模块可以有自己独立的构建配置，而项目级则负责统一的构建管理和版本控制。

在 Gradle 中，不同模块使用不同的 SDK 或 Gradle 版本的情况是一个常见的需求，尤其是在复杂的 Android 项目中。有时我们希望某些模块使用特定的 SDK 版本、Gradle 插件版本，或者依赖不同的配置。这种情况下，我们需要理解 Gradle 和 Android 的版本管理机制，来确保不同模块之间的兼容性。

📍 1. 不同模块使用不同的 Gradle 版本

每个 Android 项目（或者更一般的 Java 项目）只有一个 全局的 Gradle 版本 ，它通常在根项目的 gradle-wrapper.properties 中配置：

# gradle-wrapper.properties
distributionUrl=https\://services.gradle.org/distributions/gradle-7.0-bin.zip

Gradle 版本 是 全局统一的，所有模块都必须使用这个版本。无法在单独的模块中指定不同的 Gradle 版本。

🤔 那么如果我在多个模块中需要不同的 Gradle 版本怎么办？

• 解决方案 ：你可以在 不同的项目 中使用不同的 Gradle 版本。也就是说，如果你有多个项目，你可以在每个项目的 gradle-wrapper.properties 中指定不同的 Gradle 版本。
• 但在 同一个项目 中，Gradle 版本必须统一。如果你需要在不同模块中使用不同的构建工具版本，通常是通过 插件版本（例如 Android Gradle 插件版本）来解决。

📍 2. 不同模块使用不同的 Android SDK 版本

每个模块都可以独立地配置自己的 SDK 版本 ，不会有冲突。SDK 版本配置是在每个模块的 build.gradle 文件中的 android 块里设置的。不同模块的 SDK 配置是 独立的，它们不会相互干扰。

示例：

假设你有两个模块：moduleA 和 moduleB，它们的 build.gradle 可以分别配置不同的 SDK 版本。

moduleA 的 build.gradle：

android {
    compileSdkVersion 33  // moduleA 使用 compileSdkVersion 33
    defaultConfig {
        minSdkVersion 21
        targetSdkVersion 33
    }
    ...
}

moduleB 的 build.gradle：

android {
    compileSdkVersion 30  // moduleB 使用 compileSdkVersion 30
    defaultConfig {
        minSdkVersion 19
        targetSdkVersion 30
    }
    ...
}

在这种情况下，moduleA 和 moduleB 会各自使用它们自己指定的 SDK 版本 不会冲突 。每个模块的 compileSdkVersion、minSdkVersion 和 targetSdkVersion 都是独立的。

📍 3. 如何处理插件版本（如 Android Gradle 插件）？

• 插件版本也是全局的 ：通常来说，项目的根级 build.gradle 中定义了 Android Gradle 插件的版本。例如：

buildscript {
    repositories {
        google()
        mavenCentral()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:7.0.4'  // Android Gradle 插件版本
    }
}

所有模块都会使用这个插件版本，不能在每个模块中单独定义不同版本的插件 。这就意味着 Android Gradle 插件版本是 统一的，但你可以根据需要通过配置不同的模块来使用不同的 Android SDK 版本（如前所述）。

📍 4. Gradle 插件和依赖冲突问题

尽管不同模块可以独立配置 SDK 版本，但 依赖管理 仍然需要注意版本兼容性。如果不同模块使用的依赖版本不同，可能会导致 冲突 ，这种情况下 Gradle 会尝试 选择一个兼容的版本，或者你可以手动强制使用某个版本。

示例：依赖冲突

// moduleA 的 build.gradle
dependencies {
    implementation 'com.google.dagger:dagger:2.28.3'
}

// moduleB 的 build.gradle
dependencies {
    implementation 'com.google.dagger:dagger:2.34.0'  // 不同版本的 Dagger
}

在这种情况下，Gradle 会尽量选择兼容的版本。你也可以通过 resolutionStrategy 来强制使用某个版本：

configurations.all {
    resolutionStrategy {
        force 'com.google.dagger:dagger:2.34.0'  // 强制使用 2.34.0 版本
    }
}

⚡ 总结：

• Gradle 版本：同一个项目中，Gradle 版本必须统一，无法在不同模块中使用不同的 Gradle 版本。
• SDK 版本 ：不同模块可以配置不同的 SDK 版本（compileSdkVersion、minSdkVersion、targetSdkVersion），这些配置是模块级的，不会相互冲突。
• 插件版本：Android Gradle 插件版本是全局统一的，同一个项目中所有模块使用相同的插件版本。
• 依赖管理 ：不同模块的依赖版本可能会冲突，Gradle 会尝试解决版本冲突，你也可以通过 resolutionStrategy 强制使用某个版本。

通过这些配置，Gradle 使得多个模块能够独立配置自己的 SDK 版本和依赖，确保每个模块有自己独立的构建配置。

如果你有更深入的问题或想要具体的配置实例，随时告诉我！ 😎

🔧 configurations.all 配置的位置

configurations.all 配置通常用于 解决 Gradle 依赖冲突 ，它可以在 项目级 或 模块级 build.gradle 文件中的 dependencies 块外部进行配置，用于指定某些依赖的版本强制要求。常见的用法是 强制指定某个依赖的版本，以避免由于版本冲突导致的构建错误或不一致的行为。

🏗️ 1. 配置位置：

你可以将 configurations.all 配置放在：

• 项目级 build.gradle：全局配置，适用于整个项目中的所有模块。
• 模块级 build.gradle：仅影响该模块及其直接依赖的模块。

📍 2. 在项目级 build.gradle 中配置：

如果你想让整个项目的所有模块都强制使用特定版本的依赖，可以将 configurations.all 配置放到 项目级的 build.gradle 中。例如，通常这个配置会放在 allprojects 或 subprojects 块内。

// 项目级 build.gradle 示例
allprojects {
    repositories {
        google()
        mavenCentral()
    }

    configurations.all {
        resolutionStrategy {
            force 'com.google.dagger:dagger:2.34.0'  // 强制所有模块使用 Dagger 2.34.0 版本
        }
    }
}

这种配置会使得 项目中所有模块 使用 Dagger 2.34.0 版本，而无论哪个模块声明了 Dagger 的不同版本。

📍 3. 在模块级 build.gradle 中配置：

如果你只想影响某个模块或某个模块的依赖冲突处理，可以将 configurations.all 配置放在模块级 build.gradle 文件中：

// 模块级 build.gradle 示例
dependencies {
    implementation 'com.google.dagger:dagger:2.28.3'  // moduleA 依赖了较旧的 Dagger 版本
}

configurations.all {
    resolutionStrategy {
        force 'com.google.dagger:dagger:2.34.0'  // 强制该模块使用 Dagger 2.34.0 版本
    }
}

这种配置仅会影响当前模块及其直接依赖的模块，确保它们都使用指定的 Dagger 2.34.0 版本。

📍 4. 在 subprojects 中配置：

如果你的项目是多模块的，你可能想要在所有子项目中应用相同的版本强制策略。你可以在 subprojects 块内配置：

// 项目级 build.gradle 示例
subprojects {
    configurations.all {
        resolutionStrategy {
            force 'com.google.dagger:dagger:2.34.0'  // 强制所有子项目使用 Dagger 2.34.0 版本
        }
    }
}

🎯 resolutionStrategy 的作用：

resolutionStrategy 是 Gradle 中的一个强大的功能，可以帮助你解决依赖冲突和版本不一致的问题。通过使用 force，你可以强制 Gradle 在版本冲突时使用特定版本的依赖。

🧑‍💻 常见的 resolutionStrategy 使用场景：

• 强制某个依赖使用特定版本（如上例所示）
• 更改依赖的版本范围 ：比如指定 version 或者排除某些依赖的冲突
• 动态版本处理：例如处理某些版本间的依赖替换

configurations.all {
    resolutionStrategy {
        // 强制使用特定版本
        force 'com.google.dagger:dagger:2.34.0'
        
        // 也可以排除某个模块，避免它冲突
        eachDependency { details ->
            if (details.requested.group == 'com.google.dagger') {
                details.useVersion '2.34.0'  // 如果 Dagger 是 2.x 系列中的版本，强制使用 2.34.0
            }
        }
    }
}

---

⚡ 总结：

• configurations.all 配置可以放在项目级或模块级的 build.gradle 中，用于 全局处理依赖版本冲突。
• 如果你在 项目级 build.gradle 中配置，它会影响 所有模块。
• 如果在 模块级 build.gradle 中配置，它只会影响当前模块及其直接依赖的模块。
• resolutionStrategy 用于解决依赖冲突，特别适合在项目中强制指定某个版本的依赖。

这种配置方式非常适合在多个模块中管理共享的依赖版本，尤其是在项目中存在版本不一致时，能够确保整个项目的一致性。