一、AGP 是什么？说白了就是 Android 构建的“发动机”
Android Gradle Plugin，圈里人都叫它 AGP。它的作用其实很单纯——把咱们写的 Kotlin、Java、资源文件、Manifest 这些东西，最终变成能装到手机里的 APK / AAB。你想想看，整个构建过程中，代码编译、资源合并、签名、混淆、多渠道打包，哪个环节都得靠它来调度。
我记得刚入行那会儿，有同事一遇到构建失败就去翻 Gradle 脚本，改了半天还是报错。后来我帮他看了一眼，其实是 AGP 版本跟 Gradle 版本不匹配，换个版本就过了。所以说，理解 AGP 的来龙去脉，真的能省下不少排查时间。
1.1 AGP 到底在构建中做了什么？
简单来说，AGP 是一个 Gradle 插件，它注册了一系列 Task（任务），把源文件一步步“加工”成安装包。我习惯把构建流程拆成三个阶段：
- 编译阶段：将 .java/.kt 编译成 .class，再用 D8/R8 转成 Dex。
- 打包阶段：合并资源、处理 Manifest、签名、对齐。
- 优化阶段：代码混淆、资源压缩、多 Dex 拆分等。
你可能会问：“Gradle 本身不也能构建吗？为什么非要用 AGP？”嗯，这是因为 Android 项目有很多特殊的处理逻辑，比如资源 ID 生成、AAPT2 调用、Bundle 格式打包等等，这些只有 AGP 才知道怎么做。
1.2 历史发展：从 1.0 到 8.x，AGP 经历了什么？
AGP 最早是随着 Android Studio 1.0 一起推出的。那时候还只支持 Eclipse 迁移过来的老项目，功能也简单。我2015年做第一个项目时用的就是 AGP 1.0，那会儿连 Instant Run 都还没影子呢。
这十年间 AGP 的版本号和特点，我用一张表来总结：
| 版本 | 发布时间 | 主要变化 | 我的印象 |
|---|---|---|---|
| 1.x | 2013–2015 | 基础构建、Eclipse 兼容 | 当时打包速度很慢，一次构建能喝杯咖啡 |
| 2.x | 2016 | Instant Run、Jack 编译器（后来废弃） | Instant Run 想法很好，但实际体验并不稳定 |
| 3.x | 2017–2019 | 支持 Kotlin、Java 8+、AndroidX、构建缓存 | 从 3.0 开始全面拥抱 Kotlin，我们团队也在那时迁移 |
| 4.x | 2020–2021 | 升级到 Gradle 7+、AGP API 稳定性提升、新 DSL | API 变化大，许多自定义插件都要重写 |
| 7.x | 2022–2023 | Java 11 要求、Gradle 7+、非传递性 R 类、版本目录 | 我建议从 7.0 开始启用版本目录，依赖管理清爽很多 |
| 8.x | 2023–至今 | Gradle 8+、Java 17、KSP 支持、BuildConfig 默认不生成 | 最新版，性能提升明显，但注意一些老库的兼容 |
1.3 版本兼容性——为什么这是个“瀑布图”？
AGP 和 Gradle、Android Studio、Kotlin、Java 之间不是随便搭配的。每升一个版本，就可能影响一堆依赖。我在项目中遇到过好几次这样的情况：项目跑了一年没升级，某天想加个新特性，不得不从 AGP 4.2 跳到 7.4，结果同时要改 Gralde 版本、Kotlin 版本、甚至一些第三方插件的写法，可谓牵一发而动全身。
这就是我们这门课要重点分析的——版本兼容性瀑布图。它把每组 AGP 版本及其兼容的 Gradle 版本、最低 SDK 版本、支持 Java 版本等信息用图形的方式呈现出来，让你一眼就能看到自己的项目处于哪个“瀑布层级”。
1.4 AGP 体系架构概览
为了帮你更直观地理解 AGP 在整个 Android 构建中的位置，我画了一张架构图。它展示了从源代码到最终产物的核心链路。
从上图你能看到，源代码和依赖经过 AGP 引擎处理后，生成 APK 或 AAB。这就是整个构建流程的主干。
1.5 为什么我们要学“版本兼容性瀑布图”？
说白了，Android 构建生态里的组件版本是互相锁定的。AGP 版本决定了它能用哪个 Gradle 版本，Gradle 版本又决定了 Java 版本。一旦某个组件升了，其他组件可能也要跟着升，否则就会出现不兼容。
我整理了几个常见场景：
- 你有一个第三方插件，只支持 AGP 7.x，但你项目还在用 AGP 4.2 —— 无法使用。
- 你想用 Kotlin 1.9，但旧 AGP 可能不兼容新 Kotlin 编译器的某些行为。
- 你团队里有人升级了 Android Studio，结果自动推了 AGP 版本，导致 CI 构建失败。
这门课会带你分析每一组兼容组合，并画出一张清晰的“瀑布图”，让你以后升级时心里有数。我个人习惯是：每次升级前先把目标版本的官方兼容表打印出来，对照着改，基本不会翻车。
1.6 快速自查：你的项目是否处于危险区？
你可以对照下面几条，看看自己的项目有没有潜在的兼容问题：
- 你的 AGP 版本是否 ≥ 项目中所用 Kotlin 插件建议的最低版本？
- 你的 Gradle 版本是否在 AGP 官方支持范围内？
- 你是否使用了已经被 AGP 废弃的 API 或特性（例如 Jack 编译器、旧的 Data Binding 写法）？
- 你的第三方 Gradle 插件（如 Buttery Knife、Dagger 的旧编译器）是否兼容当前 AGP 版本？
如果以上任何一项不确定，那接下来的章节正好能帮你理清。我曾有一个项目就是因为第二项没注意，AGP 7.0 配了 Gradle 6.8，编译时直接崩了，排查了整整一下午才发现是版本不匹配。
好了，这一章先到这里。你对 AGP 的历史和体系有了一个整体印象。接下来我们会一步步拆解每个版本的兼容细节，画出那张你以后离不开的“瀑布图”。