Android 打包时 gradlew 找不到命令不是环境变量问题
bash
Linux/macOS 查看当前路径
pwd
Windows 查看当前路径
cd
请确保你的终端路径指向项目根目录。如果不在,先用 `cd` 进入正确目录,例如:
```bash
cd ~/AndroidStudioProjects/MyApp
再尝试执行:
./gradlew tasks # 测试是否可执行
排查二:gradlew 文件真的存在吗?
有些版本管理工具(如 Git)可能忽略了 gradlew 文件。或者你克隆项目时忘记加上 --recurse-submodules,导致某些子模块缺失文件。
检查文件是否存在:
# Linux/macOS
ls -l gradlew
# Windows 命令行
dir gradlew*
正常情况下你会看到 gradlew 和 gradlew.bat。如果只有 gradlew.bat 而没有 gradlew,通常是因为项目是从 Windows 环境生成的,而你正在 Linux/macOS 下工作。
解决方法:
在项目根目录执行一次 Gradle 初始化命令,重新生成 wrapper 文件(前提是系统级 Gradle 已安装),但更推荐的方式是让项目重新生成 wrapper:
gradle wrapper --gradle-version 7.5 # 用你项目需要的版本号
执行后,项目根目录会自动补齐 gradlew 和 gradlew.bat,以及 gradle/wrapper/gradle-wrapper.properties。
排查三:执行权限被“封印”
这是 Linux/macOS 用户最高频的坑。从网上下载的 zip 包、从 Windows 拷贝的项目,或者通过某些工具解压后,gradlew 脚本往往丢失了可执行权限。
症状:
bash: ./gradlew: Permission denied
如何确认:
ls -l gradlew
输出可能是 -rw-r--r--,没有 x(执行)标记。
解决方法:
赋予执行权限:
chmod +x gradlew
再尝试运行 ./gradlew --version,一切正常。
对于 Windows 用户,不存在权限问题,直接使用 gradlew.bat 或在 Git Bash 中使用 ./gradlew(Git Bash 模拟了 Linux 权限体系,同样可能遇到权限缺失,一样需要 chmod +x)。
排查四:换行符的“跨平台暗箭”(CRLF vs LF)
你是否遇到过这样的诡异错误:
/bin/sh^M: bad interpreter: No such file or directory
或者 gradlew 运行后直接报错退出,提示一些不可见字符?
罪魁祸首是 Windows 风格的换行符 CRLF(\r\n)混入了 Linux/macOS 系统中的脚本文件。当你在 Linux 上打开一个 CRLF 结尾的 gradlew,解释器会把末尾的 \r 视为文件名的一部分,从而找不到 /bin/sh\r,抛出 “bad interpreter”。
检查文件换行符:
- 用
vim打开 gradlew,执行:set ff?,若显示fileformat=dos则说明是 CRLF。 - 或用
cat -v gradlew查看行尾是否出现^M。
解决方法:
将文件转换为 Unix 格式(LF):
# 使用 sed 删除 \r
sed -i 's/\r$//' gradlew
或使用 dos2unix 工具(需安装):
dos2unix gradlew
完成后再赋予执行权限 chmod +x gradlew,问题消失。
提示:在 Windows 上使用 Git Bash 或 WSL 时常出现此问题,可以配置 Git 全局
core.autocrlf input,让 Windows 本地使用 CRLF,但提交到仓库时自动转换为 LF,从根源上避免。
排查五:Java 路径在脚本里“写死”了吗?
如果以上排查均正常,但运行 gradlew 时提示找不到 Java 或 JAVA_HOME,先别急着去系统环境变量里改来改去,很可能 gradlew 脚本里指定了错误的 Java 路径。
打开 gradlew 文件(文本编辑器即可),找到类似以下的配置段落:
# 默认的 JVM 参数配置
DEFAULT_JVM_OPTS='"-Xmx64m" "-Xms64m"'
# 寻找 Java 的位置
if [ -n "$JAVA_HOME" ] ; then
JAVACMD="$JAVA_HOME/bin/java"
...
fi
有些团队会硬编码 Java 路径,比如在脚本开头添加:
JAVA_HOME=/usr/local/old_java