Linux运维实战：CentOS 7.9高频命令速查与操作指南
2026/10/15 11:03:33
刚接触 Android SDK 命令行工具的人，十有八九会在第一次执行sdkmanager时撞到一个看起来很吓人、其实很莫名其妙的提示：Warning: Could not create settings。我第一次遇到它是在一台刚装好 JDK 的虚拟机上，当时以为安装包坏了，重新解压了好几次，问题照旧。后来把 Java 的偏好设置机制、SDK 目录规范和许可证流程翻了个遍，才算真正看清楚这行 Warning 的来路。这篇文章就把这段排查经历完整写出来，给同样被它卡住的朋友一条可以直接照做的路径。
文章会从报错的底层原因讲起，再讲 JDK、目录结构、环境变量这些前置条件，然后给出完整的排查顺序和分平台解决方案。无论你是第一次使用命令行工具链，还是在 CI 脚本里反复看到这行提示，按下面的顺序逐项排掉，基本能一次解决。
1. 先别急着改配置：搞清楚“Could not create settings”到底卡在哪
1.1 报错现场与触发规律
这个警告最常出现的场景有三个：第一次运行sdkmanager的全新环境、用户目录权限被改乱过的旧环境、以及容器或虚拟机上以 root 身份运行的环境。终端里通常会长这样：
Warning: Could not create settings java.lang.IllegalStateException: BackingStoreException at java.util.prefs.FileSystemPreferences.syncWorld at java.util.prefs.FileSystemPreferences.flush ...麻烦的地方在于，这行 Warning 出现之后，sdkmanager并不会马上退出，它可能照常打印版本号，甚至能列出部分软件包。于是很多人觉得“反正只是警告”，继续往下装东西，结果后面蹦出来一堆更奇怪的错误：许可证反复要求确认、组件下载到一半失败、SDK 目录里写不进文件。
这里的关键规律是：Warning 本身只是表象，真正要关注的是“这个工具到底有没有能力保存状态”。如果保存状态这条路被堵死，很多后续操作都会在暗处出错。
1.2 底层机制：sdkmanager 用 Java 偏好设置存状态
sdkmanager本身是用 Java 写的，启动时它要读取和保存用户偏好设置，这些设置包括许可证协议是否接受、历史配置、窗口状态等。Java 的 Preferences API 默认把用户级数据放在两个位置：
- Unix 系系统：
$HOME/.java/.userPrefs/目录下的 XML 文件 - Windows 系统：注册表
HKCU\Software\JavaSoft\Prefs子树
正常情况下，Java 运行时会自动创建这些路径。但一旦用户目录不存在、不可写，或者注册表对应的键被策略锁住，Preferences API 就会抛出异常。sdkmanager对异常做了捕获，没有让进程直接崩溃，而是降级成一行 Warning 继续运行。
理解这一层之后，后续的解决思路其实就浓缩成一句话：给 Java 的偏好设置找一个能真正写入的位置。
| 触发场景 | 直接原因 | 修复方向 |
|---|---|---|
| 全新环境首次运行 | $HOME下没有.java目录且自动创建失败 | 手动创建目录并授权 |
| 使用 sudo/root 运行 | HOME指向了不可写目录 | 保留原环境变量或显式设置 HOME |
| Windows 注册表受限 | HKCU\Software\JavaSoft被策略锁定 | 用环境变量把 prefs 指到文件目录 |
| 容器只读文件系统 | 根目录或用户目录不可写 | 挂载可写卷并设置 prefs 位置 |
1.3 这个警告是“小毛病”还是“大问题”
如果sdkmanager只是打印 Warning，但--version、--list都正常，而你只是临时查一下组件列表，那它可以先放着不管。
但如果接下来要做这几件事，就必须处理：
- 接受许可证协议
- 安装或更新 SDK 组件
- 在 CI 脚本中自动执行构建相关命令
原因很简单：许可证的“已接受”状态就是靠这套 Preferences 机制持久化的。状态写不进去，等于每次都要重新接受一遍，或者每次都拿不到完整的软件包列表。与其等到 CI 流水线里爆发，不如一开始就把这个坑填平。
2. 基础底子没打好，sdkmanager 后面还会有一堆连锁问题
2.1 JDK 版本：多数人栽在这里
Android 官方近几年发布的命令行工具包，内置的sdkmanager基本上默认要求 JDK 17。如果你的机器上还在用 JDK 8 或 JDK 11，可能不会立刻收到一句友好的“版本太低”提示，而是先遇到一串类加载异常，或者一堆让人摸不着头脑的报错。
执行下面这条命令，先确认 Java 版本：
java -version不同情况的参考判断如下：
| 环境中的 JDK | 现象 | 建议 |
|---|---|---|
| JDK 17 | 正常使用 | 保持即可 |
| JDK 11 | 部分可用，可能偶发异常 | 建议升级到 17 |
| JDK 8 或更老 | 各种诡异报错 | 直接装 JDK 17 |
| 只有 JRE | 运行时找不到类 | 安装完整 JDK |
安装 JDK 17 之后，务必设置JAVA_HOME，并且把它加进PATH。Windows 用户还要注意：改完环境变量后，必须新开一个 cmd 或 PowerShell 窗口，让新配置真正生效。很多人改了系统变量后直接在旧窗口里重试，当然还是报错。
2.2 cmdline-tools 目录放置：目录结构不对，位置全乱
这个坑非常隐蔽。从官网下载的 zip 解压以后，第一层目录就是cmdline-tools，里面才是bin、lib等子目录。
规范的做法，是把它移动到 SDK 根目录下的cmdline-tools/latest/里，最终形成这样的结构：
<SDK_ROOT>/ ├── cmdline-tools/ │ └── latest/ │ ├── bin/ │ │ ├── sdkmanager │ │ ├── sdkmanager.bat │ │ └── avdmanager │ ├── lib/ │ └── ... ├── build-tools/ ├── platforms/ └── platform-tools/如果你直接解压成<SDK_ROOT>/cmdline-tools/bin/这种结构，工具链会认为目录不完整，随后报出各种连锁错误。因为工具链默认用latest这个固定路径寻找可执行文件，版本号目录只是供多版本并存用的，没有latest这一层，它根本不知道去哪个目录找入口。
Linux 和 macOS 上，建议用mv把内容移动到目标位置；Windows 上，先解压到临时目录，再把内部文件移动过去。千万别图省事，把 zip 内容直接全部倒在 SDK 根目录下，那样必然出问题。
2.3 环境变量和 --sdk_root 的关系
sdkmanager在定位 SDK 根目录时，会先看命令行参数，再看环境变量，最后才会根据自身路径反推。命令行参数的优先级最高。
为了避免意外，我建议在任何脚本里都显式传--sdk_root，而不是依赖环境变量，同时把ANDROID_SDK_ROOT也设成同一个值。这样无论哪个环节读取配置，拿到的根目录都是一致的，不会出现“这个命令认一个目录、那个命令认另一个目录”的混乱。
另外，ANDROID_HOME是旧名称，很多老教程还在用。虽然新版本工具不一定依赖它，但为了兼容旧脚本，最好也一并设成相同路径。三个位置统一之后，很多看似随机出现的错误会直接消失。
3. 完整排查链路：从看到警告到恢复正常跑通的每一步
3.1 先用一条命令判断是环境问题还是工具问题
不要一上来就删目录重装。先在一个终端里依次执行下面这几条，把输出记下来：
java -version echo "JAVA_HOME=$JAVA_HOME" echo "ANDROID_SDK_ROOT=$ANDROID_SDK_ROOT" echo "ANDROID_HOME=$ANDROID_HOME" echo "HOME=$HOME" sdkmanager --version如果sdkmanager --version本身能输出版本号，说明可执行文件是好的，问题集中在环境或偏好设置上。如果连版本都出不来，先检查 JDK 和目录结构。
这一步看起来简单，但确实能帮你少走很多冤枉路。我见过有人花一晚上重装系统依赖，最后发现只是 cmd 窗口没重开，JAVA_HOME还是空的。
3.2 给 Java 偏好设置一个能落脚的目录
确认HOME指向一个真实存在、可写的目录之后，手动创建userPrefs目录，并检查当前用户有没有写权限：
mkdir -p "$HOME/.java/.userPrefs" chmod 700 "$HOME/.java"Windows 上通常不需要这一步，因为偏好设置写的是注册表。但如果遇到过注册表被策略锁定的情况，可以用环境变量强制 Java 把偏好设置写到文件目录里：
export JAVA_TOOL_OPTIONS="-Djava.util.prefs.userRoot=$HOME/.java/.userPrefs"把这条export写进 shell 配置文件，或者在 CI 脚本开头执行。这样sdkmanager就会把偏好设置写到$HOME/.java/.userPrefs下的文件里，不再依赖系统默认位置，Windows 上也能避开注册表限制。
3.3 接受许可证：一个被忽略的隐藏入口
很多人以为--licenses只是同意几个协议，其实这个动作会真实地写入许可证状态，而写入行为正好依赖上面说的 Preferences 机制。
如果 preferences 写不进去，你就算当场按着 y 过完所有协议，下次执行命令时它依然会提示你没接受。正确顺序是：先解决userPrefs的可写问题，再一次性接受许可：
yes | sdkmanager --sdk_root="$ANDROID_SDK_ROOT" --licenses执行时不需要盯着屏幕，结束提示出现之后就说明状态已经写入。如果没有正常结束，回头检查上一步的目录权限，多半是某个路径没有写权限。
3.4 把 SDK 根目录写在明处
接下来执行任何sdkmanager命令，都显式加上--sdk_root，防止它跑偏：
"$ANDROID_SDK_ROOT/cmdline-tools/latest/bin/sdkmanager" \ --sdk_root="$ANDROID_SDK_ROOT" \ --list这样即使环境变量在某个脚本里被临时覆盖，命令行参数仍然能保证它指向正确的根目录。这个习惯在 CI 场景里尤其重要，因为构建服务器的环境经常被多个脚本共用，环境变量被覆盖是常有的事。
3.5 验证：能列包、能安装、能接受许可证
修复完成之后，做三步验证，缺一不可：
- 列包：执行
--list，能正常输出组件列表 - 安装：装一个体积很小的组件，比如
platform-tools，确认能写入 SDK 目录 - 再验许可：再次执行
--licenses，确认没有反复提示同意协议
都通过后，那个 Warning 基本就会消失。如果 Warning 还在，但功能完全正常，那说明还有别的东西在控制 Java 的 prefs 路径，可以接着看下一章的专题排查。
4. 分平台破案：Windows 注册表、macOS 路径、容器环境各有各的坑
4.1 Windows：权限是万恶之源
Windows 上最容易踩的坑，是把 SDK 根目录选在了系统保护目录下。把cmdline-tools解压到C:\Program Files\Android\Sdk后，普通用户运行sdkmanager时根本没有写权限，各种报错就会以千奇百怪的形式冒出来。
建议直接把 SDK 放在C:\Android\Sdk或者%USERPROFILE%\Android\Sdk这类普通用户可写的路径，尽量避免带空格的 Program Files 路径。在 cmd 里执行sdkmanager.bat之前，先确认新开的窗口里JAVA_HOME是否生效：
echo %JAVA_HOME%如果显示为空，设置完环境变量后要重新开 cmd。注册表问题比较少见，但在公司统一管理的机器上，组策略确实可能锁定HKCU\Software\JavaSoft子树。这时候用JAVA_TOOL_OPTIONS把 prefs 指到文件目录，是唯一的绕行办法。
4.2 Linux/macOS：HOME 与 .java 目录的隐形地雷
Linux 上最常见的坑是 sudo。你明明是当前用户，但执行sudo sdkmanager ...之后，HOME可能变成/root，而/root下可能没有.java目录，或者/root本身权限设置很严。
解决方案是尽量不用 sudo 执行sdkmanager，如果非要用，就加上-E参数保留原有环境变量：
sudo -E sdkmanager --sdk_root="$ANDROID_SDK_ROOT" --listmacOS 上要特别注意JAVA_HOME的路径，它通常指向/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home，而不是外层目录。还有一种情况是自动挂载的 home 目录在初始化时没有执行.zshrc或.bashrc，导致PATH缺了 JDK 路径。出现奇怪报错时，先跑一遍which java，确认实际指向的是哪个 JDK 再往下查。
4.3 Docker/CI 与无显示环境：三种额外配置别漏
容器环境里这个警告几乎必现，根因基本都在于没有给 Java 一个可写的 HOME。我常用的组合有四个：
- 明确设置
ENV HOME=/root或/home/builder，并保证对应目录存在 - 启动脚本里先执行
mkdir -p "$HOME/.java/.userPrefs" - 所有
sdkmanager命令都带--sdk_root - 许可证接受过程用
yes |非交互式处理
另外，基础镜像里要提前装好unzip和ca-certificates。缺解压工具会出现 zip 打不开的诡异现象，很容易让人误判成别的错误。如果容器以只读文件系统运行，SDK 目录必须挂成可写卷，否则任何写入都会被拒绝，那已经不只是 prefs 层面的问题了。
5. 让这个报错从此消失：一份可直接套用的初始化脚本与日常维护习惯
5.1 一个跨平台的检查脚本骨架
下面这段脚本适合 Linux 和 macOS，我经常把它放到新环境的初始化步骤里。它不算最精简，但每一步都有明确目的：
#!/usr/bin/env bash set -euo pipefail SDK_ROOT="${ANDROID_SDK_ROOT:-$HOME/Android/Sdk}" export ANDROID_SDK_ROOT="$SDK_ROOT" # 1. 给 Java 偏好设置留好位置 mkdir -p "$HOME/.java/.userPrefs" # 2. 确认 cmdline-tools 目录结构 CMDTOOLS="$SDK_ROOT/cmdline-tools/latest" if [ ! -x "$CMDTOOLS/bin/sdkmanager" ]; then echo "sdkmanager not found under $CMDTOOLS/bin" exit 1 fi # 3. 检查 JDK java -version # 4. 非交互接受许可 yes | "$CMDTOOLS/bin/sdkmanager" --sdk_root="$SDK_ROOT" --licenses # 5. 列出组件验证 "$CMDTOOLS/bin/sdkmanager" --sdk_root="$SDK_ROOT" --listWindows 上把命令换成sdkmanager.bat，把$HOME改成%USERPROFILE%，思路完全一样。这套脚本跑完，通常不会再出现Could not create settings。
5.2 日常维护：升级、更新与清理
升级cmdline-tools时，不要直接覆盖latest目录，最好把新下载的 zip 解压到临时目录，确认没问题后整体替换。如果.java/.userPrefs里的 XML 文件被写坏了，或者你想彻底重置偏好，可以先把该目录改名备份，再让 Java 自动重建，这比反复猜测配置内容可靠得多。
SDK 组件更新用sdkmanager --update也可以，但建议在重要项目里手动看一遍变更内容，避免工具链突然跨大版本导致构建行为变化。别小看这些日常小事，很多潜伏问题都是组件版本不一致引出来的。
5.3 警告还在但功能正常，要不要继续管
如果你只是偶尔手动跑一条命令，并且确认列表、安装、许可都没有问题，留着这行 Warning 也无所谓。
但如果它出现在自动化流水线里，我还是建议花几分钟处理掉。流水线日志里的 Warning 很容易被误判成失败原因，到时候排查起来成本比修复成本还高。我自己的习惯是：只要报错信息里出现Could not create settings，就先检查userPrefs和--sdk_root两处，几乎五分钟内能解决。
最后说一点个人体会：这类问题最迷惑人的地方，在于它不会让命令立刻崩掉，而是留着一个看似无害的 Warning 让你继续往前走。真正被它坑到的时候，往往是半个月后你在 CI 日志里发现许可证状态丢失、组件装了一半失败，回溯之后才发现源头就是当初那行不起眼的提示。所以遇到它，不值得绕路。按照“基础环境、目录结构、偏好设置、许可状态”这个顺序查一遍，后续所有依赖sdkmanager的操作都会顺畅很多。