企业官网建设流程全解析

简介：本资源是 Android 官方命令行工具包（Windows 版），面向无 IDE 依赖的 Android 开发者、CI/CD 工程师及轻量级 SDK 管理需求用户，用于在不安装 Android Studio 的前提下完成 SDK 组件下载、AVD 创建、APK 分析与构建工具链初始化等核心操作。压缩包共 100 个文件，含 90 个 JAR（支撑 sdkmanager、avdmanager、apkanalyzer 等工具运行）、7 个 BAT 批处理脚本（提供开箱即用的 Windows 命令入口）、1 个 README 和配置类文件，整体大小为 115.29MB，结构精简、无冗余图形界面组件。目前已有 236 人学习下载，适合需快速搭建纯命令行 Android 构建环境、定制化 SDK 管理流程或嵌入自动化脚本的中高级开发者。 很多人在Windows上下载了commandlinetools-win-9123335-latest.zip之后，第一反应是“这玩意到底干啥用的”。它既不是一个完整的IDE，也不是一个能直接跑应用的模拟器，但如果你是做Android开发、自动化构建、CI/CD流水线，或者单纯想在命令行环境下管理SDK，这个包就是绕不开的入口。这篇想讲的，就是这个zip从解压到真正能干活的全过程，包括那些文档里不会明说、但实际使用时一定会踩的坑。

先说清楚，commandlinetools-win-9123335-latest.zip是Android SDK的命令行工具包，专门给Windows环境用的。它里面包含的核心工具是sdkmanager和avdmanager，前者用来下载和管理SDK组件（比如platform-tools、build-tools、具体的Android平台版本），后者用来创建和管理模拟器（AVD）。Android Studio虽然自带一套图形化的SDK Manager，但在服务器、Docker容器、虚拟机或者任何没有图形界面的场景下，这套命令行工具就是唯一的选择。即使你平时用Android Studio，我也建议把命令行工具单独装一份，很多批量操作、版本切换、脚本自动化，用命令行比点鼠标高效得多。

这个zip的版本号9123335对应的是cmdline-tools 12.0，属于2024年之后发布的较新版本。和旧版相比，它对JDK版本有硬性要求（必须JDK 17），对目录结构的摆放也更严格。下面我把整个过程拆开讲。

1. 解压之后别急着用，先搞懂cmdline-tools的目录摆放逻辑

拿到zip之后，如果不加思考直接双击解压，大概率会看到一个名叫cmdline-tools的文件夹，里面是bin、lib等子目录。很多人以为这样就算装好了，然后运行sdkmanager，结果直接报错，提示找不到SDK根目录。原因很简单：cmdline-tools的目录结构有一套自己的约定，你必须在某个位置放一个名为latest的父目录，把解压出来的cmdline-tools内容整体放进去。

也就是说，正确的手动安装路径是这样的：

你的SDK根目录/ └── cmdline-tools/ └── latest/ ├── bin/ ├── lib/ ├── NOTICE.txt ├── package.xml └── source.properties

举个例子，如果你想在D:\Android\Sdk下安装，那么最终sdkmanager.bat的完整路径应该是D:\Android\Sdk\cmdline-tools\latest\bin\sdkmanager.bat。这个latest目录名不能随便改，原因是sdkmanager在运行时会在自身路径中向上查找cmdline-tools/latest这个固定结构，用它来解析SDK根目录。如果你把目录命名成cmdline-tools\v12.0或者直接cmdline-tools，那么sdkmanager内部计算出来的SDK根目录就会出错，表现就是各种“SDK location not found”或者“Unable to locate a Java Runtime”。

这是安装过程中最容易出问题的第一步。我见过很多人卡在这里，明明java环境没问题，zip也解压了，但一跑sdkmanager --list就报错，折腾半天发现是目录结构不对。

另外有一个细节：这个zip解压后的根目录默认就叫cmdline-tools，如果你直接按照上面的结构去建目录，操作上应该是：

1. 在SDK根目录下创建cmdline-tools文件夹。
2. 在cmdline-tools下创建latest文件夹。
3. 把zip解压出来的内容（注意是里面的bin、lib等文件，不是cmdline-tools这层壳）全部移动到latest中。

