秦皇岛房产局网签查询/手机网络优化软件

JDK环境配置：

1、Gradle运行时的JDK，即Gradle需要用到的JDK，配置如下：

如需修改现有项目的 Gradle JDK 配置，请依次点击 File（或者 macOS 上的 Android Studio）> Settings > Build, Execution, Deployment > Build Tools > Gradle，打开 Gradle 设置

注意：你若直接运行，则用的是这个配置的JDK，若是在Android Studio 内或外部的终端中运行 Gradle，则 JAVA_HOME 环境变量（如果已设置）决定了哪个 JDK 运行 Gradle 脚本。如果未设置 JAVA_HOME，则会对 PATH 环境变量使用 java 命令。为了获得最一致的结果，请务必将 JAVA_HOME 环境变量和这个配置设置为同一 JDK。

2、工具链 JDK 包含用于编译任何 Java 源代码的 Java 编译器。此 JDK 还会在构建期间运行 javadoc 和单元测试。 大概意思就是指定一个JDK版本，它决定了整个 Java 工具链在处理项目相关操作（如编译、生成文档、执行单元测试等）时所遵循的 Java 语言规则。

//build.gradle.kts
java {toolchain {languageVersion = JavaLanguageVersion.of(17)}
}
//build.gradle
java {toolchain {languageVersion = JavaLanguageVersion.of(17)}
}

注意：工具链默认为用于运行 Gradle 的 JDK，即不指定这个，就用Gradle配置的同一个JDK。

3、Java 源代码编译期间可用的 Java 语言功能

//build.gradle.kts
android {compileOptions {sourceCompatibility = JavaVersion.VERSION_17}
}
//build.gradle
android {compileOptions {sourceCompatibility JavaVersion.VERSION_17}
}

这个跟上面languageVersion的区别在于，范围更小，仅是编译范围。

4、为编译的 Java 和 Kotlin 源代码生成字节码时使用的 Java 类格式版本

//build.gradle.kts
android {compileOptions {sourceCompatibility = JavaVersion.VERSION_17targetCompatibility = JavaVersion.VERSION_17}kotlinOptions {jvmTarget = "17"}
}
//build.gradle
android {compileOptions {sourceCompatibility JavaVersion.VERSION_17targetCompatibility JavaVersion.VERSION_17}kotlinOptions {jvmTarget '17'}
}

targetCompatibility（针对 Java）、jvmTarget（针对 Kotlin），主要用于 Java 源代码编译后的字节码生成阶段。它决定了为 Java 源代码生成字节码时所采用的 Java 类格式版本。

个人总结：

1、编译主要是将高级编程语言（如 Java 或 Kotlin）编写的源代码转换为中间表示形式的过程，用sourceCompatibility 指定，例如，当设置为JavaVersion.VERSION_17时，编译器在编译代码过程中，会允许使用 Java 17 及以下版本所支持的所有语言功能。主要影响代码编译这一个环节，决定编译器对源代码语言功能的接受范围

2、在编译后的下一步，编译器会将解析后的源代码生成字节码。字节码是一种可以在 Java 虚拟机（JVM）上执行的中间格式。用targetCompatibility（针对 Java）、jvmTarget（针对 Kotlin）指定。 例如，设置targetCompatibility = JavaVersion.VERSION_17，生成的字节码将以 Java 17 的类格式为目标，以便在 Java 17 的 JVM 环境中顺利执行。主要涉及生成字节码的环节，决定字节码与目标 JVM 的兼容性。

3、关系：targetCompatibility必须大于或等于sourceCompatibility。这是因为编译代码时使用的语法规则（由sourceCompatibility决定）所生成的字节码，不能超过目标 JVM 能够理解的版本范围（由targetCompatibility决定）。在实际项目中，为了简单和一致性，sourceCompatibility、targetCompatibility和jvmTarget通常应该使用相同的值，这样可以确保从代码编写、编译到字节码生成和运行的整个过程都在一个统一的 Java 版本环境下进行，避免出现兼容性问题。

当languageVersion、sourceCompatibility和targetCompatibility都不指定时，Gradle 通常会默认使用运行 Gradle 的 JDK 来进行编译以及字节码生成等操作。

整体写法，例子：

