非零退出码不是错误本身，而是子进程向Gradle报告“我失败了”的信号；它只说明某步执行未返回0，真正问题藏在日志中紧邻的上几行，需结合task名称、报错上下文及最近修改定位。
非零退出码不是错误本身，而是子进程向 Gradle 报告“我失败了”的信号。 它不告诉你哪里错了，只说明某一步执行没成功返回 0。真正的问题藏在它前面的日志里。
为什么 Gradle 会把非零退出码当失败
Gradle 本身不直接编译 Java 或打包资源，它调用外部工具（比如 java.exe、aapt.exe、javac）来干活。这些工具按 Unix/Linux/Windows 通用约定：成功返回 0，失败返回 1、2 等非零值。Gradle 看到非零就中断当前 task，并抛出类似 Process 'command 'java.exe'' finished with non-zero exit value 1 的提示。
-
exit value 1最常见，多对应编译错误、资源找不到、Manifest 冲突、Java 源码语法问题 -
exit value 2常见于 jar 包重复（如两个support-v4）、multidex 配置缺失、或 JVM 启动失败 -
exit value 3+较少见，可能涉及 native 编译（NDK）、磁盘满、权限不足等底层问题
怎么快速定位真正出错的那行日志
别只盯着最后一句 finished with non-zero exit value X。Gradle 日志是倒着读的——错误源头往往在它上面 5～20 行之间，尤其是紧挨着的 Execution failed for task ':xxx' 那一行之后的内容。
- 用
--stacktrace重跑：能看到 Java 异常栈，锁定具体类和方法 - 用
--info或--debug：暴露被调用的完整命令行，比如实际执行的是哪条java -jar ... - 在 Android Studio 中，点开 Build 窗口右上角的 Toggle view，切换成 Text 模式，避免折叠关键报错
常见触发命令和对应修复方向
看到不同 task 名称，基本能判断问题类型：
-
:app:processDebugResources→ 检查res/下的 XML 资源，比如@drawable/xxx找不到、字符串未转义、layout 中 ID 重复 -
:app:transformClassesWithDexForDebug→ 多为 multidex 未启用或依赖冲突，确认defaultConfig { multiDexEnabled true }已设 -
:com.ford.easy.EASYServiceApplication.main()→ 这是运行时失败，不是编译问题；检查 main() 方法逻辑、Spring Boot 配置、或 JVM 参数是否超限 -
R CMD INSTALL或javah被调用失败 → 可能是编码（如 UTF-8 vs GBK）、路径含空格、或环境变量（JAVA_HOME）指向错误 JDK
最易被忽略的一点：非零退出码本身没有上下文。同一个 exit value 1，在 javac 和 aapt 里代表完全不同的失败原因。必须结合 task 名称 + 紧邻日志 + 你最近改过的代码/配置，才能准确定位。不要跳过日志里任何带 Error:、Caused by: 或文件路径的那一行。