如果你嫌手动建目录麻烦，也可以先随便解压到一个临时位置，然后用命令行里的robocopy或者xcopy把内容整体搬过去。这一步做对了，后面就顺了。

2. 安装前的Java环境：JDK 17是硬门槛，不是建议

新版cmdline-tools对Java的要求是JDK 17。这不是“推荐”版本，而是“强制”版本。如果你用的是JDK 8或者JDK 11，运行sdkmanager时通常会收到这样的错误：

Error: Could not find or load main class com.android.sdklib.tool.sdkmanager.SdkManagerCli

或者更直接的：

Unsupported major.minor version 61.0

这个61.0指的就是Java 17编译出来的class文件版本号。JDK 8对应52.0，JDK 11对应55.0，JDK 17对应61.0。如果你看到Unsupported major.minor version，不用怀疑，就是JDK版本不够新。

在Windows上安装JDK 17并不复杂，下载安装包、配置环境变量就行。但有几个细节值得注意。首先，同一台机器上可能装了多个JDK，JAVA_HOME环境变量指向的版本可能不是17。sdkmanager脚本会优先读取JAVA_HOME，如果你在命令行里敲java -version显示的版本和JAVA_HOME不一致，说明Path里的顺序有问题，或者JAVA_HOME被其他安装程序覆盖了。

其次，如果你用的是Android Studio自带的JBR（JetBrains Runtime），这个运行时是基于JDK 17的，它通常位于Android Studio的安装目录下的jbr文件夹中。你完全可以把JAVA_HOME指向这个jbr，这样就不用单独装JDK了。但如果你在服务器上只想装命令行工具，不装Android Studio，那么独立JDK 17就是必需品。

建议在打开命令行工具之前，先固定一个干净的环境。比如在运行sdkmanager之前，在同一个命令行窗口里执行：

set JAVA_HOME=C:\Program Files\Java\jdk-17 set PATH=%JAVA_HOME%\bin;%PATH%

这样可以临时覆盖系统级的JAVA_HOME，避免因为全局配置混乱导致排查困难。等确认一切正常之后，再把JAVA_HOME固化到系统环境变量里。

3. sdkmanager的日常操作：从查看列表到安装组件

当目录结构摆对、JDK 17就位之后，sdkmanager就可以正常跑了。我一般先在命令行里运行：

sdkmanager --list

这个命令会输出两部分内容：Installed packages和Available Packages。前者是你已经装好的SDK组件，后者是可以安装的全部组件，列表很长，包含platform-tools、build-tools、platforms、system-images、emulator等。强烈建议第一次运行--list时把输出重定向到文件里，方便搜索：

sdkmanager --list > sdk_list.txt

然后你就可以用文本编辑器的搜索功能找想要的组件，避免在命令行里翻半天。如果是在PowerShell里，输出重定向的方式一样，但编码可能不同，中文Windows环境下推荐用Out-File -Encoding utf8来避免乱码。

安装组件的命令格式是：

sdkmanager "platform-tools" "platforms;android-35" "build-tools;35.0.0"

注意引号不能少，因为组件名包含分号和点，不加引号会导致命令解析错误。可以一次性传入多个组件，sdkmanager会按顺序安装。

实际使用中最常装的就是这几种：

如果只是做一般的命令行构建，platform-tools+platforms;android-35+build-tools;35.0.0基本就够了。如果是做自动化测试，还需要系统镜像和模拟器。

有个很容易忽略的点：安装组件时，sdkmanager会对每个组件的许可协议进行确认，它不会一口气全装上，而是每下载一个组件前弹一次确认，如果人不在电脑前，安装就会卡住。解决办法是先执行：

sdkmanager --licenses

这个命令会遍历所有组件的许可协议并逐条提示，输入y接受即可。但更省事的做法是直接接受全部许可：

yes | sdkmanager --licenses

如果你在Windows的cmd或者PowerShell里没有yes命令，可以用一个循环代替。在PowerShell里：

1..100 | ForEach-Object { "y" } | sdkmanager --licenses

或者在cmd里用：

(for /L %i in (1,1,100) do @echo y) | sdkmanager --licenses

这里有个经验之谈：license的接受状态是全局的，以licenses目录下的文件形式存储在SDK根目录里。一旦接受过，后续安装新组件时如果涉及相同协议，就不会再询问了。但是如果你在CI流水线的临时环境中每次都从零部署SDK，那yes | sdkmanager --licenses这行几乎是标配。

