简介gradle-7.2-all.zip 是 Gradle 7.2 完整发行包面向 Java 与 Android 开发者尤其适合需要离线安装、摆脱 Android Studio 在线下载不稳定局面的构建场景。压缩包约 149.73MB完整包含 Gradle 运行时、核心库与配套工具解压后即可作为本地 Gradle 发行版直接使用无需额外联网快速完成初始化与构建。Gradle 在 Android 工程中负责依赖管理、多项目构建、APK 打包、代码混淆等关键任务7.2-all 版将全部组件收拢于一个压缩包内便于内网环境或网络受限时统一分发、切换版本也能规避在线拉取依赖的等待同样适合需要锁定构建工具版本的团队项目。已有 1467 人浏览。对经常处理大型项目、团队协作或网络波动环境的技术人员来说这份完整发行包可充当统一的构建基线减少重复下载和版本漂移降低构建失败概率。1. gradle-7.2-all.zip 是什么先别管配不配环境把发行包拿到手再说用 Android Studio 打开一个老项目改完代码点 Run构建一半卡在 Gradle sync 转圈日志翻到最后是下载 gradle-7.2-all.zip 连接超时——这是我见过最常见的 Android 构建翻车现场之一。gradle-7.2-all.zip 就是 Gradle 7.2 的完整发布包里面包含二进制、文档和源码不依赖网络就能完成整套安装。它的核心价值在于把 Gradle 7.2 从“每次靠网络现拉”变成“本地一次解压就能用”特别适合网络不稳定、多台机器需要统一构建版本、以及 CI 上想跳过重复下载的场景。Android 开发、多模块工程维护者、做构建环境标准化的人这份资源能直接省下一个小时的构建排障时间。2. Gradle 7.2 与 Android 构建的版本关系JDK、AGP、SDK 三者怎么配2.1 版本矩阵Gradle 7.2 能配合哪些 AGP 和 JDKGradle 7.2 是 2021 年年中发布的稳定版本在 Android 生态里的位置其实很微妙向上能兼容 AGP 7.0.x 和 7.1.x向下还能跑在 JDK 8 环境上所以很多还在 4.x、5.x 上挣扎的老工程第一次大版本升级往往会选它作为中间站。7.2 相对 7.1 的改动不算激进构建缓存和配置缓存都还在完善期依赖解析性能有些提升但不会逼你改一大堆脚本。我一般配版本时先定 AGP再反过来选 Gradle。常见组合大概是这样AGP 版本最低 Gradle 版本建议 JDK7.0.x7.0JDK 117.1.x7.0JDK 117.2.x7.3.3JDK 11注意AGP 7.2 起最低 Gradle 要求就跳到 7.3.3 了所以如果你手里那份 gradle-7.2-all.zip 是要配合 AGP 7.2.x 用的那 Gradle 版本本身就不够要么把 AGP 降到 7.1.x要么换 Gradle 7.4 以上版本。最容易踩的就是“看别人那边 AGP 升了我就跟着升”结果绕一圈又绕回版本矩阵里。JDK 这块Gradle 7.2 官方支持 JDK 8 到 16 都能运行但 AGP 7.x 强制要求 JDK 11 来编译所以别用 Java 17 直接跑 AGP 7.1会直接报 class file major version 61 不识别。SDK 方面没有硬性版本限制但 compileSdk 建议用 31 或以下配合 Android 12 的 API这样资源和依赖兼容性上的问题最少。2.2 三处需要同步改gradle-wrapper.properties、AGP 插件、JDK 路径把 gradle-7.2-all.zip 落到项目里不只是解压要改的地方其实有三处。第一处是 gradle/wrapper/gradle-wrapper.propertiesAndroid Studio 同步时第一个读的就是它# Wrapper 配置入口sync 时会优先按这里去找 Gradle 发行包 distributionBaseGRADLE_USER_HOME distributionPathwrapper/dists # 个人开发直接 file 协议指向本地 zip内网环境可换成镜像地址 distributionUrlfile\:///D:/dev-tools/gradle-7.2-all.zip networkTimeout10000 validateDistributionUrltrue zipStoreBaseGRADLE_USER_HOME zipStorePathwrapper/dists这里最关键的改动就是把 distributionUrl 从 https 远程地址换成 file 协议指向本地 zip。Windows 路径下 file 协议后面是三个斜杠冒号前要加反斜杠转义Linux 就是 file:///home/you/gradle-7.2-all.zip 这样的写法。networkTimeout 表示下载超时毫秒数离线方案里这个值不太重要但内网镜像场景下 10000 毫秒是经验值短了容易误报。第二处是根目录或模块的 build.gradle 里的 AGP 版本plugins { // AGP 7.1.x 与 Gradle 7.2 搭配是稳定档位 id com.android.application version 7.1.3 // 工程用到 Kotlin 时再加对应插件这里不展开 }AGP 7.1.3 是配 Gradle 7.2 比较稳妥的版本档位Kotlin 插件没有 Gradle 硬绑定但建议用 1.6.x别用 2.0 以后的新 Kotlin 插件带老构建系统会引入新的编译模式。第三处是 Android Studio 里的 JDK 路径。在 File Project Structure SDK Location 里切到 Gradle Settings把 Gradle JDK 指到本机的 JDK 11。Studio 自带的 JBR 可以是 17但那只是 IDE 运行用Gradle 构建还是按这个设置走。很多人在新版 Studio 上遇到构建诡炸就是这里没同步。这三处如果不一致最典型的现象就是 sync 通过但构建报 AGP 最低版本要求不满足或者反过来 sync 就失败。检查顺序建议是先看 wrapper 指向的 zip 路径存在不存在再看 AGP 和 Gradle 矩阵对不对最后确认 JDK 版本。按这个顺序能快速定位八成环境问题。3. 把 zip 装进本地仓库三种安装方式与目录细节3.1 方式一手动解压到用户目录命令行和 IDE 共用一份拿到 gradle-7.2-all.zip 后最直接的动作是解压到一个固定目录让命令行和 Android Studio 都能引用。Gradle 发行包解开后目录结构是固定的bin 里放着 gradle 启动脚本lib 是全部运行依赖 jardocs 是用户手册和 DSL 参考src 里是这个版本的源码init.d 放全局初始化脚本。# 统一放在用户目录下的 dev-tools避免挪来挪去 mkdir -p ~/dev-tools/gradle-dist unzip gradle-7.2-all.zip -d ~/dev-tools/gradle-dist export GRADLE_HOME~/dev-tools/gradle-dist/gradle-7.2 export PATH$GRADLE_HOME/bin:$PATH # 验证版本、JVM 和实际安装目录 gradle --versionunzip 的 -d 参数指定解压目标目录命令执行后会生成 gradle-7.2 这个子目录。GRADLE_HOME 指向的是这个子目录而不是外层。PATH 里加上 bin 后终端里直接敲 gradle 就能调用。gradle --version 的返回里有三行信息要注意Gradle 版本号、JVM 版本号、以及当前机器的主目录。如果 JVM 显示的是 17那你后面用 AGP 7.1 构建时会很痛苦先在这里发现比构建时发现省事得多。这两个 export 命令只在当前终端会话生效。要全局生效把这两行追加到 ~/.bashrc 或 ~/.zshrc 末尾然后 source 一下。团队里如果有多个人共用一台构建机还可以像配 JDK 一样把 Gradle 根路径写进环境变量配置文件避免每个人重复解压一份。这种方式最透明也是后面讲离线构建验证的基础。3.2 方式二通过 Android Studio 指定本地 Gradle 目录Android Studio 本身不强制用 wrapper它允许你直接指向本地已有的 Gradle 发行目录。打开 Settings 下的 Build Tools 面板选择 Gradle再选 Local distribution 并填本地目录路径。这样做的优点是Android Studio 不再下载任何东西同步完全是本地读盘。要注意 Studio 识别的是那种包含 bin、lib 完整结构的目录也就是说填 ~/dev-tools/gradle-dist/gradle-7.2不能填 zip 文件本身也不能填外层 gradle-dist。这个方法适合不想改项目里 wrapper 文件的情况缺点是每个开发者都要在自己机器上手动指定一次换台电脑就丢配置本质上还是在做本地安装管理。如果项目已经用 wrapperStudio 默认优先走 wrapper本地 distribution 设置会被忽略。所以这种方式只对不用 wrapper 的老项目或者你确实想绕开 wrapper 的场景有效。我的习惯是个人临时调试项目用这个方式正式工程一律改 wrapper 的 distributionUrl因为 wrapper 能通过项目文件把版本固定下来别人 clone 下来也跑同一个版本。3.3 方式三把 zip 塞进 wrapper 缓存让下载环节原地消失wrapper 在首次同步时会把 distributionUrl 指向的 zip 下载到本机缓存目录之后每次构建都从缓存解压。如果我们提前把 zip 放到缓存对应位置就能让下载环节整个消失。缓存路径在用户目录下~/.gradle/wrapper/dists/gradle-7.2-all/ 下面会有一个随机哈希串的目录zip 和最终解压出来的目录都在这底下。# 先跑一次 sync 生成哈希目录再把包塞进去覆盖 # Windows: C:\Users\用户名\.gradle\wrapper\dists\gradle-7.2-all\hash\ # Linux: ~/.gradle/wrapper/dists/gradle-7.2-all/hash/ cp gradle-7.2-all.zip ~/.gradle/wrapper/dists/gradle-7.2-all/hash/这个方法的坑在于哈希目录是随机的不同机器上不一样你不能写死。所以我更推荐的做法是手动建好 gradle-7.2-all 这个父目录然后通过修改 wrapper 里的 distributionUrl 指向本地 zip让 wrapper 自己决定缓存组织方式。手动放 zip 只适合你已经明确知道 hash 目录存在、只是 zip 被删掉的修复场景。三种方式里方式三最贴近“让 wrapper 不可见地使用本地资源”这个目标但可维护性最差方式二适合个人临时用方式一最透明而且能直接配合命令行做构建验证。如果你要统一团队环境我建议方式一加方式二双保险命令行和 IDE 都能用同一份包。安装方式适用场景可维护性手动解压命令行与 IDE 共用、团队标准化高Studio 本地指定个人单机、老项目临时调试低wrapper 缓存赛包修复已存在哈希目录的缓存缺失低提示手动往 wrapper/dists 下塞 zip 时哈希目录名别写死脚本里要动态探测当前存在的目录名。4. 升级到 Gradle 7.2 的构建脚本改造DSL、依赖和缓存的三处改动4.1 依赖管理里从 compile 到 implementation 的迁移Gradle 7.x 把一批老 API 标记为移除状态最典型的是依赖配置里的 compile。Android 老工程里最常见的写法是compile com.example.network:http:1.0这个写法从 4.x 开始废弃到 7.2 已经完全移除了。升级时如果不改构建会直接报找不到 compile 配置而不是给个警告。dependencies { // 旧写法已不可用 // compile com.example.network:http:1.0.0 // 内部依赖只在当前模块里可见不对外传递 implementation com.example.network:http:1.0.0 // 对外暴露依赖当前模块的其他模块能看到这个库 api com.example.ui:design-system:1.2.0 // 仅编译期使用运行时由运行环境提供 compileOnly com.example.tools:annotation-processor:1.0.0 annotationProcessor com.example.tools:annotation-processor:1.0.0 }implementation 和 api 的区别要按模块边界来理解。implementation 引入的库只会出现在当前模块的运行时 classpath 里上游模块看不到好处是编译更快、下次构建缓存命中率更高api 会把库传到依赖树上让依赖当前模块的其他模块也能直接用代价是会拖慢编译。compileOnly 最典型的场景是注解处理器这类只在编译期出现的东西。迁移的时候不要无脑把 compile 全换成 implementation先想清楚这个依赖是否需要被模块外部引用。4.2 缓存目录结构变化与磁盘清理Gradle 7.2 的缓存目录在用户目录的 .gradle/caches 下里面有几个关键子目录modules-2 存依赖元数据transforms-3 存 AAR 转换产物build-cache-1 存构建缓存。升级上来后你会发现旧的 modules-1、transforms-1、transforms-2 这些老目录会残留磁盘占用大的根本原因往往不在项目 build 目录而在这堆缓存目录里。# 先看缓存占了多少空间 du -sh ~/.gradle/caches # 删掉历史残留目录注意等最新版本构建稳定后再删 rm -rf ~/.gradle/caches/modules-1 rm -rf ~/.gradle/caches/transforms-1 rm -rf ~/.gradle/caches/transforms-2 # 项目级清理构建产物 ./gradlew clean反过来如果你发现构建依赖解析总是报错先把 modules-2 删掉让 Gradle 重新拉比在网上一通搜有效。Gradle 7.2 里 transforms-3 是 AAR 资源转换后的输出新版本会自动用老目录不会自动清理这就是磁盘悄悄变大的原因。清理前确认构建稳定一旦删了就要重新下载内网镜像不稳定的话这步会比较疼。4.3 构建性能参数堆内存、并行开关与配置缓存升级到 Gradle 7.2 最容易获得体感提升的是 gradle.properties 里的几个参数。Gradle 默认 JVM 堆只有 1GB 左右Android 工程很容易 OOM所以第一件事是调 jvmargs。配置缓存在这个版本还挂着 unsafe 前缀建议要开也要用单独分支验证别在主分支直接上。# gradle.properties与 settings.gradle 同目录 # 堆内存加到 2GMetaspace 也要给够否则反射多的工程频繁 Full GC org.gradle.jvmargs-Xmx2048m -XX:MaxMetaspaceSize512m # 多模块并行构建模块间无强依赖时收益明显 org.gradle.paralleltrue # 按需配置只配置要构建的模块大工程效果好小工程慎用 org.gradle.configureondemandtrue # 构建缓存相同输入直接复用输出开启后注意验证增量产物 org.gradle.cachingtrueparallel 参数在多模块工程里能把耗时从 10 分钟压到 5 分钟以内但前提是模块之间没写乱七八糟的依赖关系。configureondemand 是双刃剑只配置当前需要的模块但如果脚本里依赖了未配置模块的属性会报类找不到小工程建议关掉。caching 一旦开起来Gradle 会跨构建复用产物但 AAR 或插件输出变化时可能拿到旧产物所以在 CI 和本地的缓存行为不一致时先关掉再排。5. 避坑Gradle 7.2 使用中的五个常见问题与排查路径5.1 sync 卡在 Downloading远程下载链路不通现象Android Studio 首次打开工程或切换 Gradle 版本时Status 栏一直显示 Downloading gradle-7.2-all.zip进度条不动最后超时。原因wrapper 默认从远程地址下载网络连接不通或公司网络屏蔽了该下载源。解决别等它直接把 distributionUrl 改成 file 协议指向本地 zip或者把 zip 放到 wrapper 缓存目录下让 wrapper 跳过下载这步直接解压。改完后注意清掉项目里的 .idea 和 .gradle 下残留否则 Studio 有时会读旧缓存继续卡。5.2 报 Unsupported class file major version 61JDK 版本超限现象构建或 Gradle 解析插件时报错核心信息是 Unsupported class file major version 61。原因Gradle 7.2 的运行 JVM 版本太高。major version 61 对应 Java 17Gradle 7.2 虽然能在 JDK 17 上启动但 AGP 7.1 的很多字节码处理逻辑没有适配 17。解决把 Gradle JDK 切到 JDK 11同时检查 JAVA_HOME 和 Android Studio 的 Gradle JDK 设置。如果你机器上只有一个 JDK 17装个 JDK 11 并让构建环境指过去IDE 本身的 JBR 不受影响。5.3 报 Minimum supported Gradle versionAGP 与 Gradle 矩阵错位现象sync 阶段报 Minimum supported Gradle version is 7.3.3 之类的错误。原因当前 AGP 版本要求的最低 Gradle 高于你配的 7.2。解决两条路把 AGP 降到 7.1.x或者把 Gradle 升到匹配版本。建议先查版本矩阵再决定动哪边。gradle-7.2-all.zip 要配 AGP 7.1.x 最省事别硬怼新版 AGP。5.4 离线构建报 Could not resolve all artifacts缓存里根本没有依赖现象开启 --offline 后构建失败错误是 Could not resolve all artifacts for configuration。原因Gradle 离线模式只认 ~/.gradle/caches/modules-2 里的东西如果之前没做过一次完整在线构建缓存就是空的离线必然失败。解决先在线跑一次能通过的构建让依赖落进缓存再切离线或者在 repositories 里配置内网镜像仓库。别一上来就开 offline本地没有依赖闭环离线构建只是个摆设。5.5 配置缓存开启后插件内部报错实验特性背锅现象org.gradle.unsafe.configuration-cachetrue 打开后构建报 plugin internal error堆栈完全看不懂。原因Gradle 7.2 的配置缓存还属于实验特性插件没做适配序列化构建状态时就会炸。解决先关掉配置缓存把插件升到适配版本再决定是否重新开启。这个特性在 7.2 里不值得为那点秒级的提速搭进去排障时间除非你的工程没有 Android 插件只有纯 Java 模块。6. 验证安装与构建可复现性几个值得养成的检查习惯包解压完、wrapper 改完参数别急着点 Run。验证的顺序有个套路先用命令行确认环境能闭环再用警告模式扫一遍老脚本的遗留问题最后做一次干净环境的全量构建。这三个动作按顺序来能在十分钟内把版本升级的大部分隐患暴露出来。第一步用命令行直接验证本地环境# 离线构建一次验证 zip 路径、JDK 版本、依赖缓存是否全部闭环 ./gradlew assembleDebug --offline --consoleplain--offline 让 Gradle 完全不碰网络能通过说明三个关键点都对了。--consoleplain 的作用是让日志以纯文本输出不进入交互界面方便直接记录到文件。如果这一步报错先别怀疑业务代码大概率是环境层面的问题比如 zip 路径没指对、JDK 切到了 17、或者某个依赖从来没有进过本地缓存。第二步扫描废弃 API 和构建警告# 把所有 deprecated 调用和警告全部暴露出来升级后的扫尾检查 ./gradlew build --warning-modeall--warning-modeall 会把构建脚本里所有废弃写法的位置和替代方案打印出来。Gradle 升级后最隐蔽的问题不是编译报错而是静默警告比如老式的 maven 仓库写法、被移除的依赖配置、过时的插件 API都会在这里现形。不要忽略这些警告它们大多在你换下一个版本时就变成硬错误。第三步做干净环境复现测试。删掉项目根目录下的 .gradle 和所有模块的 build 目录再清掉 ~/.gradle/caches 里和本项目相关的缓存子目录然后重新跑离线构建。这一步专门用来揭露靠增量缓存掩盖的问题本地仓库里其实缺少某个传递依赖、某个插件在冷启动时的配置顺序不对这些在第二次构建时因为缓存存在不会出现清理后立刻暴露。我第一次配 Gradle 7.2 时没做这套东西把 zip 解压完、sync 通过就以为搞定了。结果代码切到另一台机器上第一次全量构建光缺依赖就折腾了一下午最后发现缓存目录里少了一个老版本的库在线下载又超时。从那以后我每次落地 gradle 版本都强制走一遍本地解压、改 file 协议、offline 构建、warning 扫描的完整流程。多花十来分钟把那些说不清的玄学构建问题全挡在门外。如果你现在正被项目里纷乱的 Gradle 版本拖着后腿这份 gradle-7.2-all.zip 不妨先放在本地下次配环境时照着这套流程走一遍能省不少事。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/20 4:02:59 · 阅读 1.2k gradle-7.2-all.zip离线安装与Android构建版本配置指南
简介gradle-7.2-all.zip 是 Gradle 7.2 完整发行包面向 Java 与 Android 开发者尤其适合需要离线安装、摆脱 Android Studio 在线下载不稳定局面的构建场景。压缩包约 149.73MB完整包含 Gradle 运行时、核心库与配套工具解压后即可作为本地 Gradle 发行版直接使用无需额外联网快速完成初始化与构建。Gradle 在 Android 工程中负责依赖管理、多项目构建、APK 打包、代码混淆等关键任务7.2-all 版将全部组件收拢于一个压缩包内便于内网环境或网络受限时统一分发、切换版本也能规避在线拉取依赖的等待同样适合需要锁定构建工具版本的团队项目。已有 1467 人浏览。对经常处理大型项目、团队协作或网络波动环境的技术人员来说这份完整发行包可充当统一的构建基线减少重复下载和版本漂移降低构建失败概率。1. gradle-7.2-all.zip 是什么先别管配不配环境把发行包拿到手再说用 Android Studio 打开一个老项目改完代码点 Run构建一半卡在 Gradle sync 转圈日志翻到最后是下载 gradle-7.2-all.zip 连接超时——这是我见过最常见的 Android 构建翻车现场之一。gradle-7.2-all.zip 就是 Gradle 7.2 的完整发布包里面包含二进制、文档和源码不依赖网络就能完成整套安装。它的核心价值在于把 Gradle 7.2 从“每次靠网络现拉”变成“本地一次解压就能用”特别适合网络不稳定、多台机器需要统一构建版本、以及 CI 上想跳过重复下载的场景。Android 开发、多模块工程维护者、做构建环境标准化的人这份资源能直接省下一个小时的构建排障时间。2. Gradle 7.2 与 Android 构建的版本关系JDK、AGP、SDK 三者怎么配2.1 版本矩阵Gradle 7.2 能配合哪些 AGP 和 JDKGradle 7.2 是 2021 年年中发布的稳定版本在 Android 生态里的位置其实很微妙向上能兼容 AGP 7.0.x 和 7.1.x向下还能跑在 JDK 8 环境上所以很多还在 4.x、5.x 上挣扎的老工程第一次大版本升级往往会选它作为中间站。7.2 相对 7.1 的改动不算激进构建缓存和配置缓存都还在完善期依赖解析性能有些提升但不会逼你改一大堆脚本。我一般配版本时先定 AGP再反过来选 Gradle。常见组合大概是这样AGP 版本最低 Gradle 版本建议 JDK7.0.x7.0JDK 117.1.x7.0JDK 117.2.x7.3.3JDK 11注意AGP 7.2 起最低 Gradle 要求就跳到 7.3.3 了所以如果你手里那份 gradle-7.2-all.zip 是要配合 AGP 7.2.x 用的那 Gradle 版本本身就不够要么把 AGP 降到 7.1.x要么换 Gradle 7.4 以上版本。最容易踩的就是“看别人那边 AGP 升了我就跟着升”结果绕一圈又绕回版本矩阵里。JDK 这块Gradle 7.2 官方支持 JDK 8 到 16 都能运行但 AGP 7.x 强制要求 JDK 11 来编译所以别用 Java 17 直接跑 AGP 7.1会直接报 class file major version 61 不识别。SDK 方面没有硬性版本限制但 compileSdk 建议用 31 或以下配合 Android 12 的 API这样资源和依赖兼容性上的问题最少。2.2 三处需要同步改gradle-wrapper.properties、AGP 插件、JDK 路径把 gradle-7.2-all.zip 落到项目里不只是解压要改的地方其实有三处。第一处是 gradle/wrapper/gradle-wrapper.propertiesAndroid Studio 同步时第一个读的就是它# Wrapper 配置入口sync 时会优先按这里去找 Gradle 发行包 distributionBaseGRADLE_USER_HOME distributionPathwrapper/dists # 个人开发直接 file 协议指向本地 zip内网环境可换成镜像地址 distributionUrlfile\:///D:/dev-tools/gradle-7.2-all.zip networkTimeout10000 validateDistributionUrltrue zipStoreBaseGRADLE_USER_HOME zipStorePathwrapper/dists这里最关键的改动就是把 distributionUrl 从 https 远程地址换成 file 协议指向本地 zip。Windows 路径下 file 协议后面是三个斜杠冒号前要加反斜杠转义Linux 就是 file:///home/you/gradle-7.2-all.zip 这样的写法。networkTimeout 表示下载超时毫秒数离线方案里这个值不太重要但内网镜像场景下 10000 毫秒是经验值短了容易误报。第二处是根目录或模块的 build.gradle 里的 AGP 版本plugins { // AGP 7.1.x 与 Gradle 7.2 搭配是稳定档位 id com.android.application version 7.1.3 // 工程用到 Kotlin 时再加对应插件这里不展开 }AGP 7.1.3 是配 Gradle 7.2 比较稳妥的版本档位Kotlin 插件没有 Gradle 硬绑定但建议用 1.6.x别用 2.0 以后的新 Kotlin 插件带老构建系统会引入新的编译模式。第三处是 Android Studio 里的 JDK 路径。在 File Project Structure SDK Location 里切到 Gradle Settings把 Gradle JDK 指到本机的 JDK 11。Studio 自带的 JBR 可以是 17但那只是 IDE 运行用Gradle 构建还是按这个设置走。很多人在新版 Studio 上遇到构建诡炸就是这里没同步。这三处如果不一致最典型的现象就是 sync 通过但构建报 AGP 最低版本要求不满足或者反过来 sync 就失败。检查顺序建议是先看 wrapper 指向的 zip 路径存在不存在再看 AGP 和 Gradle 矩阵对不对最后确认 JDK 版本。按这个顺序能快速定位八成环境问题。3. 把 zip 装进本地仓库三种安装方式与目录细节3.1 方式一手动解压到用户目录命令行和 IDE 共用一份拿到 gradle-7.2-all.zip 后最直接的动作是解压到一个固定目录让命令行和 Android Studio 都能引用。Gradle 发行包解开后目录结构是固定的bin 里放着 gradle 启动脚本lib 是全部运行依赖 jardocs 是用户手册和 DSL 参考src 里是这个版本的源码init.d 放全局初始化脚本。# 统一放在用户目录下的 dev-tools避免挪来挪去 mkdir -p ~/dev-tools/gradle-dist unzip gradle-7.2-all.zip -d ~/dev-tools/gradle-dist export GRADLE_HOME~/dev-tools/gradle-dist/gradle-7.2 export PATH$GRADLE_HOME/bin:$PATH # 验证版本、JVM 和实际安装目录 gradle --versionunzip 的 -d 参数指定解压目标目录命令执行后会生成 gradle-7.2 这个子目录。GRADLE_HOME 指向的是这个子目录而不是外层。PATH 里加上 bin 后终端里直接敲 gradle 就能调用。gradle --version 的返回里有三行信息要注意Gradle 版本号、JVM 版本号、以及当前机器的主目录。如果 JVM 显示的是 17那你后面用 AGP 7.1 构建时会很痛苦先在这里发现比构建时发现省事得多。这两个 export 命令只在当前终端会话生效。要全局生效把这两行追加到 ~/.bashrc 或 ~/.zshrc 末尾然后 source 一下。团队里如果有多个人共用一台构建机还可以像配 JDK 一样把 Gradle 根路径写进环境变量配置文件避免每个人重复解压一份。这种方式最透明也是后面讲离线构建验证的基础。3.2 方式二通过 Android Studio 指定本地 Gradle 目录Android Studio 本身不强制用 wrapper它允许你直接指向本地已有的 Gradle 发行目录。打开 Settings 下的 Build Tools 面板选择 Gradle再选 Local distribution 并填本地目录路径。这样做的优点是Android Studio 不再下载任何东西同步完全是本地读盘。要注意 Studio 识别的是那种包含 bin、lib 完整结构的目录也就是说填 ~/dev-tools/gradle-dist/gradle-7.2不能填 zip 文件本身也不能填外层 gradle-dist。这个方法适合不想改项目里 wrapper 文件的情况缺点是每个开发者都要在自己机器上手动指定一次换台电脑就丢配置本质上还是在做本地安装管理。如果项目已经用 wrapperStudio 默认优先走 wrapper本地 distribution 设置会被忽略。所以这种方式只对不用 wrapper 的老项目或者你确实想绕开 wrapper 的场景有效。我的习惯是个人临时调试项目用这个方式正式工程一律改 wrapper 的 distributionUrl因为 wrapper 能通过项目文件把版本固定下来别人 clone 下来也跑同一个版本。3.3 方式三把 zip 塞进 wrapper 缓存让下载环节原地消失wrapper 在首次同步时会把 distributionUrl 指向的 zip 下载到本机缓存目录之后每次构建都从缓存解压。如果我们提前把 zip 放到缓存对应位置就能让下载环节整个消失。缓存路径在用户目录下~/.gradle/wrapper/dists/gradle-7.2-all/ 下面会有一个随机哈希串的目录zip 和最终解压出来的目录都在这底下。# 先跑一次 sync 生成哈希目录再把包塞进去覆盖 # Windows: C:\Users\用户名\.gradle\wrapper\dists\gradle-7.2-all\hash\ # Linux: ~/.gradle/wrapper/dists/gradle-7.2-all/hash/ cp gradle-7.2-all.zip ~/.gradle/wrapper/dists/gradle-7.2-all/hash/这个方法的坑在于哈希目录是随机的不同机器上不一样你不能写死。所以我更推荐的做法是手动建好 gradle-7.2-all 这个父目录然后通过修改 wrapper 里的 distributionUrl 指向本地 zip让 wrapper 自己决定缓存组织方式。手动放 zip 只适合你已经明确知道 hash 目录存在、只是 zip 被删掉的修复场景。三种方式里方式三最贴近“让 wrapper 不可见地使用本地资源”这个目标但可维护性最差方式二适合个人临时用方式一最透明而且能直接配合命令行做构建验证。如果你要统一团队环境我建议方式一加方式二双保险命令行和 IDE 都能用同一份包。安装方式适用场景可维护性手动解压命令行与 IDE 共用、团队标准化高Studio 本地指定个人单机、老项目临时调试低wrapper 缓存赛包修复已存在哈希目录的缓存缺失低提示手动往 wrapper/dists 下塞 zip 时哈希目录名别写死脚本里要动态探测当前存在的目录名。4. 升级到 Gradle 7.2 的构建脚本改造DSL、依赖和缓存的三处改动4.1 依赖管理里从 compile 到 implementation 的迁移Gradle 7.x 把一批老 API 标记为移除状态最典型的是依赖配置里的 compile。Android 老工程里最常见的写法是compile com.example.network:http:1.0这个写法从 4.x 开始废弃到 7.2 已经完全移除了。升级时如果不改构建会直接报找不到 compile 配置而不是给个警告。dependencies { // 旧写法已不可用 // compile com.example.network:http:1.0.0 // 内部依赖只在当前模块里可见不对外传递 implementation com.example.network:http:1.0.0 // 对外暴露依赖当前模块的其他模块能看到这个库 api com.example.ui:design-system:1.2.0 // 仅编译期使用运行时由运行环境提供 compileOnly com.example.tools:annotation-processor:1.0.0 annotationProcessor com.example.tools:annotation-processor:1.0.0 }implementation 和 api 的区别要按模块边界来理解。implementation 引入的库只会出现在当前模块的运行时 classpath 里上游模块看不到好处是编译更快、下次构建缓存命中率更高api 会把库传到依赖树上让依赖当前模块的其他模块也能直接用代价是会拖慢编译。compileOnly 最典型的场景是注解处理器这类只在编译期出现的东西。迁移的时候不要无脑把 compile 全换成 implementation先想清楚这个依赖是否需要被模块外部引用。4.2 缓存目录结构变化与磁盘清理Gradle 7.2 的缓存目录在用户目录的 .gradle/caches 下里面有几个关键子目录modules-2 存依赖元数据transforms-3 存 AAR 转换产物build-cache-1 存构建缓存。升级上来后你会发现旧的 modules-1、transforms-1、transforms-2 这些老目录会残留磁盘占用大的根本原因往往不在项目 build 目录而在这堆缓存目录里。# 先看缓存占了多少空间 du -sh ~/.gradle/caches # 删掉历史残留目录注意等最新版本构建稳定后再删 rm -rf ~/.gradle/caches/modules-1 rm -rf ~/.gradle/caches/transforms-1 rm -rf ~/.gradle/caches/transforms-2 # 项目级清理构建产物 ./gradlew clean反过来如果你发现构建依赖解析总是报错先把 modules-2 删掉让 Gradle 重新拉比在网上一通搜有效。Gradle 7.2 里 transforms-3 是 AAR 资源转换后的输出新版本会自动用老目录不会自动清理这就是磁盘悄悄变大的原因。清理前确认构建稳定一旦删了就要重新下载内网镜像不稳定的话这步会比较疼。4.3 构建性能参数堆内存、并行开关与配置缓存升级到 Gradle 7.2 最容易获得体感提升的是 gradle.properties 里的几个参数。Gradle 默认 JVM 堆只有 1GB 左右Android 工程很容易 OOM所以第一件事是调 jvmargs。配置缓存在这个版本还挂着 unsafe 前缀建议要开也要用单独分支验证别在主分支直接上。# gradle.properties与 settings.gradle 同目录 # 堆内存加到 2GMetaspace 也要给够否则反射多的工程频繁 Full GC org.gradle.jvmargs-Xmx2048m -XX:MaxMetaspaceSize512m # 多模块并行构建模块间无强依赖时收益明显 org.gradle.paralleltrue # 按需配置只配置要构建的模块大工程效果好小工程慎用 org.gradle.configureondemandtrue # 构建缓存相同输入直接复用输出开启后注意验证增量产物 org.gradle.cachingtrueparallel 参数在多模块工程里能把耗时从 10 分钟压到 5 分钟以内但前提是模块之间没写乱七八糟的依赖关系。configureondemand 是双刃剑只配置当前需要的模块但如果脚本里依赖了未配置模块的属性会报类找不到小工程建议关掉。caching 一旦开起来Gradle 会跨构建复用产物但 AAR 或插件输出变化时可能拿到旧产物所以在 CI 和本地的缓存行为不一致时先关掉再排。5. 避坑Gradle 7.2 使用中的五个常见问题与排查路径5.1 sync 卡在 Downloading远程下载链路不通现象Android Studio 首次打开工程或切换 Gradle 版本时Status 栏一直显示 Downloading gradle-7.2-all.zip进度条不动最后超时。原因wrapper 默认从远程地址下载网络连接不通或公司网络屏蔽了该下载源。解决别等它直接把 distributionUrl 改成 file 协议指向本地 zip或者把 zip 放到 wrapper 缓存目录下让 wrapper 跳过下载这步直接解压。改完后注意清掉项目里的 .idea 和 .gradle 下残留否则 Studio 有时会读旧缓存继续卡。5.2 报 Unsupported class file major version 61JDK 版本超限现象构建或 Gradle 解析插件时报错核心信息是 Unsupported class file major version 61。原因Gradle 7.2 的运行 JVM 版本太高。major version 61 对应 Java 17Gradle 7.2 虽然能在 JDK 17 上启动但 AGP 7.1 的很多字节码处理逻辑没有适配 17。解决把 Gradle JDK 切到 JDK 11同时检查 JAVA_HOME 和 Android Studio 的 Gradle JDK 设置。如果你机器上只有一个 JDK 17装个 JDK 11 并让构建环境指过去IDE 本身的 JBR 不受影响。5.3 报 Minimum supported Gradle versionAGP 与 Gradle 矩阵错位现象sync 阶段报 Minimum supported Gradle version is 7.3.3 之类的错误。原因当前 AGP 版本要求的最低 Gradle 高于你配的 7.2。解决两条路把 AGP 降到 7.1.x或者把 Gradle 升到匹配版本。建议先查版本矩阵再决定动哪边。gradle-7.2-all.zip 要配 AGP 7.1.x 最省事别硬怼新版 AGP。5.4 离线构建报 Could not resolve all artifacts缓存里根本没有依赖现象开启 --offline 后构建失败错误是 Could not resolve all artifacts for configuration。原因Gradle 离线模式只认 ~/.gradle/caches/modules-2 里的东西如果之前没做过一次完整在线构建缓存就是空的离线必然失败。解决先在线跑一次能通过的构建让依赖落进缓存再切离线或者在 repositories 里配置内网镜像仓库。别一上来就开 offline本地没有依赖闭环离线构建只是个摆设。5.5 配置缓存开启后插件内部报错实验特性背锅现象org.gradle.unsafe.configuration-cachetrue 打开后构建报 plugin internal error堆栈完全看不懂。原因Gradle 7.2 的配置缓存还属于实验特性插件没做适配序列化构建状态时就会炸。解决先关掉配置缓存把插件升到适配版本再决定是否重新开启。这个特性在 7.2 里不值得为那点秒级的提速搭进去排障时间除非你的工程没有 Android 插件只有纯 Java 模块。6. 验证安装与构建可复现性几个值得养成的检查习惯包解压完、wrapper 改完参数别急着点 Run。验证的顺序有个套路先用命令行确认环境能闭环再用警告模式扫一遍老脚本的遗留问题最后做一次干净环境的全量构建。这三个动作按顺序来能在十分钟内把版本升级的大部分隐患暴露出来。第一步用命令行直接验证本地环境# 离线构建一次验证 zip 路径、JDK 版本、依赖缓存是否全部闭环 ./gradlew assembleDebug --offline --consoleplain--offline 让 Gradle 完全不碰网络能通过说明三个关键点都对了。--consoleplain 的作用是让日志以纯文本输出不进入交互界面方便直接记录到文件。如果这一步报错先别怀疑业务代码大概率是环境层面的问题比如 zip 路径没指对、JDK 切到了 17、或者某个依赖从来没有进过本地缓存。第二步扫描废弃 API 和构建警告# 把所有 deprecated 调用和警告全部暴露出来升级后的扫尾检查 ./gradlew build --warning-modeall--warning-modeall 会把构建脚本里所有废弃写法的位置和替代方案打印出来。Gradle 升级后最隐蔽的问题不是编译报错而是静默警告比如老式的 maven 仓库写法、被移除的依赖配置、过时的插件 API都会在这里现形。不要忽略这些警告它们大多在你换下一个版本时就变成硬错误。第三步做干净环境复现测试。删掉项目根目录下的 .gradle 和所有模块的 build 目录再清掉 ~/.gradle/caches 里和本项目相关的缓存子目录然后重新跑离线构建。这一步专门用来揭露靠增量缓存掩盖的问题本地仓库里其实缺少某个传递依赖、某个插件在冷启动时的配置顺序不对这些在第二次构建时因为缓存存在不会出现清理后立刻暴露。我第一次配 Gradle 7.2 时没做这套东西把 zip 解压完、sync 通过就以为搞定了。结果代码切到另一台机器上第一次全量构建光缺依赖就折腾了一下午最后发现缓存目录里少了一个老版本的库在线下载又超时。从那以后我每次落地 gradle 版本都强制走一遍本地解压、改 file 协议、offline 构建、warning 扫描的完整流程。多花十来分钟把那些说不清的玄学构建问题全挡在门外。如果你现在正被项目里纷乱的 Gradle 版本拖着后腿这份 gradle-7.2-all.zip 不妨先放在本地下次配环境时照着这套流程走一遍能省不少事。希望帮到你。本文还有配套的精品资源点击获取