//kotlin（.gradle.kts）
android {compileOptions {// 设置Java源代码编译时可用的语言功能，这里指定为Java 17sourceCompatibility = JavaVersion.VERSION_17// 设置为Java源代码生成字节码时所采用的Java类格式版本，这里为Java 17targetCompatibility = JavaVersion.VERSION_17}kotlinOptions {// 设置Kotlin编译器为Kotlin源代码生成字节码时所针对的JVM版本，这里是Java 17jvmTarget = "17"}java {toolchain {// 指定Java工具链的语言版本为Java 17，用于规范整个构建过程涉及Java工具链的操作languageVersion = JavaLanguageVersion.of(17)}}
}
//groovy(.gradle)
android {compileOptions {sourceCompatibility = JavaVersion.VERSION_17targetCompatibility = JavaVersion.VERSION_17}kotlinOptions {jvmTarget = "17"}java {toolchain {languageVersion = JavaLanguageVersion.of(17)}}
}

Android build 结构

文件夹/文件	使用
.gradle/	Gradle 项目缓存目录 由 Gradle 管理，包含下载的 Gradle 发行版、项目缓存和配置文件。 请勿更改此目录中的文件！
.idea/	Android Studio 项目元数据 请勿更改此目录中的文件！
build.gradle(.kts)	根 build 文件 应仅包含用于设置跨子项目通用插件类路径的插件声明。 其他代码应位于设置或嵌套项目级 build 文件中。
gradle.properties	Gradle 执行配置 包含 Gradle 属性，用于控制 Gradle 构建环境方面，例如堆大小、缓存和并行执行。 此处定义了一些临时的 Android 属性，以便在添加和移除 AGP DSL 时减少对 AGP DSL 的更改。
gradlew（Linux、Mac） gradlew.bat（适用于 Windows）	Gradle 封装容器文件 通过下载 Gradle 发行版并将命令转发给它来引导 build。这样一来，您无需预安装 Gradle 即可运行构建。
local.properties	本地机器配置 包含与本地计算机相关的属性，例如 Android SDK 的位置。 从源代码控制系统中排除此文件！
settings.gradle(.kts)	Gradle build 初始化 包含 Gradle 初始化和项目配置的全局构建信息，例如 项目名称 要包含在此 build 中的子项目的列表 用于查找插件和依赖项的仓库规范 外部版本目录导入。
gradle/
☐ libs.versions.toml	版本目录 定义 build 中使用的依赖项和插件的变量。您可以在此处指定要使用的版本，以确保项目中的所有子项目之间的一致性。
☐ 封装容器/
☐ gradle‐wrapper.jar	Gradle 引导加载程序可执行文件 下载指定的 Gradle 发行版（如果不存在），并运行该发行版，并传递任意参数
☐ gradle‐wrapper.properties	Gradle 封装容器的配置 指定 Gradle 发行版的下载位置（包括要使用的版本）。
app/	子项目目录 子项目（在 Android Studio 中称为“模块”）可以构建应用或库，并可能依赖于其他子项目或外部依赖项。 app 是顶级应用子项目的常规名称（但不是必需名称）。其他子项目具有类似结构，但名称也不同。 任何目录都可以是子项目，必须至少包含一个 build.gradle(.kts) 文件，并使用 settings.gradle(.kts) 包含在 build 中。
☐ build.gradle(.kts)	子项目级 build 文件 声明如何构建此子项目。每个子项目都需要一个单独的 build 文件，并且应包含 用于构建此子项目的插件 插件所需的配置块 构建此子项目时包含的依赖项（库和平台） 您不应在 build 文件中包含构建逻辑（例如 Kotlin 函数定义或条件）或任务声明。构建逻辑和任务只能包含在插件内。
☐ src/	子项目源文件 将源文件（应用代码和资源）分组为源代码集。main 源代码集包含所有变体共有的源文件，而其他源代码集包含某个变体独有的源文件。
☐ main/	主 源代码集 所有 build 变体之间通用的源代码和资源。此源将作为所有构建的基础，并且会添加或替换其他更具体的源集。
☐ java/ ☐ kotlin/	Kotlin 和 Java 源代码 java 目录可同时包含 Java 和 Kotlin 源代码。如果此子项目仅包含 Kotlin 代码，您可以将此目录重命名为 kotlin. Android，将其作为一个 Kotlin 优先平台。支持 Java 源代码，但新的 API 以 Kotlin 语言为目标平台。我们建议针对所有新代码和对现有代码进行重大更新使用 Kotlin。
☐ res/	Android 资源文件 包含应用资源，例如 XML 文件和图片。所有应用都会使用一些基本资源（例如启动器图标），但其中许多资源（例如布局和菜单）仅用于基于视图的应用。Compose 应用使用此目录下定义的 String 资源。
☐ AndroidManifest.xml	Android 应用元数据 由 Android 软件包管理器读取，以告知系统 由您的应用定义的组件 必要权限 设备兼容性 Android 平台限制
☐ androidTest/	设备测试 源代码集 包含在 Android 设备或模拟器上运行的测试的源代码。这些测试可以访问真实的 Android 环境，但执行速度比主机测试慢。 main 源代码集中的所有源文件都可供 androidTest 下的源代码使用。
☐ 测试/	主机测试 源代码集 包含在 JVM 本地运行的测试（而不是在设备上运行的测试）的源代码。这些测试的运行速度比设备测试快得多。但是，您必须模拟、伪造、打桩或以其他方式模拟任何系统调用（包括运行应用的生命周期）。 main 源代码集中的所有源文件都可供被测源代码使用。
☐ proguard-rules.pro	R8 配置规则 定义用于控制应用缩减、优化和混淆的规则。R8 移除了不需要的代码和资源，优化运行时性能，并通过重命名标识符进一步最大限度地减少代码。

settings.gradle(.kts)常见配置及作用

包含 Gradle 初始化和项目配置的全局构建信息，例如

• 项目名称
• 要包含在此 build 中的子项目的列表
• 用于查找插件和依赖项的仓库规范
• 外部版本目录导入。

常见配置，例子：

pluginManagement {/* pluginManagement.repositories块用于配置 Gradle 用来搜索或下载 Gradle 插件及其传递依
赖项的仓库。Gradle 预先配置了对诸如 JCenter、Maven Central 和 Ivy 等远程仓库的支持。你也可以
使用本地仓库或者自行定义远程仓库。在此，我们将 Gradle 插件门户、谷歌的 Maven 仓库以及 Maven 中央
仓库定义为 Gradle 查找其依赖项时应使用的仓库。*/repositories {gradlePluginPortal()google()mavenCentral()}
}
dependencyResolutionManagement {/* dependencyResolutionManagement.repositories块用于配置项目中所有模块所使用的仓库及依
赖项，例如你用于创建应用程序的库。不过，你应该在每个模块级别的build.gradle文件中配置特定于模块的依
赖项。对于新项目，Android Studio 默认包含谷歌的 Maven 仓库和 Maven 中央仓库，但不会配置任何依
赖项（除非你选择了一个需要某些依赖项的模板）。*///repositoriesMode 用于设置项目的仓库解析模式
//当设置为FAIL_ON_PROJECT_REPOS时，如果在项目的build.gradle文件（不是根build.gradle或者
settings.gradle）中定义了仓库（例如repositories {... }块），Gradle 构建将会失败。即保证全局
性的配置仓库地址。repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)repositories {google()mavenCentral()}
}
//项目名称
rootProject.name = "My Application"
// 包含名为'app'和'mylibrary'的子项目，只有include的才能互相依赖，是依赖的前提
include("app", "mylibrary")