4. 环境变量配置：让adb和sdkmanager全局可用

组件装完后，下一步就是配置环境变量。至少有两个变量是必设的：ANDROID_HOME和ANDROID_SDK_ROOT。

ANDROID_HOME指向你的SDK根目录，比如D:\Android\Sdk。ANDROID_SDK_ROOT和它指向同一个地方，虽然这个变量在新版工具链中逐渐被淡化，但很多老旧的构建脚本仍然会读取它，所以两个都设上不会有坏处。

然后是PATH。需要把以下目录加进PATH：

• %ANDROID_HOME%\cmdline-tools\latest\bin：让sdkmanager、avdmanager全局可用。
• %ANDROID_HOME%\platform-tools：让adb、fastboot全局可用。
• %ANDROID_HOME%\emulator：让emulator命令全局可用，方便启动模拟器。

具体操作是在系统环境变量里编辑Path，新增这三行。有个小心得：在Windows上不要把%ANDROID_HOME%变量直接嵌入到Path里的路径结尾加多余的反斜杠或者空格，否则adb虽然能启动，但在某些工具链解析路径时会出毛病。写%ANDROID_HOME%\platform-tools就够了，不要写成%ANDROID_HOME%\platform-tools\。

配置完之后，新开一个命令行窗口，执行：

adb version sdkmanager --version

如果两个命令都能正常输出版本号，说明环境变量生效了。这里有一个很常见的坑：如果你在配置环境变量之前就已经打开了一个终端窗口，那么这个窗口里的环境变量不会自动刷新，需要关闭后重新打开。如果不想重启终端，可以用refreshenv命令（需要安装Chocolatey才有），或者直接在新窗口里测试。

另外，如果你电脑上同时装有Android Studio，它可能会在%LOCALAPPDATA%\Android\Sdk下建立自己的SDK目录。这个目录和你的ANDROID_HOME指向的目录可能不是同一个。建议统一，否则会出现命令行里编译的APK和Android Studio里构建的APK签名配置不一致的问题，排查起来非常痛苦。

5. 实操中容易踩的三个坑：licenses、代理和SDK组件版本匹配

5.1 licenses目录与持续集成环境的坑

sdkmanager在首次安装组件时，会在SDK根目录下生成一个licenses目录，里面存放每个许可协议的哈希文件。如果你在临时目录里安装SDK、跑完构建后直接删掉，下次又要重新接受一遍许可。更麻烦的是，如果CI脚本里yes | sdkmanager --licenses和sdkmanager的安装命令执行顺序不对，或者sdkmanager --licenses失败但没设置set -e，那么后续安装也会失败。建议在CI脚本里用yes |管道，并且一定要确保ANDROID_HOME目录有写权限。在Windows的容器环境里，如果目录权限不足，licenses写入失败，即使你输入一百个y也没用。

5.2 网络代理：下载慢或者卡住的真实原因

sdkmanager默认从Google的官方仓库下载组件。在部分网络环境下直接下载会超时或者断流，表现是Downloading...进度条长时间不动，或者直接报java.net.SocketTimeoutException。这个问题在CI环境、服务器环境尤其常见。

一个务实的做法是配置镜像源。sdkmanager支持通过REPO_OS_OVERRIDE和sdkmanager --channel之类的参数调整一些行为，但镜像配置并不是一个简单的命令行开关，而是通过修改SDK根目录下的repositories.cfg文件，或者通过环境变量ANDROID_SDK_SOURCE来指定仓库地址。不过坦白说，官方对“自定义仓库”的支持并不友好，大多数团队的实际做法是预先在一个可联网的机器上把SDK组件下载好，做成压缩包传到内网服务器，然后在CI脚本里解压使用。这样虽然少了实时下载的灵活性，但CI构建速度更快也更稳定。我个人的经验是，如果内网环境无法访问官方仓库，与其纠结镜像配置，不如直接把基础SDK目录做成一个可复用的基础镜像，这是投入产出比最高的方式。

5.3 SDK组件版本匹配问题

sdkmanager装哪个build-tools版本，跟你项目里compileSdkVersion和buildToolsVersion的配置是紧密相关的。项目里配置compileSdkVersion 35，那就至少需要platforms;android-35；配置buildToolsVersion "35.0.0"，那就需要build-tools;35.0.0。

