简介：这份资源是面向 Windows 平台的 Android 命令行工具包（commandlinetools-win-8512546_latest.zip），适合不想安装完整 Android Studio、却需要搭建或维护 Android SDK 环境的开发者、测试人员与自动化构建工程师。它解决的是在无图形界面或轻量环境下获取 SDK 组件、管理虚拟设备与调试工具的问题，属于进阶开发与持续集成场景的实用工具集。压缩包共 100 个文件，以 90 个 jar 为核心运行库，配合 7 个 bat 批处理脚本、1 个 readme、1 个 properties 与 1 个 txt 说明文件，整体约 108.86MB，解压后可通过 sdkmanager、avdmanager、apkanalyzer、lint、retrace 等命令完成 SDK 包下载、应用分析、代码检查与混淆还原等操作。目前已有 1088 人学习下载，说明其在 Android 工具链配置中具备一定参考价值。读者可借此获得一套可独立部署的命令行 SDK 环境，掌握脱离 IDE 的包管理与构建排错思路，并借助内置脚本快速完成环境初始化与日常维护。
1. 从一台没装 Android Studio 的机器说起：commandlinetools 到底解决什么问题
很多人第一次接触 Android 开发，默认路径是下载几个 G 的 Android Studio 安装包，一路下一步。但真实工作场景里，经常遇到的是另一类机器：一台 2 核 4G 的云构建节点、一台只跑 CI 的 Linux 容器、一台不想装 IDE 的办公本，甚至是一台只想用 vscode android cmdline-tools 写点小工具的机器。这些场景下，装完整 IDE 既浪费磁盘也拖慢流水线，而commandlinetools-win-8512546_latest.zip就是为这种需求准备的——它是 Android SDK 的命令行工具包，只包含sdkmanager、avdmanager、adb、fastboot等核心组件，不捆绑 IDE 和模拟器镜像。
这个包解决的核心问题是：让你在没有图形界面的环境下，依然能完整地安装、更新、管理 Android SDK 的各个平台版本、构建工具和平台工具。它适合三类人：一是做 CI/CD 流水线、需要脚本化安装 SDK 的工程师；二是磁盘紧张、只想按需拉取组件的开发者；三是想搞清楚 Android Studio 背后到底调了什么命令的进阶学习者。8512546 这个版本号对应的是 cmdline-tools 的一个具体构建，解压后目录结构是cmdline-tools/bin加cmdline-tools/lib，和早期tools包的布局完全不同，这一点后面会专门讲坑。
2. 解压、目录布局与 sdkmanager 初始化：把黑匣子拆开看
2.1 为什么不能直接双击 sdkmanager.bat
下载完commandlinetools-win-8512546_latest.zip，很多人的第一反应是解压后直接进bin目录双击sdkmanager.bat，然后窗口一闪而过。原因是这个版本的 cmdline-tools 强制要求一个特定的目录层级：它必须位于<SDK_ROOT>/cmdline-tools/<version>/下面，其中<version>可以是latest，也可以是具体版本号。如果你把解压出来的cmdline-tools文件夹直接放在D:\android-sdk\下，那么sdkmanager会找不到自己的lib目录，报Could not determine SDK root或者直接闪退。
常见做法是手动建两级目录。假设你打算把 SDK 装在D:\android-sdk，正确布局是：
D:\android-sdk\ cmdline-tools\ latest\ bin\ sdkmanager.bat avdmanager.bat lib\ NOTICE.txt source.properties也就是说，解压出来的cmdline-tools文件夹要先重命名或移动到latest这一层。这一步是血泪经验，我第一次在 CI 上跑的时候就是因为少了这层latest，脚本卡了半小时才定位到。
2.2 配置 ANDROID_HOME 与 PATH 的具体命令
目录摆好之后，需要让系统知道 SDK 根在哪。Windows 下用setx写环境变量，注意setx写入的是用户级变量，当前会话不会立即生效，要新开一个终端：
:: 设置 SDK 根目录，注意路径不要带尾部反斜杠 setx ANDROID_HOME "D:\android-sdk" setx ANDROID_SDK_ROOT "D:\android-sdk" :: 把 cmdline-tools 的 bin 和 platform-tools 加进 PATH setx PATH "%PATH%;%ANDROID_HOME%\cmdline-tools\latest\bin;%ANDROID_HOME%\platform-tools"这里有两个参数要说明。ANDROID_HOME和ANDROID_SDK_ROOT目前建议都设，因为不同版本的 Gradle 插件读取的变量名不一致，老项目认前者，新工具链认后者。PATH里加platform-tools是为了后面adb能直接调用，但platform-tools目录此刻还不存在，要等sdkmanager装完才有，所以第一次配置时 PATH 里报个警告是正常的。
验证是否配好，新开终端执行：
sdkmanager --version如果输出版本号而不是报错，说明目录层级和环境变量都对了。如果报Warning: Could not create settings，那是它想写~/.android目录但权限不够，属于可忽略的警告，不影响后续安装。
2.3 sdkmanager 的包名规则与 --list 输出解读
sdkmanager装包靠的是包名，包名格式是组件类型;版本;修订号，分号在 Windows 命令行里要小心，通常用引号包起来。先看有哪些可用包：
sdkmanager --list输出分三块：Installed packages、Available Packages、Available Updates。新手容易懵的是platforms;android-34和build-tools;34.0.0的区别。platforms是编译时用的 android.jar，决定你能调用哪些 API；build-tools是 aapt2、d8、zipalign 这些打包工具的集合，决定打包行为。两者版本号不要求一致，但 Gradle 插件对 build-tools 有最低版本要求。
一个最小可用的安装组合是：
sdkmanager "platform-tools" "platforms;android-34" "build-tools;34.0.0"platform-tools提供 adb 和 fastboot，platforms;android-34提供 API 34 的编译目标，build-tools;34.0.0提供打包工具。装完后D:\android-sdk下会多出platform-tools、platforms、build-tools三个目录，这时 PATH 里的platform-tools才真正生效。
提示：
sdkmanager首次运行会要求接受 license，交互式输入y即可。CI 环境下用yes | sdkmanager --licenses批量接受，但要注意yes在 Windows cmd 里不可用，得用echo y循环或者改用 PowerShell。
3. 用 sdkmanager 装 SDK、建 AVD 与接入 Gradle 构建
3.1 批量安装与 license 自动接受的脚本写法
在 CI 里手动敲y不现实，常见做法是把 license 接受和包安装写成一个脚本。Windows 下可以用 PowerShell 的管道，或者用for循环喂y：
:: 先接受所有 license，用循环喂 y for /l %i in (1,1,20) do @echo y | sdkmanager --licenses >nul 2>&1 :: 再安装指定组件，--sdk_root 显式指定根目录避免歧义 sdkmanager --sdk_root=%ANDROID_HOME% "platform-tools" "platforms;android-34" "build-tools;34.0.0"--sdk_root这个参数值得单独说。当你的 cmdline-tools 不在默认位置时，sdkmanager会尝试从自身路径反推 SDK 根，推错了就会把包装到奇怪的地方。显式传--sdk_root是最稳的做法，尤其在多 SDK 共存的机器上。>nul 2>&1是把 license 接受过程的输出丢掉，避免日志被几十行 license 文本淹没，但调试阶段建议先去掉，看清楚它到底接受了哪些。
3.2 avdmanager 创建模拟器的完整参数
commandlinetools里还带了avdmanager，可以在没有 Android Studio 的情况下建 AVD。先看有哪些系统镜像可用：
sdkmanager --list | findstr "system-images"假设要建一个 API 34 的 Google APIs 镜像模拟器，先装镜像再建 AVD：
:: 装系统镜像，x86_64 在 Intel/AMD 机器上性能最好 sdkmanager "system-images;android-34;google_apis;x86_64" :: 创建 AVD，-n 是名字，-k 是镜像包名，-d 是设备型号 avdmanager create avd -n test_api34 -k "system-images;android-34;google_apis;x86_64" -d pixel_6-d pixel_6指定设备轮廓，决定屏幕分辨率和 dpi，不指定会用一个默认的通用轮廓。建完后 AVD 文件在%USERPROFILE%\.android\avd\下。启动模拟器需要emulator组件，它不在 cmdline-tools 里，要单独装：
sdkmanager "emulator" emulator -avd test_api34这里有个容易翻车的点：emulator装完后不在platform-tools里，而在D:\android-sdk\emulator\下，PATH 里没加这个目录的话，命令行直接敲emulator会提示找不到命令。
3.3 让 Gradle 认出命令行装的 SDK
命令行装完 SDK，如果本地还有 Android Studio 项目要构建，需要让 Gradle 知道 SDK 位置。最直接的方式是在项目根目录建local.properties：
# local.properties，不要提交到版本库 sdk.dir=D\:\\android-sdk注意 Windows 路径里的反斜杠要转义成\\，冒号也要转义，这是 Java Properties 格式的要求，写错了 Gradle 会报SDK location not found。另一种方式是不写local.properties，靠ANDROID_HOME环境变量，Gradle 会自己读。两种方式优先级是local.properties高于环境变量，团队协作时通常把local.properties加进.gitignore，让每个人用自己的环境变量。
验证 Gradle 能否找到 SDK，在项目目录执行：
gradlew tasks --all | findstr "assembleDebug"能列出任务说明 SDK 配置通了。如果报Failed to find target with hash string 'android-34'，说明platforms;android-34没装或者装到了别的 SDK 根下，回去检查--sdk_root和ANDROID_HOME是否指向同一个目录。
4. 避坑与排查：cmdline-tools 最容易翻车的五个地方
4.1 现象：sdkmanager 报 "Could not determine SDK root"
原因几乎总是目录层级不对。8512546 这个版本要求cmdline-tools下面必须有一层版本目录（latest或具体版本号），bin和lib要在这层版本目录里。很多人解压后直接把cmdline-tools当根用，sdkmanager向上找不到platform-tools之类的兄弟目录，就判定不了 SDK 根。解决办法是按 2.1 的布局重新摆，或者用--sdk_root显式指定。
4.2 现象：装完 platform-tools 但 adb 命令找不到
原因是 PATH 没生效或者加错了目录。setx改的 PATH 只对新开的终端生效，当前窗口还是旧 PATH。另外要确认加的是%ANDROID_HOME%\platform-tools，不是%ANDROID_HOME%\cmdline-tools\latest\bin，adb 在 platform-tools 里。验证方法是在新终端里where adb，看输出的路径是不是你预期的那个。
4.3 现象：sdkmanager --list 卡住或超时
这通常是网络到下载源的连通性问题，不是工具本身的 bug。sdkmanager默认走 Google 的下载地址，国内网络环境下可能很慢或超时。常见做法是配置代理镜像，在%USERPROFILE%\.android\下建repositories.cfg或者在 Gradle 里配镜像源。但要注意，改下载源只影响包下载，不影响 license 校验逻辑。如果只是--list卡住，可以先加--verbose看它卡在哪一步。
4.4 现象：avdmanager create avd 报 "Package path is not valid"
这个报错说明-k后面的镜像包名和实际安装的包名对不上。常见原因是装了google_apis_playstore却写了google_apis，或者架构写成了x86而实际装的是x86_64。解决办法是先sdkmanager --list | findstr "system-images"把已安装的镜像包名原样复制出来，不要凭记忆写。包名里分号、下划线、连字符都不能错。
4.5 现象：Gradle 构建报 build-tools 版本不匹配
Gradle 插件对 build-tools 有最低版本要求，比如 AGP 8.x 要求 build-tools 33 以上。如果你只装了build-tools;30.0.3，构建时会报Installed Build Tools revision 30.0.3 is corrupted或者直接提示版本过低。解决办法是看项目build.gradle里buildToolsVersion或 AGP 版本对应的要求，用sdkmanager补装对应版本。注意 build-tools 可以多版本共存，不用卸载旧的。
注意：
sdkmanager的--uninstall会直接删目录，没有回收站。卸载前确认没有项目依赖那个版本，尤其是platforms和build-tools，删错了重新下载要等很久。
5. 进阶：用 sdkmanager 做可复现的 SDK 清单与版本锁定
5.1 把 SDK 状态导出成可提交的清单
团队协作和 CI 里最怕的是「我本地能构建，你那边不行」，根因往往是 SDK 组件版本不一致。sdkmanager没有直接的freeze命令，但可以用--list的输出过滤出已安装包，生成一份清单文件：
:: 导出已安装包列表，去掉表头和空行，只留包名 sdkmanager --list | findstr /r "^ [a-z]" > sdk-packages.txt这个sdk-packages.txt可以提交到版本库，新人拉下来后一条命令批量安装：
:: 逐行读取清单并安装，for /f 按行处理 for /f "tokens=*" %p in (sdk-packages.txt) do sdkmanager "%p"findstr /r "^ [a-z]"这个正则的意思是匹配行首两个空格后跟小写字母的行，正好是sdkmanager --list里已安装包的格式。不同版本的输出格式可能有细微差别，生成后建议人工扫一眼，把误匹配的行删掉。这个做法比手写安装脚本可靠，因为清单是从实际环境导出的，不会漏包也不会多包。
5.2 用 source.properties 锁定 cmdline-tools 自身版本
sdkmanager能管理别的组件，但它自己这个 cmdline-tools 包的版本怎么锁定？答案在cmdline-tools/latest/source.properties里，这个文件记录了Pkg.Revision，比如Pkg.Revision=8512546。CI 脚本里可以在初始化后校验这个值：
:: 读取 source.properties 里的版本号并比对 findstr "Pkg.Revision" "%ANDROID_HOME%\cmdline-tools\latest\source.properties"如果输出的不是预期的 8512546，说明有人手动更新过 cmdline-tools，可能导致构建行为变化。把这一步加进 CI 的前置检查，能避免「某天流水线突然挂了但没人改代码」这类玄学问题。source.properties里还有Pkg.Desc和Pkg.Revision两个关键字段，前者是描述，后者才是版本号。
5.3 一个我常用的验证习惯
每次在新机器上配完 cmdline-tools，我不会直接跑项目构建，而是先走一遍最小验证链：sdkmanager --version确认工具可用，sdkmanager --list确认能连上源，sdkmanager "platform-tools"装一个最小包确认写权限，adb version确认 PATH 生效，最后才gradlew assembleDebug。这条链任何一环断了，问题范围都能立刻缩小到具体组件，不用在完整构建的几百行日志里大海捞针。
从那以后我每次配新环境都强制走一遍这条最小验证链，宁可多花两分钟，也不愿在构建失败后花半小时排查到底是 SDK 没装对还是代码有问题。希望这套流程能帮到你，少踩几个我踩过的坑。
本文还有配套的精品资源，点击获取
