简介：面向 Windows 平台开发者的 Android 命令行工具集最新版压缩包，专为无需安装完整 Android Studio 的用户设计。内含 sdkmanager、avdmanager 等核心可执行组件，可通过命令行下载 SDK 包、管理虚拟设备、执行构建与调试任务，适合习惯终端操作或需轻度开发环境的工程师与学习者。压缩包共 108 个文件，主要为 95 个 JAR 运行库与 10 个 BAT 启动脚本，另含配置与说明文档，整体大小 136.41MB，解压即可使用。工具集中 sdkmanager 尤其重要，能够按需获取系统镜像、API 文档及模拟器组件；lint 与 d8/r8 等则协助静态检查与代码压缩，方便接入自动化构建与持续集成流程。目前已有 544 人浏览学习，属于轻量、可裁剪的开发基座，适合需要快速搭建命令行 Android 环境或希望深入理解 SDK 工具链的开发者。
1. 先认清这个 zip 是什么：一个没有 SDK 的 SDK 管理器
如果你在一台干净的 Windows 机器上，既不想装一整个 Android Studio，又想在 CI 里跑构建、造模拟器、精确管理 SDK 版本，那你下载的东西大概率就是 Android 命令行工具（commandlinetools-win-13114758-latest.zip）。这个 zip 体积不大，但它解决的是大问题：把 sdkmanager、avdmanager、lint 这些管理能力从图形界面里拆出来，让你能用脚本操作整个 Android SDK。这里有个反直觉的事实：它本身不含 adb，也不含任何 system-image 和 platform 包，更像一个启动器。所有真实组件都得靠它去下载，所以搞懂它的运行机制比下载本身更重要。这套工具适合三类人：不装 Studio 的命令行党、维护 Windows CI 的工程师、想精确固定 SDK 版本的插件开发者。下载只是第一步，真正的坑在后面的目录结构、JDK 和许可证。
2. 落地先过目录关：cmdline-tools/latest 结构与两个环境变量
2.1 解压到正确位置：cmdline-tools/latest 的意义
很多人第一步就翻车。这个 zip 解压后直接得到一个cmdline-tools文件夹，里面有bin/、lib/、source.properties、NOTICE.txt。如果你把cmdline-tools\bin直接加到 PATH，然后跑sdkmanager.bat，大概率会看到类似Could not determine SDK root的报错。原因是 sdkmanager 靠自身路径反推 SDK 根目录，它默认寻找的结构是$SDK_ROOT/cmdline-tools/latest/bin/sdkmanager.bat，而不是$SDK_ROOT/cmdline-tools/bin/。
常见做法是：在某个磁盘根下建一个干净的 SDK 目录，把解压出来的整个cmdline-tools文件夹移动进去，并改名为latest，最终形成C:\Android\sdk\cmdline-tools\latest\bin\sdkmanager.bat。我用的是C:\Android\sdk，不带空格，避免后续脚本解析出幺蛾子。命令如下：
mkdir C:\Android\sdk\cmdline-tools move Downloads\cmdline-tools C:\Android\sdk\cmdline-tools\latestdir C:\Android\sdk\cmdline-tools\latest\bin移动后dir应该能看到sdkmanager.bat、avdmanager.bat、apkanalyzer.bat、lint.bat这几个关键文件。这里latest是工具内部约定的相对路径，不是随意起的名字。如果你把目录叫tools-2024，它还是会找不到自己。如果你机器上已经有一份 Android Studio 的 SDK，我更建议复用：把cmdline-tools放到那一份 SDK 根目录的cmdline-tools\latest下，这样命令行工具和 Studio 共用同一套platforms、build-tools，不会出现两套 SDK 各占几个 GB 的尴尬。
2.2 环境变量：ANDROID_HOME、JAVA_HOME 与 PATH
sdkmanager 是 Java 程序，先决条件是 JDK。现在新版命令行工具最低要求是 JDK 17，如果你还在用 JDK 8 或 11，启动时直接报UnsupportedClassVersionError。如果你装有 Android Studio，最省事的办法是把JAVA_HOME指向 Studio 自带的 jbr 目录，那是经过验证的 JDK 17，不用额外装 Java。没有 Studio 的话，单独装一个 JDK 17 也很快。
环境变量我一般同时设置ANDROID_HOME和ANDROID_SDK_ROOT。虽然新官方建议是ANDROID_SDK_ROOT，但老项目、老 Gradle 插件还在读ANDROID_HOME，两个都设置才不会踩坑。在 Windows 上用setx设置，注意setx不影响当前终端窗口，设置完要开一个新的终端再验证。
setx ANDROID_HOME "C:\Android\sdk" setx ANDROID_SDK_ROOT "C:\Android\sdk" setx JAVA_HOME "C:\Program Files\Android\Android Studio\jbr" setx PATH "%ANDROID_HOME%\cmdline-tools\latest\bin;%ANDROID_HOME%\platform-tools;%ANDROID_HOME%\emulator;%PATH%"PATH 里提前把platform-tools和emulator也放进去，是为了免去后面装完包再改一次环境变量的重复劳动。cmdline-tools\latest\bin放在最前面，保证你敲sdkmanager时命中的是预期那个，而不是某个残留的旧版本。
2.3 最小验证：sdkmanager --version 与 --sdk_root
设置完环境后，先做最小验证，别急着装包。打开新终端，运行：
sdkmanager --version如果输出一串版本号就没问题。如果提示找不到 sdkmanager，先查两件事：sdkmanager.bat是否真的在C:\Android\sdk\cmdline-tools\latest\bin下，以及 PATH 是否生效。还有一种情况是目录暂时改不动，可以用--sdk_root强指：
sdkmanager --sdk_root=C:\Android\sdk --list--sdk_root的作用是绕过自动探测，直接告诉 sdkmanager SDK 根目录在哪。这个参数在后续所有命令里都能用，特别是当你把 SDK 放在非约定位置时，它就是后悔药。现在能跑通这两条，说明目录、JDK、PATH 三关都过了，可以进入下一个环节。
3. 用 sdkmanager 装出第一套基础 SDK：ID、版本、许可证一个都不能漏
3.1 先读懂 sdkmanager --list 的输出
sdkmanager 本质上是一个包管理器，类似针对 Android SDK 的apt或npm。它管理的每个包都有一个唯一 ID，格式像platforms;android-34、build-tools;34.0.0、system-images;android-34;google_apis;x86_64。包名是分号分隔的，不是等号也不是冒号。运行：
sdkmanager --list --sdk_root=C:\Android\sdk输出会分成两块，上面是Installed packages，下面是Available Packages。截取一段典型输出：
Installed packages: build-tools;34.0.0 platforms;android-34 Available Packages: build-tools;34.0.0 build-tools;35.0.0 platforms;android-34 platforms;android-35 system-images;android-34;google_apis;x86_64这里有个细节：安装时写的是完整包 ID，不是缩写。有人习惯写android-34，sdkmanager 会直接报unknown package。原因是android-34只是显示名的一部分，完整 ID 必须是platforms;android-34。版本号也要精确到小版本，比如build-tools;34.0.0，只写build-tools或build-tools;34都会让你多踩一个坑。
3.2 一条命令装齐四类组件
最小可用环境至少需要四类东西：platform-tools（提供 adb 和 fastboot）、platforms;android-34（提供 android.jar，编译期依赖）、build-tools;34.0.0（提供 aapt2、zipalign 等打包工具）、emulator（模拟器本体）。一条命令可以同时装多个包：
sdkmanager "platform-tools" "platforms;android-34" "build-tools;34.0.0" "emulator" --sdk_root=C:\Android\sdk参数说明：platform-tools没有版本号后缀，始终跟随最新版；platforms;android-34的34对应 API 级别，需要和项目的compileSdk一致；build-tools的完整版本号必须存在，先用--list确认，别凭记忆写。安装过程会显示下载进度，完成后检查：
dir C:\Android\sdk\platform-tools\adb.exe看到adb.exe就说明platform-tools真的落地了。再次强调：commandlinetools这个 zip 本身不含 adb，如果你没装platform-tools，后面所有adb命令都会报“不是内部或外部命令”。这是新手最容易产生的误解。
3.3 接受许可证：一条管道命令解决构建失败
Gradle 构建时会检查 SDK 包对应的许可证记录，没接受的话会直接报You have not accepted the license agreements of the following SDK components。这不是网络问题，是许可证文件没生成。解决方式是对当前 SDK 根目录执行许可证接受命令。在 Windows 上没有yes命令，我习惯在 PowerShell 里运行：
1..50 | ForEach-Object { 'y' } | & "$env:ANDROID_HOME\cmdline-tools\latest\bin\sdkmanager.bat" --licenses --sdk_root="$env:ANDROID_HOME"这条命令的意思是：生成 50 个y字符，通过管道依次喂给 sdkmanager 的许可证询问流程，把所有协议都接受掉。执行后检查C:\Android\sdk\licenses目录，里面会出现android-sdk-license文件，有它就行。如果你用的是内网代理或镜像源下载，sdkmanager 不读HTTP_PROXY环境变量，它是 Java 程序，认的是 JVM 系统属性。常见做法是设置JAVA_TOOL_OPTIONS带代理参数，但要注意设置后只对当前终端有效，直接放到 CI 配置里才能稳定生效。
4. avdmanager + emulator：从系统镜像到可启动的 AVD
4.1 系统镜像怎么选：google_apis 与 x86_64 的理由
模拟环境还需要系统镜像。system-images的三个常见变体是default、google_apis、google_apis_playstore。选型理由很简单：default最干净但很多 Google 服务接口调不了；google_apis_playstore带 Play 商店，适合测试上架前的兼容性，但它无法 root，自动化脚本里权限受限；google_apis是开发和 CI 最稳的中间选项，既有 Google API 又能 root，做 UI 自动化不容易被卡权限。架构上 Windows 机器选x86_64才能吃硬件加速，arm64-v8a镜像在 x86 主机上跑起来慢得没法用。安装命令：
sdkmanager "system-images;android-34;google_apis;x86_64" --sdk_root=C:\Android\sdk镜像体积不小，下载完可以先看C:\Android\sdk\system-images\android-34\google_apis\x86_64目录是否存在。sdkmanager 的好处是它会自动处理镜像依赖，不需要你手动解压任何东西。
4.2 创建 AVD 并调整 config.ini
创建虚拟设备前，先看看有哪些设备定义可用：
avdmanager list device输出里能看到pixel_6、pixel_7这类 ID。创建 AVD 时用--device指定 ID，用--package指定刚才装的镜像，--force覆盖同名设备：
echo no | avdmanager create avd --name ci_avd --package "system-images;android-34;google_apis;x86_64" --device pixel_6 --forceecho no的作用是自动回答“是否创建自定义硬件配置文件”，选择不创建，直接用设备模板。AVD 生成后默认存在%USERPROFILE%\.android\avd\ci_avd.avd目录下，核心配置在config.ini。为了在无 GPU 的 CI 机器上稳定跑，我会改三个参数：
hw.ramSize=2048 disk.dataPartition.size=6G hw.gpu.mode=offhw.ramSize是虚拟机内存，CI 机上给 2GB 够用；disk.dataPartition.size设大一点，避免安装测试 APK 时数据分区爆掉；hw.gpu.mode=off关掉 GPU 加速，配合无头模式用。如果你是在本地开发机跑，想要窗口画面，把hw.gpu.mode改回auto或host即可。
4.3 无头模式启动与开机等待
启动模拟器用emulator命令，它在C:\Android\sdk\emulator\emulator.exe。无头模式的标准启动命令：
emulator -avd ci_avd -no-window -no-audio -no-boot-anim -gpu swiftshader_indirect -no-snapshot -memory 2048 -cores 2参数含义：-no-window不弹窗口；-no-audio关音频，避免声卡驱动报错；-gpu swiftshader_indirect用软件渲染，防止没显卡的机器直接崩溃；-no-snapshot很重要，它避免加载上次的残留快照，保证每次冷启动都是干净状态。启动后不能立刻跑测试，系统还在 boot。adb wait-for-device只等设备在线，不等系统启动完成，真正的开机完成标志是：
until adb shell getprop sys.boot_completed 2>/dev/null | tr -d '\r' | grep -q 1; do sleep 5; done这段循环的逻辑很直白：不断读sys.boot_completed属性，读到1才继续。tr -d '\r'是为了去掉 Windows 下 adb 输出里的回车符，不然grep匹配不上。这里是血泪经验，很多 CI 脚本卡死就是因为少了这个回车符处理。启动完成后，adb shell input keyevent 82可以唤醒屏幕，后续 UI 自动化脚本就能直接操作了。
5. 高频翻车点排查：许可证、硬件加速、两套 SDK 打架
5.1 sdkmanager.bat 一闪而过或提示 SDK manager was not found
现象：双击sdkmanager.bat窗口闪一下就消失，或者在终端里运行提示SDK manager was not found、Could not determine SDK root。
原因：目录结构不符合cmdline-tools/latest/bin约定，或者JAVA_HOME没设置、指向了 JRE。sdkmanager 靠自身路径探测 SDK 根，路径不对就无从谈起。
解决：先检查sdkmanager.bat的实际位置，确保它是$ANDROID_HOME\cmdline-tools\latest\bin\sdkmanager.bat。再运行java -version，确认版本号是 17 而不是 1.8。如果目录暂时不想动，可以给所有命令加--sdk_root=C:\Android\sdk硬指根目录。注意：JAVA_HOME必须指向 JDK，不是 JRE，命令行工具用到javac相关能力时 JRE 不够。
5.2 Gradle 报 licenses has not been accepted
现象：项目构建时出现You have not accepted the license agreements of the following SDK components，同样是编译platforms;android-34，换了台机器就报。
原因：许可证不是全局注册的，它记录在 SDK 根目录的licenses文件夹里。你在这台机器接受过，换一个新 SDK 目录就要重新接受。很多人以为 Studio 里接受过就一劳永逸，但命令行工具对的是另外一套 SDK 路径。
解决：对当前实际使用的 SDK 根目录执行第 3.3 节的许可证命令，然后确认ANDROID_HOME、ANDROID_SDK_ROOT、项目里的local.properties三个地方指向同一个目录。如果项目指定了 Studio 的 SDK 目录，而命令行工具装在另一处，两边各自都要执行一次许可证接受。最省事的办法是复用一个统一目录，别搞两套房。
5.3 模拟器提示 x86_64 emulation currently requires hardware acceleration
现象：启动模拟器直接退出，提示x86_64 emulation currently requires hardware acceleration!，BIOS 里明明开了虚拟化还是不行。
原因：Windows 的虚拟机监控程序平台没启用，或者 Hyper-V 被其他软件抢占。Android 模拟器在 Windows 上依赖 WHPX 或 Hyper-V，不是光有 VT-x 就行。
解决：打开“控制面板 → 启用或关闭 Windows 功能”，勾选“Windows 虚拟机监控程序平台”和“Hyper-V”，重启。然后用emulator -accel-check验证加速状态。如果你同时跑 Docker Desktop，它也会占 Hyper-V，这时候模拟器可能拿不到资源。运行模拟器前先把不相关的容器服务停掉，这个排查顺序能省半小时。
5.4 adb 找不到，或分不清两个 SDK 根目录
现象：安装完 sdkmanager 后敲adb提示不是内部或外部命令；或者命令行工具装的包项目里全看不见。
原因：adb不在commandlinetools里，它属于platform-tools包，没装就是没有。另一种情况是命令行装的 SDK 是一套路径，项目里 Gradle 用的是另一套，两边各管各的。
解决：先执行sdkmanager "platform-tools"，再把platform-tools加进 PATH。如果是路径打架，打开终端执行echo %ANDROID_HOME%和echo %ANDROID_SDK_ROOT%，看是不是同一个值。再去项目根目录看local.properties里的sdk.dir，三方对齐。之前有人遇到“Studio 能跑、命令行不能跑”，就是 Studio 内置 SDK 和命令行 SDK 是两套，最后统一成一套就安静了。
6. 进阶习惯：把 SDK 清单化，让新机器一键复现
走到这一步，你已经能手动搭出全套环境。我最后的建议是：把 SDK 依赖写进一个文本文件，让以后每台新机器都能一键还原。我习惯建一个sdk-requirements.txt，每行一个包 ID，#开头是注释：
# SDK 依赖清单，保持版本精确 platform-tools platforms;android-34 build-tools;34.0.0 emulator system-images;android-34;google_apis;x86_64配合一段批处理脚本安装：
for /f "eol=# delims=" %%i in (sdk-requirements.txt) do ( if not "%%i"=="" sdkmanager.bat "%%i" --sdk_root=%ANDROID_HOME% )脚本的逻辑是逐行读取清单，跳过#开头的注释和空行，把每个包 ID 交给 sdkmanager 安装。版本号永远写具体值，不要写latest，否则两个月后新机器装出来的 SDK 和旧机器对不上，构建结果会变得很玄学。装完自动跑一次sdkmanager --list_installed，把输出留档，这就是这台机器的 SDK 指纹。升级某个组件前先把当前版本记下来，出问题还能用sdkmanager --uninstall退回去。CI 里跑模拟器时，-no-snapshot和adb emu kill是我每次都会带的，前者保证冷启动干净，后者保证任务结束不留僵尸进程。我自己当年就是没搞清 adb 不随 commandlinetools 附带，白白折腾了一下午，现在每个环节都按清单走，反而再没出过岔子。希望帮到你。
本文还有配套的精品资源，点击获取