这里有个细节：新版AGP（Android Gradle Plugin）在构建时，如果发现build-tools版本缺失，不会自动帮你安装，而是直接报一个错误提示。所以手动管理SDK时，确保依赖项齐全是一个很重要的前置步骤。

怎么确认项目需要哪些SDK组件？最简单的办法是在项目根目录执行：

gradlew :app:dependencies

或者直接看app/build.gradle里的配置。如果你用的AGP版本比较新，它还会要求某个最低build-tools版本。这个版本信息在AGP内部的SDK组件要求表里写死了，你可以在项目构建失败时的报错信息里看到具体需求。

6. avdmanager：命令行创建和管理模拟器

cmdline-tools里另一个常用工具是avdmanager，全称是Android Virtual Device Manager。它负责创建、删除、列出AVD。在无图形界面的服务器上创建模拟器，靠的就是这个命令。

创建AVD之前，必须保证已安装对应的系统镜像。比如你想创建一个Android 35、x86_64架构、带Google APIs的模拟器，那么需要先安装：

sdkmanager "system-images;android-35;google_apis;x86_64"

然后创建AVD：

avdmanager create avd -n test_avd -k "system-images;android-35;google_apis;x86_64" -d pixel_5

-d参数指定设备配置文件，可以用avdmanager list device查看所有可用的设备ID。如果你不指定-d，avdmanager会创建一个默认配置的AVD。-n是AVD的名字，后续启动模拟器时要用。

创建完之后，可以用avdmanager list avd确认是否创建成功。然后启动模拟器：

emulator -avd test_avd -no-window -no-audio -gpu swiftshader_indirect

在服务器上没有显示器的情况下，-no-window是必需的。-gpu swiftshader_indirect表示用软件渲染GPU，虽然性能一般，但没有物理GPU时这是最稳妥的方案。

这里有一个实际使用中容易忽略的地方：AVD的存储位置在Windows上是%USERPROFILE%\.android\avd，如果你在CI里以不同账户运行构建，AVD列表会出现相互不可见的情况。如果发现avdmanager list avd看不到之前创建的AVD，可以先检查一下当前用户的.android目录下是否有对应的ini和avd文件夹。

7. 一个完整的Windows命令行部署清单

把整篇文章的内容串起来，一个从零到可用的Windows环境部署流程，我一般写成这样的清单：

1. 安装JDK 17，配置JAVA_HOME和PATH。
2. 创建SDK目录，比如D:\Android\Sdk。
3. 下载commandlinetools-win-9123335-latest.zip，解压并按cmdline-tools/latest目录结构摆放。
4. 设置ANDROID_HOME和ANDROID_SDK_ROOT为SDK目录。
5. 把cmdline-tools/latest/bin、platform-tools、emulator加入PATH。
6. 新开命令行窗口，运行sdkmanager --licenses接受所有许可。
7. 运行sdkmanager "platform-tools" "platforms;android-35" "build-tools;35.0.0"安装基础组件。
8. 运行adb version和sdkmanager --version验证环境。
9. 如果有模拟器需求，再安装系统镜像并创建AVD。

这套流程我前前后后在不同机器上重复过几十遍，每一步都可能出一些小岔子，但归根结底就三类：目录结构不对、JDK版本不对、环境变量没生效。把这三点盯住，基本上就顺了。

最后分享一个小技巧：sdkmanager安装组件时，如果某个版本装错了，想卸载，直接删SDK目录下对应的文件夹就行，没有单独的卸载命令。比如D:\Android\Sdk\platforms\android-35就是Android 35平台库，删掉这个目录就等于卸载了这个组件。但注意别手滑删错，SDK目录里build-tools和platforms下往往有很多版本共存，删掉之后如果项目还依赖它，下次构建就会从零重新下载。

对于commandlinetools-win-9123335-latest.zip这个包本身，我目前使用下来的体验是，只要目录结构摆对，JDK 17就位，它就是一个稳定可靠的基础工具。相比Android Studio那套庞大的图形界面，命令行工具更轻量、更可控，尤其适合脚本化和自动化场景。希望这篇东西能帮你少走点弯路。

本文还有配套的精品资源，点击获取