顶层 build.gradle.kts 常见配置及作用

应仅包含用于设置跨子项目通用插件类路径的插件声明。其他代码应位于设置或嵌套项目级 build 文件中。

plugins {/**在顶级的 build.gradle 文件中使用 apply false，可以将一个 Gradle 插件作为构建依赖
添加进来，但不会将其应用到当前（根）项目上。不要在子项目中使用 apply false。*/id("com.android.application") version "8.7.0" apply falseid("com.android.library") version "8.7.0" apply falseid("org.jetbrains.kotlin.android") version "2.0.20" apply false
}

模块级 build.gradle.kts 常见配置及作用

声明如何构建此子项目。每个子项目都需要一个单独的 build 文件，并且应包含

• 用于构建此子项目的插件
• 插件所需的配置块
• 构建此子项目时包含的依赖项（库和平台）

/*** 构建配置中的第一部分将 Android Gradle 插件应用于此构建，并使 `android` 
代码块可用于指定特定于 Android 的构建选项。*/
plugins {id("com.android.application")
}/*** 定位（可能还会下载）一个用于构建 Kotlin 源代码的 JDK。这也充当 `sourceCompatibility`、
`targetCompatibility` 和 `jvmTarget` 的默认值。请注意，这不会影响运行 Gradle 构建本
身所使用的 JDK，并且无需考虑 Gradle 插件（例如 Android Gradle 插件）所需的 JDK 版本。*/
kotlin {jvmToolchain(11)
}/*** `android` 代码块是用于配置所有特定于 Android 的构建选项的地方。*/
android {/*** 应用的命名空间。主要用于访问应用资源。*/namespace = "com.example.myapp"/*** `compileSdk` 指定 Gradle 用于编译应用的 Android API 级别。这意味着你的应
用可以使用此 API 级别及更低级别中包含的 API 特性。*/compileSdk = 33/*** `defaultConfig` 代码块封装了所有构建变体的默认设置和条目，并且可以从构建系统动
态覆盖 `main/AndroidManifest.xml` 中的某些属性。你可以配置产品变种来为应用的不同版本
覆盖这些值。*/defaultConfig {// 唯一标识用于发布的包。applicationId = "com.example.myapp"// 定义运行应用所需的最低 API 级别。minSdk = 21// 指定用于测试应用的 API 级别。targetSdk = 33// 定义应用的版本号。versionCode = 1// 为应用定义一个用户友好的版本名称。versionName = "1.0"}/*** `buildTypes` 代码块是可以配置多个构建类型的地方。默认情况下，构建系统定义了
两个构建类型：`debug` 和 `release`。`debug` 构建类型在默认构建配置中未明确显示，但
它包含调试工具并使用调试密钥进行签名。`release` 构建类型应用 ProGuard 设置，默认情况
下未签名。*/buildTypes {/*** 默认情况下，Android Studio 将 `release` 构建类型配置为启用代码压缩
（通过 `minifyEnabled`），并指定默认的 ProGuard 规则文件。*/getByName("release") {isMinifyEnabled = true // 为 `release` 构建类型启用代码压缩。proguardFiles(getDefaultProguardFile("proguard-android.txt"),"proguard-rules.pro")}}/*** `productFlavors` 代码块是可以配置多个产品变种的地方。这允许你创建应用的不同版本，
这些版本可以用自己的设置覆盖 `defaultConfig` 代码块。产品变种是可选的，构建系统默认不会
创建它们。* 此示例创建了一个免费和付费的产品变种。每个产品变种然后指定其自己的应用 ID，以便它们
可以同时存在于 Google Play 商店或 Android 设备上。** 如果声明了产品变种，还必须声明变种维度并将每个变种分配给一个变种维度。*/flavorDimensions += "tier"productFlavors {create("free") {dimension = "tier"applicationId = "com.example.myapp.free"}create("paid") {dimension = "tier"applicationId = "com.example.myapp.paid"}}/*** 若要覆盖源兼容性和目标兼容性（如果与工具链 JDK 版本不同），请添加以下内容。所有这些
默认与 `kotlin.jvmToolchain` 的值相同。如果对这些值和 `kotlin.jvmToolchain` 使用相同
的版本，则可以删除这些代码块。*///compileOptions {//    sourceCompatibility = JavaVersion.VERSION_11//    targetCompatibility = JavaVersion.VERSION_11//}//kotlinOptions {//    jvmTarget = "11"//}
}/*** 模块级构建配置文件中的 `dependencies` 代码块指定仅构建模块本身所需的依赖项。*/
dependencies {implementation(project(":lib"))implementation("androidx.appcompat:appcompat:1.7.0")implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}

注意：compileSdk 和 targetSdk 的值不必相同。请谨记以下基本原则：

• compileSdk 可让您使用新 API
• targetSdk 用于设置应用的运行时行为
• targetSdk 必须小于或等于 compileSdk

扩展功能

自定义依赖项解析策略

一个项目可能会依赖于同一个库的两个不同版本，这样会导致依赖项冲突。例如，如果您的项目依赖于模块 A 的版本 1 和模块 B 的版本 2，而模块 A 以传递方式依赖于模块 B 的版本 3，则会出现依赖项版本冲突。

为了解决此冲突，Android Gradle 插件使用以下依赖项解析策略：当插件检测到依赖项关系图中存在同一模块的不同版本时，默认情况下，它会选择版本号最高的一个。如果你不想按这个模式走，可以自定义。

例子：

// 以下是 Android 项目中模块级别的 build.gradle 文件示例，用于配置该模块自身的构建相关信息、依赖管理以及依赖解析策略等内容
// 此配置示例假设项目包含地图展示、数据库操作等功能，且存在一些依赖冲突和版本管理相关的情况需要处理android {// 配置应用的基本信息，如编译 SDK、默认配置等（此处省略部分常规配置）compileSdkVersion 33defaultConfig {applicationId "com.example.myapp"minSdkVersion 21targetSdkVersion 33versionCode 1versionName "1.0"}// 针对应用的所有变体（例如不同构建类型、不同产品风味组合形成的变体）进行相关配置操作applicationVariants.all {// 处理编译配置中的依赖解析策略部分，用于解决编译阶段的依赖版本冲突等问题compileConfiguration.resolutionStrategy {// 假设项目中还引入了其他库依赖了不同版本的 retrofit 库（此处示例）// 存在 retrofit 2.9.0 和 retrofit 2.6.0 两个版本冲突情况// 强制统一使用 retrofit 2.9.0 版本进行编译，这样可以避免编译时因版本不一致导致的错误force 'com.squareup.retrofit2:retrofit:2.9.0' // 处理数据库相关注解处理器的版本冲突，优先使用 DatabaseLibrary 依赖的 MyAnnotationProcessor 版本（2.0 版本）// 因为 ExtraFeatureLib 引入了该注解处理器的旧版本（1.0 版本），而我们希望使用 DatabaseLibrary 所需的版本来确保数据库注解处理正确prefer 'com.example.annotation:MyAnnotationProcessor:2.0' }// 处理运行时配置中的依赖解析策略，用于控制应用在运行时不同场景下使用的依赖版本runtimeConfiguration.resolutionStrategy {eachDependency { DependencyResolveDetails details ->// 根据构建类型来选择 MapLibrary 的不同版本// 目的是在开发调试阶段使用带有更多调试信息的开发版，而在发布应用时使用正式版if (details.requested.group == 'com.example.map' && details.requested.name == 'MapLibrary') {if (project.plugins.hasPlugin('com.android.application') && variant.buildType.name == 'release') {details.useVersion '1.0'} else {details.useVersion '1.0-dev'}}}}// 处理注解处理器配置中的依赖解析策略，再次确保数据库相关注解处理使用正确的版本annotationProcessorConfiguration.resolutionStrategy {// 再次明确优先使用 DatabaseLibrary 依赖的 MyAnnotationProcessor（2.0 版本）来确保数据库注解处理正确prefer 'com.example.annotation:MyAnnotationProcessor:2.0' }}// 配置构建类型（此处简单展示 release 和 debug 构建类型的基本配置）buildTypes {release {minifyEnabled falseproguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'}debug {// 调试相关配置（可按需添加更多）}}
}dependencies {// 引入地图库，这里使用的是示例中的版本，实际中根据具体需求和库的更新情况选择合适版本implementation 'com.example.map:MapLibrary:1.0'// 引入数据库库，用于实现数据库操作功能implementation 'com.example.database:DatabaseLibrary:1.0'// 引入额外功能库（引发了依赖冲突问题），该库自带的一些依赖可能与其他库依赖的版本有冲突implementation 'com.example.extra:ExtraFeatureLib:1.0'// 引入其他可能用到的库（此处示例引入 retrofit 库，导致版本冲突）implementation 'com.squareup.retrofit2:retrofit:2.6.0'
}

讲解（以上例子由ai生成）：

• compileConfiguration.resolutionStrategy 部分：它针对的是编译阶段的配置，通过 resolutionStrategy 这个机制，利用 Gradle 提供的 API，可以去精细地调整该变体在编译时如何去处理依赖关系，比如当存在多个版本的相同依赖库时，决定选用哪个版本等情况。

• runtimeConfiguration.resolutionStrategy 部分：侧重于运行时配置方面，同样借助 resolutionStrategy ，可以定义在应用运行时其依赖解析的策略，确保运行时所使用的依赖是符合预期的，例如处理运行时可能出现的依赖冲突等问题。

• annotationProcessorConfiguration.resolutionStrategy 部分：主要是针对注解处理器相关的配置，通过指定解析策略，能让注解处理器在处理代码中的注解等情况时，依赖的解析符合项目特定的要求，像引入合适的依赖库来支持注解处理的功能实现等。

配置build变体（即生成不同的版本）

1、配置 build 类型

每种 build 变体都代表您可以构建的一个不同的应用版本。例如，您可能希望为应用构建两个版本，一个是内容有限的免费版本，另一个是包含更多内容的付费版本。下面是配置多个版本的例子：

android {defaultConfig {// 在 AndroidManifest.xml 文件中设置名为 "hostName" 的占位符的值为 "www.example.com"，// 可用于在构建时向清单文件传递动态值，比如配置应用要连接的服务器主机名等情况。// 如，在清单文件里面这么引用：//  <intent-filter ... >//    <data android:scheme="https" android:host="${hostName}" ... />//   </intent-filter>manifestPlaceholders["hostName"] = "www.example.com"...}buildTypes {getByName("release") {isMinifyEnabled = trueproguardFiles(getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro")}// 给应用的包名（applicationId）添加一个后缀 ".debug"，如果正式发布版本的 applicationId 是 //com.example.myapp，那么调试版本的 applicationId 就变成了 com.example.myapp.debuggetByName("debug") {applicationIdSuffix = ".debug"//设置此构建类型为可调试状态，这使得开发人员可以在 Android 设备或模拟器上使用调试工具（如 //Android Studio 的调试功能）来跟踪代码执行、查看变量值等，方便查找和修复代码中的问题，这
//是开发调试阶段非常重要的一个属性设置。isDebuggable = true}//创建预发布变体create("staging") {
// initWith属性允许你从其他构建类型复制配置信息，然后只需配置你想要更改的设置即可。
// 此处这个构建类型从调试（debug）构建类型复制配置，接着更改清单占位符和应用 ID 的相关设置。initWith(getByName("debug"))manifestPlaceholders["hostName"] = "internal.example.com"applicationIdSuffix = ".debugStaging"}}
}

2、配置产品变种

 所有变种都必须属于一个指定的变种维度，即一个产品变种组。例子：

android {...buildTypes {getByName("debug") {...}getByName("release") {...}}// 指定你想要使用的产品风味维度。你罗列这些维度的顺序决定了它们在 Gradle 
//合并变体资源及配置时的优先级，顺序是从最高优先级到最低优先级。
// 并且，你必须将你所配置的每个产品风味分配到这些风味维度中的某一个维度上。flavorDimensions += listOf("api", "mode")productFlavors {create("demo") {// 将这个产品风味分配到 "mode" 风味维度下。dimension = "mode"...}create("full") {dimension = "mode"...}// "api" 产品风味中的配置会覆盖 "mode" 产品风味以及 defaultConfig 代码块中的配置。
// Gradle 根据风味维度在 flavorDimensions 属性旁边出现的顺序来确定它们之间的优
//先级，排在第一个的维度优先级高于第二个维度，依此类推。create("minApi24") {dimension = "api"minSdk = 24// 为了确保目标设备能接收到具有最高兼容 API 级别版本的应用，按照 API 级别以递
//增的值来分配版本号（versionCode）。versionCode = 30000 + (android.defaultConfig.versionCode ?: 0)versionNameSuffix = "-minApi24"...}create("minApi23") {dimension = "api"minSdk = 23versionCode = 20000  + (android.defaultConfig.versionCode ?: 0)versionNameSuffix = "-minApi23"...}create("minApi21") {dimension = "api"minSdk = 21versionCode = 10000  + (android.defaultConfig.versionCode ?: 0)versionNameSuffix = "-minApi21"...}}
}
...

以上代码分了两个维度，“api” 维度有 “minApi24”、“minApi23”、“minApi21” 这 3 个变种，“mode” 维度有 “demo” 和 “full” 这 2 个变种，build 类型有 “debug” 和 “release” 这 2 种。最后能生成12个变体。

• build 变体：[minApi24, minApi23, minApi21][Demo, Full][Debug, Release]
• 对应的 APK：app-[minApi24, minApi23, minApi21]-[demo, full]-[debug, release].apk

例如，

build 变体：minApi24DemoDebug

对应的 APK：app-minApi24-demo-debug.apk

3、过滤变种

某些 build 变体可能并不是您需要的，或者在您项目的背景下没有意义。您可以在模块级 build.gradle.kts 文件中创建变体过滤器，以移除某些 build 变体配置。

android {...buildTypes {...}flavorDimensions += listOf("api", "mode")productFlavors {create("demo") {...}create("full") {...}create("minApi24") {...}create("minApi23") {...}create("minApi21") {...}}
}androidComponents {beforeVariants { variantBuilder ->// 若要检查特定的构建类型，可使用 variant.buildType.name == "<buildType>" 这种形式
//来判断。例如判断是否为 "debug" 构建类型，就可以写成 variant.buildType.name == "debug"。if (variantBuilder.productFlavors.containsAll(listOf("api" to "minApi21", "mode" to "demo"))) {// Gradle 将会忽略满足上述条件的任何变体。也就是当变体的产品风味同时包含 "minApi21" 
//和 "demo" 时，这个变体在构建过程中会被 Gradle 忽略，不会生成对应的构建产物（如 APK 等）。variantBuilder.enable = false}}
}
...

4、更改变种的应用id

android {...defaultConfig {...}buildTypes {getByName("debug"){...}getByName("release"){...}}// Specifies one flavor dimension.flavorDimensions += "version"productFlavors {create("demo") {// 那么这个 dimension 属性的设置其实是可选的，因为 Android Gradle 插件
//会自动把当前模块下所有定义的产品风味都分配到这个唯一的维度当中。dimension = "version"
// 给应用的包名（applicationId）添加一个后缀 ".demo"applicationIdSuffix = ".demo"
// 给应用的版本名称（versionName）添加一个后缀 "-demo"versionNameSuffix = "-demo"}create("full") {dimension = "version"applicationIdSuffix = ".full"versionNameSuffix = "-full"}}
}

若applicationId 为com.example.myapp，那么对应的变体是 com.example.myapp.demo，com.example.myapp.full。   若有build 类型配置，比如debug 也配置了applicationIdSuffix 属性（applicationIdSuffix = ".debug"），那么生成多是，com.example.myapp.demo.debug ，com.example.myapp.full.debug

配置签名

...
android {...defaultConfig {...}signingConfigs {create("release") {storeFile = file("myreleasekey.keystore")storePassword = "password"keyAlias = "MyReleaseKey"keyPassword = "password"}}buildTypes {getByName("release") {...signingConfig = signingConfigs.getByName("release")}}
}

注意：在 build 文件中添加发布密钥和密钥库的密码并不是一种好的安全做法。

1、创建一项签名配置，并将其分配给一种或多种 build 类型。

2、在项目的根目录下创建一个名为 keystore.properties 的文件。此文件应当包含您的签名信息，如下所示：

storePassword=myStorePassword
keyPassword=mykeyPassword
keyAlias=myKeyAlias
storeFile=myStoreFileLocation

3、在模块的 build.gradle 文件中，在 android {} 块的前面添加用于加载 keystore.properties 文件的代码。

...
import java.util.Properties
import java.io.FileInputStream// 创建一个名为keystorePropertiesFile的变量，并将其初始化为位于根项目文件
//夹下的keystore.properties文件。（你可以更改存储位置）
val keystorePropertiesFile = rootProject.file("keystore.properties")// 初始化一个名为keystoreProperties的新Properties()对象。
val keystoreProperties = Properties()// 将keystore.properties文件加载到keystoreProperties对象中。
keystoreProperties.load(FileInputStream(keystorePropertiesFile))android {signingConfigs {
//您可以使用语法 keystoreProperties['propertyName'] 引用存
//储在 keystoreProperties 中的属性。create("config") {keyAlias = keystoreProperties["keyAlias"] as StringkeyPassword = keystoreProperties["keyPassword"] as StringstoreFile = file(keystoreProperties["storeFile"] as String)storePassword = keystoreProperties["storePassword"] as String}}...
}

注：由于您的 build 文件不再包含敏感信息，您现在可以将其包含在源代码控制系统中或者上传到共享的代码库。请务必保证 keystore.properties 文件的安全。您可能需要将其从您的源代码控制系统中移除。

添加依赖

目前官网推荐的是用 版本目录 去统一管理依赖。

添加过程：

1、在版本目录文件的 [versions] 部分为所需依赖项版本添加别名，该别名称为 libs.versions.toml（位于 Project 视图的 gradle 目录下或 Android 视图的 Gradle Scripts下）：

[versions] //版本
agp = "8.3.0"
androidx-macro-benchmark = "1.2.2"
my-library = "1.4"[libraries] //库
androidx-benchmark-macro = { group = "androidx.benchmark", name = "benchmark-macro-junit4", version.ref = "androidx-macro-benchmark" }
my-library = { group = "com.myapplication", name = "mylibrary", version.ref = "my-library" }[plugins] //插件
androidApplication = { id = "com.android.application", version.ref = "agp" }

2、将对依赖项别名的引用添加到需要该依赖项的模块的 build 脚本中。从 build 脚本引用别名时，请将别名的下划线和短划线转换为圆点。我们的模块级 build 脚本将如下所示：

plugins {alias(libs.plugins.androidApplication)
}dependencies {implementation(libs.androidx.benchmark.macro)implementation(libs.my.library)
}

声明选项功能：

配置	行为
implementation	Gradle 会将依赖项添加到编译类路径，并将依赖项打包到 build 输出。当您的模块配置 implementation 依赖项时，会让 Gradle 了解您不希望该模块在编译时将该依赖项泄露给其他模块。也就是说，该依赖项不会提供给依赖于当前模块的其他模块。 使用此依赖项配置代替 api 可以显著缩短构建时间，因为这样可以减少构建系统需要重新编译的模块数。例如，如果 implementation 依赖项更改了其 API，Gradle 只会重新编译该依赖项以及直接依赖于它的模块。大多数应用和测试模块都应使用此配置。
api	Gradle 会将依赖项添加到编译类路径和 build 输出。当一个模块包含 api 依赖项时，会让 Gradle 了解该模块要以传递方式将该依赖项导出到其他模块，以便这些模块在运行时和编译时都可以使用该依赖项。 使用此配置时应格外小心，只能对您需要以传递方式导出到其他上游消费者的依赖项使用它。如果 api 依赖项更改了其外部 API，Gradle 会在编译时重新编译所有有权访问该依赖项的模块。拥有大量的 api 依赖项会显著增加构建时间。除非要将依赖项的 API 公开给单独的模块，否则库模块应改用 implementation 依赖项。
compileOnly	Gradle 只会将依赖项添加到编译类路径（也就是说，不会将其添加到 build 输出）。如果您创建 Android 模块时在编译期间需要相应依赖项，但它在运行时可有可无，此配置会很有用。例如，如果您依赖的库仅包含编译时注解（通常用于生成代码，但通常不包含在 build 输出中），则可以将该库标记为 compileOnly。 如果您使用此配置，那么您的库模块必须包含一个运行时条件，用于检查是否提供了相应依赖项，然后适当地改变该模块的行为，以使该模块在未提供相应依赖项的情况下仍可正常运行。这样做不会添加不重要的瞬时依赖项，因而有助于减小最终应用的大小。 注意：您不能将 compileOnly 配置与 Android 归档文件 (AAR) 依赖项配合使用。
runtimeOnly	Gradle 只会将依赖项添加到 build 输出，以便在运行时使用。也就是说，不会将其添加到编译类路径。 这在 Android 上很少用到，但在服务器应用中通常用于提供日志记录实现。例如，库可以使用不包含实现的日志记录 API。该库的使用方可以将其添加为 implementation 依赖项，并添加 runtimeOnly 依赖项以供实际日志记录实现使用。
ksp kapt annotationProcessor	这些配置会提供库，用于在代码编译之前处理代码中的注解和其他符号。它们通常用于验证代码或生成额外的代码，从而减少您需要编写的代码量。 如需添加此类依赖项，您必须使用 ksp、kapt 或 annotationProcessor 配置将其添加到注解处理器类路径。使用这些配置可以将编译类路径与注解处理器类路径分开，从而提高 build 性能。如果 Gradle 在编译类路径上找到注解处理器，则会停用 避免编译功能，这样会增加构建时间（Gradle 5.0 及更高版本会忽略编译类路径上的注解处理器）。 如果 JAR 文件包含以下文件，则 Android Gradle 插件会假定依赖项是注解处理器： META-INF/services/javax.annotation.processing.Processor 如果插件检测到编译类路径上包含注解处理器，则会产生 build 错误。 ksp 是 Kotlin 符号处理器，由 Kotlin 编译器运行。 kapt 和 apt 是单独的工具，会在 Kotlin 或 Java 编译器执行之前处理注解。 在决定要使用哪种配置时，请考虑以下几点： 如果某个处理器可用作 Kotlin 符号处理器，请将其用作 ksp 依赖项。 如需详细了解如何使用 Kotlin 符号处理器，请参阅从 kapt 迁移到 KSP。 如果处理器无法用作 Kotlin 符号处理器： 如果您的项目包含 Kotlin 源代码（但也可以包含 Java 源代码），请使用 kapt 进行添加。 如果您的项目仅使用 Java 源代码，请使用 annotationProcessor 将其添加进来。 如需详细了解如何使用注解处理器，请参阅添加注解处理器。
lintChecks	使用此配置可以添加包含您希望 Gradle 在构建 Android 应用项目时执行的 lint 检查的库。 请注意，包含 lint.jar 文件的 AAR 会自动运行该 lint.jar 文件中定义的检查；您无需添加显式 lintChecks 依赖项。这样，您就可以在单个依赖项中定义库和关联的 lint 检查，确保在使用库的消费者运行检查时，系统会运行您的检查。
lintPublish	在 Android 库项目中使用此配置可以添加您希望 Gradle 编译成 lint.jar 文件并打包在 AAR 中的 lint 检查。这会使得使用 AAR 的项目也应用这些 lint 检查。如果您之前使用 lintChecks 依赖项配置将 lint 检查添加到已发布的 AAR 中，则需要迁移这些依赖项以改用 lintPublish 配置。 KotlinGroovy dependencies {// Executes lint checks from the ":checks" project at build time.lintChecks(project(":checks"))// Compiles lint checks from the ":checks-to-publish" into a// lint.jar file and publishes it to your Android library.lintPublish(project(":checks-to-publish")) }

为特定 build 变体配置依赖项

上述所有配置都会将依赖项应用于所有 build 变体。如果您只想为特定的 build 变体源代码集或测试源代码集声明依赖项，则必须将配置名称的首字母大写，并在其前面加上build 变体或测试源代码集的名称作为前缀。

例如，如需使用 implementation 配置仅向“free”产品变种添加远程二进制文件依赖项，请使用以下代码：

dependencies {freeImplementation("com.google.firebase:firebase-ads:21.5.1")
}

不过，如果您想为将产品变种和 build 类型组合在一起的变体添加依赖项，则必须初始化配置名称：

//为 freeDebugImplementation 依赖配置初始化一个占位符
val freeDebugImplementation by configurations.creatingdependencies {freeDebugImplementation(project(":free-support"))
}

如需为本地测试和插桩测试添加 implementation 依赖项，请使用如下所示的代码：

dependencies {// 仅为本地测试添加一个远程二进制依赖项。testImplementation("junit:junit:4.12")// 仅为插桩测试APK添加一个远程二进制依赖项。androidTestImplementation("androidx.test.espresso:espresso-core:3.6.1")
}

不过，某些配置在这种情况下没有意义。例如，因为其他模块不能依赖于 androidTest，所以如果您使用 androidTestApi 配置，会收到以下警告：

WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with 'androidTestImplementation'.

管理maven库

//仓库配置
dependencyResolutionManagement {repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)repositories {google()mavenCentral()mavenLocal()}
}
//写法二，直接写地址dependencyResolutionManagement {repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)repositories {maven(url = "https://repo.example.com/maven2")maven(url = "file://local/repo/")ivy(url = "https://repo.example.com/ivy")}
}