企业官网建设流程全解析

简介：本资源为 Android 官方命令行工具最新版（Windows 平台），面向无需完整 IDE 的 Android 开发者、CI/CD 工程师及自动化构建人员，解决轻量级 SDK 管理、离线环境部署与脚本化构建等核心需求。压缩包共 104 个文件，含 93 个 JAR 库（支撑 sdkmanager、avdmanager 等核心功能）、8 个 BAT 批处理脚本（提供开箱即用的命令入口，如 apkanalyzer.bat、lint.bat、retrace.bat 等）、以及 README 和配置文件，整体大小 146.47MB，结构精简、无冗余依赖。目前已有 561 人学习下载，适用于脱离 Android Studio 的纯 CLI 场景，可直接调用 sdkmanager 安装平台、构建工具与系统镜像，配合 resourceshrinker.bat、screenshot2.bat 等实用工具完成 APK 分析、资源优化与设备截图等典型任务，是构建稳定、可复现 Android 构建环境的关键基础组件。 搞 Android 开发的人，肯定都见过这个commandlinetools-win-11076708-latest.zip，一百多 MB 的东西，名字看着平平无奇，但 Android SDK 的安装、管理、调试、模拟器创建，全都靠它。我第一次认真折腾它是在配 CI 构建环境的时候，那会儿 Android Studio 太重塞不进服务器，就靠这个压缩包把整套 SDK 从零拉了起来，后面才发现 Android Studio 里的 SDK Manager 底层调用的其实也是这套命令行工具。这几年我也帮不少人排查过 "Android Studio 找不到 SDK""Flutter 环境起不来""sdkmanager 报错" 这类问题，根源大多出在对这个 zip 的理解和使用姿势上。这篇文章我就用实际经验把它的目录结构、配置方法、常用命令和填坑记录完整讲一遍，内容偏入门但会把关键细节抠到位，适合刚接触 Android 开发、要配环境变量、要搭 CI、或者想搞明白 Android Studio 背后机制的人。

1. commandlinetools 到底是什么：拆开 zip 看门道

1.1 和 Android Studio 的关系

很多新手以为 Android SDK 是跟着 Android Studio 一起装的，装完 Studio 就万事大吉。这个理解没错，但只对了一半。Android Studio 本质上是一个基于 IntelliJ IDEA 的 IDE，它自身不带完整的 Android 编译工具链，而是通过调用一套独立的 SDK 组件来完成编译、打包、安装、调试。这套组件就是 SDK Manager 管理的那些东西：platform-tools、platforms、build-tools 等。

而commandlinetools-win-xxxx-latest.zip，就是脱离 Android Studio 后，在命令行里管理这些 SDK 组件的入口。Google 从 Android Studio 3.2 开始把这块独立出来，提供单独的压缩包下载，让开发者不装 IDE 也能搭建完整的 Android 构建环境。这对 CI/CD 场景尤其重要，因为服务器上不需要图形界面，只需要一个能拉取 SDK 包、接受 license、触发 Gradle 构建的命令行工具链。

1.2 解压后目录里都有啥

这个 zip 解压出来，里面不是一坨散文件，而是一个结构清晰的cmdline-tools目录：

cmdline-tools\ └── latest\ ├── bin\ │ ├── sdkmanager.bat │ ├── avdmanager.bat │ ├── apkanalyzer.bat │ ├── lint.bat │ ├── retrace.bat │ ├── screenshot2.bat │ └── profgen.bat ├── lib\ └── source.properties

bin目录下最常用的是sdkmanager.bat和avdmanager.bat。前者负责 SDK 包的安装、卸载、列出、接受 license；后者负责创建和管理虚拟设备（AVD）。apkanalyzer在分析 APK 时很顺手，lint是静态代码扫描，retrace用来还原混淆后的堆栈。lib目录放的是这些工具运行所需的 Java 类库，正常情况下你不会去动它。

有个细节一定要记住：zip 解压后第一层是cmdline-tools，你必须保证最终执行文件的路径是...\cmdline-tools\latest\bin\sdkmanager.bat。这个latest目录名是硬性约定，sdkmanager 靠它来确定 SDK 根目录，改错名字或者把 bin 里的文件直接挪到别的位置，工具就会报Could not determine SDK root。

1.3 版本号怎么解读

11076708是 Google 内部的构建号，数字越大代表越新的构建。latest的意思是官方会持续更新这个链接对应的文件，你今天下载的和三个月后下载的，虽然文件名都带11076708，但内容可能已经变了。所以官网标注的是commandlinetools-win-11076708_latest.zip，实际下载后的文件可能内置版本号更高。

平台标识win对应 Windows，其他还有linux和macosx。在 Windows 上如果下载了 Linux 版本，解压后全是.sh脚本，自然跑不起来。这个看起来是低级错误，但我确实见过有人把命令复制错导致环境变量配了半天没反应。

2. 头一次配置：下载解压、JDK 和环境变量

2.1 怎么下载到正确的 zip

下载渠道很简单，直接去 Android 开发者官网的 "Command line tools only" 区域，这个页面会列出 Windows、macOS、Linux 三个版本的下载链接。页面上标注的下载文件名通常就是commandlinetools-win-11076708_latest.zip这样。

如果你的网络访问官网不稳定，可以换一个网络环境或者用国内云厂商维护的 Android SDK 镜像仓库。注意 verify 一下下载文件的大小，正常 Windows 版本应该在一百多 MB，如果只有几 MB，大概率下到了错误的文件或者下载被中断。解压时建议用系统自带的资源管理器右键解压，或者tar -xf，有些第三方解压工具在 Windows 上处理文件夹权限会出幺蛾子，导致后续运行脚本时提示无权限。

2.2 目录规划：别把 latest 放错地方

我强烈建议把 Android SDK 放到一个独立目录，不要放在C:\Program Files这类需要管理员权限的路径下。我的习惯是建一个D:\Android\Sdk，所有 SDK 组件都统一放在这里。具体步骤是：

1. 在D:\Android\Sdk下新建cmdline-tools文件夹。
2. 把下载的 zip 解压到临时目录，你会得到一个cmdline-tools文件夹。
3. 把解压出来的cmdline-tools里面的latest文件夹复制到D:\Android\Sdk\cmdline-tools下。

完成后目录结构应该是这样的：

D:\Android\Sdk\ ├── cmdline-tools\ │ └── latest\ │ └── bin\ │ ├── sdkmanager.bat │ └── ... ├── platform-tools\ ├── platforms\ └── build-tools\

很多人犯的错误是把 zip 直接在D:\Android\Sdk下解压，结果变成了D:\Android\Sdk\cmdline-tools\cmdline-tools\latest，多套了一层，sdkmanager 就找不到根目录。判断标准很简单：如果能用命令D:\Android\Sdk\cmdline-tools\latest\bin\sdkmanager.bat --version正常输出版本号，说明层级对了。

2.3 JDK 版本匹配与 JAVA_HOME

命令行工具本身是 Java 程序，所以运行它需要装 JDK。11076708这个版本要求 JDK 17，如果你以前装过 Android 开发环境，机器上可能同时存在 JDK 8、JDK 11、JDK 17。sdkmanager 启动时会读JAVA_HOME环境变量，指向哪个版本就用哪个版本。

我踩过的坑是：系统里装了多个 JDK，JAVA_HOME还指向旧版本，执行sdkmanager.bat --version直接抛UnsupportedClassVersionError。排查方法很简单，先执行java -version看当前默认 Java 版本，如果版本不对，就把JAVA_HOME改成 JDK 17 的安装目录，并确保PATH里的%JAVA_HOME%\bin排在前面。如果你本机只有 JRE，没有完整 JDK，也会有问题，sdkmanager 需要 JDK 的javac相关能力，单纯 JRE 不行。

2.4 PATH 与 ANDROID_HOME 配置

环境变量配不好，后面步步难受。建议至少配置三个变量：

• ANDROID_HOME：指向 SDK 根目录，也就是D:\Android\Sdk。
• ANDROID_SDK_ROOT：有些工具（特别是旧版 Gradle 插件和 Flutter）会认这个变量，同样指向D:\Android\Sdk，两个都设了最稳。
• PATH：新增%ANDROID_HOME%\cmdline-tools\latest\bin和%ANDROID_HOME%\platform-tools，这样你可以在任意目录执行sdkmanager、adb命令。

Windows 下配置环境变量的界面在哪里就不啰嗦了，只说几个注意点。第一，修改完环境变量必须重开终端窗口才会生效，急着验证之前先确认你是在新的终端里跑的。第二，有用户变量和系统变量之分，如果你只是给当前用户装开发环境，配用户变量就行，但如果给 CI 或构建服务器配，建议配系统变量，保证所有服务账号都能读到。第三，路径里不要带空格和中文，C:\Users\张三\Android这种路径会让一些老脚本崩溃，同理Program Files目录也尽量回避。

配置完成后，用下面的命令做一次验证：

sdkmanager.bat --version adb --version

如果两条命令都能输出正常信息，说明环境变量配好了，可以进行下一步。

3. sdkmanager 实操：真正开始管理 SDK

3.1 看有哪些包可以装

sdkmanager --list是第一个要记住的命令。这个命令会列出所有可用的 SDK 包、已安装的包和可更新的包。输出比较大，在 Windows 命令行里建议配合查找过滤：

sdkmanager.bat --list | findstr "platform-tools"

注意一个细节：--list默认只显示稳定版通道的包，如果你想看预览版或者测试版，可以加--channel=3（0 是稳定版，1 是测试版，2 是预览版，3 是全部）。做日常开发一般不需要装预览通道，除非你要提前适配新版 Android 系统。

sdkmanager --list里能看到包名都是有规律的。platforms;android-34表示 Android 14 的平台库，build-tools;34.0.0表示对应版本的构建工具，system-images;android-34;google_apis;x86_64表示模拟器用的系统镜像。理解这个命名规则后，你就知道要装哪个包了。

3.2 装 platform-tools、platforms 和 build-tools

新装环境一般至少需要这三样：

sdkmanager.bat "platform-tools" "platforms;android-34" "build-tools;34.0.0"

引号务必带上，尤其在 PowerShell 里，分号是语句分隔符，不加引号命令会被拆成两段导致解析错误。安装过程中会输出下载进度和已安装组件的路径，耗时取决于网络情况。

如果是做 Flutter 开发，通常还需要额外的包，但 Flutter 工具链会自动检测缺失项并提示你安装，不需要手动去猜。如果是做 NDK 相关的 C/C++ 开发，就再装ndk;版本号。基本原则是缺什么装什么，不要一次性把所有包都拉下来，SDK 全量装的话体积非常大，而且大部分你用不到。

这里提醒一句：安装完成后最好去D:\Android\Sdk\platform-tools看下有没有adb.exe，有就说明platform-tools装好了。platforms;android-34会生成D:\Android\Sdk\platforms\android-34，build-tools同理。

3.3 批量接受许可协议

这是新手最容易卡住的地方。sdkmanager 安装某些包前会先要你接受 license 协议，手动一个个输入y确实能过，但如果要装十几个包，每装一个都停下来问一次，体验极其糟糕，CI 环境里更是没法操作。

我常用的做法是先跑一次全局接受：

sdkmanager.bat --licenses

它会把所有未接受的 license 逐个列出来，你一直输入y回车，直到回到命令行提示符。如果要全自动，在 Windows 上可以这样：

( echo y echo y echo y echo y echo y echo y echo y echo y echo y echo y ) | sdkmanager.bat --licenses

PowerShell 下更直观：

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

执行完后，license 文件会写到D:\Android\Sdk\licenses目录下，后续 Gradle 构建自动下载 SDK 组件时就不会再卡在许可确认这一步。如果你重新下载了新版 cmdline-tools 但沿用同一个 SDK 目录，licenses 目录会保留，一般不用重新接受。

3.4 卸载、查看已安装和常用参数

卸载也走 sdkmanager：

sdkmanager.bat --uninstall "platforms;android-34"

查看已安装的包：

sdkmanager.bat --list_installed

如果你把 SDK 放在非默认位置，每次命令都带--sdk_root参数比较麻烦：

sdkmanager.bat --sdk_root=D:\Android\Sdk --list

不过我建议还是通过环境变量解决，而不是每次敲参数。还有一种场景：你的 cmdline-tools 目录名不叫latest，而是叫8.0、12.0之类的自定义名字。sdkmanager 会找不到它，因为它默认期望cmdline-tools/latest。这时候可以给命令加--sdk_root指向包含cmdline-tools的上层目录来绕过。但我的建议是不要折腾，目录名就叫latest，省去所有麻烦。

4. 配套工具实战：adb、avdmanager、apkanalyzer

4.1 adb 连接与调试

adb 是 Android 开发里最高频的命令，它来自platform-tools包。装好之后，先验证设备连接：

adb devices

正常连接时会看到设备的序列号和device状态。如果显示offline，多半是手机上的调试授权弹窗没点确认，或者驱动有问题。unauthorized就是手机上没允许这台电脑调试，重新插拔一下数据线再试。

日常开发常用的还有：

adb install app-debug.apk adb logcat adb shell adb reverse tcp:8081 tcp:8081

adb logcat在调试 framework、蓝牙、Binder 通信这类系统级问题时是必备的，过滤器配合logcat *:E只看错误信息能省不少眼力。adb shell进入设备终端后，可以跑dumpsys系列命令查看系统服务状态，调查系统崩溃、OTA 升级后的行为验证都离不开这些操作。

4.2 avdmanager 创建模拟器

创建模拟器需要先装系统镜像，然后调用 avdmanager：

sdkmanager.bat "system-images;android-34;google_apis;x86_64" avdmanager.bat create avd -n test_device -k "system-images;android-34;google_apis;x86_64" -d pixel_6

这里的-d pixel_6是指定设备定义，可以先执行avdmanager list device看有哪些可选设备。创建过程中会问你是否需要自定义硬件配置文件，直接no就行，后面要调整再改config.ini。

创建完成后，模拟器启动通常是由 emulator 包提供，需要额外安装：

sdkmanager.bat "emulator" emulator -avd test_device

如果你用 Android Studio 创建模拟器，底层逻辑是一样的，不过 Studio 把 avdmanager 的操作封装成了图形界面。命令行创建的好处是方便脚本化，比如每次跑完自动化测试就删掉模拟器重新建，保证环境干净。

4.3 apkanalyzer 快速分析 APK

有时候你拿到一个 APK，想知道它的包名、最低支持版本、权限列表，但又不想装 Jadx 或者打开 Android Studio，用 apkanalyzer 最快：

apkanalyzer.bat apk summary app-debug.apk apkanalyzer.bat manifest application-id app-debug.apk apkanalyzer.bat manifest permissions app-debug.apk apkanalyzer.bat manifest min-sdk app-debug.apk

这些命令在 CI 流水线里很好用，比如检查产物 APK 的 applicationId 是否符合预期，或者校验 minSdk 版本是否超过了某个阈值。它可以输出纯文本，方便脚本解析，不需要额外装任何解析库。

4.4 环境变量相关：ANDROID_HOME 与 ANDROID_SDK_ROOT

很多工具链（Gradle、Flutter、React Native）查找 SDK 时，会依次查ANDROID_HOME和ANDROID_SDK_ROOT这两个环境变量。我建议两个都设置成同一个值，避免某些工具只认其中一个变量时报 SDK 找不到。

有些开发者习惯单独设置ANDROID_SDK_ROOT，路径却和ANDROID_HOME不一致，结果 Gradle 用了一个 SDK，Flutter 用了另一个，两边装的 platform 版本不一致，构建时各种奇怪报错。最好的做法是统一：两个变量都指向D:\Android\Sdk。另外，local.properties文件里的sdk.dir优先级最高，它只对当前项目生效，如果你在项目里手动改了路径，以它为准。

5. 把这些串进自动化流程：Gradle、CI 与脚本

5.1 local.properties 和 Gradle 自动发现 SDK

Gradle 构建 Android 项目时，SDK 位置的查找顺序是：local.properties的sdk.dir属性、ANDROID_HOME环境变量、ANDROID_SDK_ROOT环境变量、默认路径。local.properties里这样写：

sdk.dir=D:\\Android\\Sdk

Windows 路径里的反斜杠要写成双反斜杠或正斜杠，否则解析会有问题。如果你已经配好了ANDROID_HOME，其实大多数时候不用写local.properties，但建议还是写上，保证项目换机器构建时能稳定找到 SDK。

Gradle 还有一个"自动下载 SDK"的机制：如果你的 SDK 缺少某个platforms;android-xx或build-tools，Gradle 的 Android 插件会自动调用 sdkmanager 去下载。前提是 cmdline-tools 就在 SDK 目录里，而且 license 已经接受过了。所以你在新机器上只装了 commandline-tools，没装 platforms，直接执行gradlew assembleDebug，它会自动把缺的包补齐，体验非常好。

5.2 无人值守安装脚本模板

如果你经常要初始化新电脑或者 CI 服务器，把整套动作写成脚本能省大量时间。我用的是这样一个 PowerShell 模板：

$sdkRoot = "D:\Android\Sdk" $cmdlineToolsZip = "commandlinetools-win-11076708_latest.zip" New-Item -ItemType Directory -Force -Path "$sdkRoot\cmdline-tools" Expand-Archive -Path $cmdlineToolsZip -DestinationPath "$sdkRoot\temp" -Force Copy-Item -Path "$sdkRoot\temp\cmdline-tools\latest" -Destination "$sdkRoot\cmdline-tools\" -Recurse -Force Remove-Item -Path "$sdkRoot\temp" -Recurse -Force $env:ANDROID_HOME = $sdkRoot $env:ANDROID_SDK_ROOT = $sdkRoot $env:Path += ";$sdkRoot\cmdline-tools\latest\bin;$sdkRoot\platform-tools" ./sdkmanager.bat --licenses ./sdkmanager.bat "platform-tools" "platforms;android-34" "build-tools;34.0.0"

脚本逻辑很直白：建目录、解压、复制到正确层级、配置临时环境变量、装基础组件。如果你要长期用，把环境变量设置部分改成setx命令让它持久化。注意Expand-Archive要求文件路径正确，zip 里cmdline-tools下面的内容会被原样复制。

5.3 国内网络下载慢的解决思路

sdkmanager 默认从 Google 的仓库下载，在国内网络环境下经常慢到怀疑人生。我实测下来，有几个可用的手段：

• 在网络相对稳定的时段（比如清晨）执行安装，下载速度会有明显改善。
• 使用国内云厂商提供的 SDK 仓库镜像，sdkmanager 支持通过--repository_url参数指定镜像仓库地址：

sdkmanager.bat --repository_url=https://mirrors.example.com/android/repository "platform-tools"

• 尽量走有线网络或 5GHz Wi-Fi，避免弱信号导致下载中断。
• 如果你在公司内网，也可以把已下载好的 SDK 整体打包拷贝到其他机器，比每台机器都重新拉一遍快得多。

我个人的体会是：最省心的方式还是找一台网络稳定的机器，把整个D:\Android\Sdk打包成 zip，然后在其他机器上解压、配环境变量，一步到位。Sdk 目录本身是可移植的，不依赖注册表，只要 licenses 目录和 source.properties 文件都在，复制过去就能用。

5.4 Flutter / RN / 其他跨端工具链复用

Flutter 的 Android 工具链其实复用的就是这套东西。配置 Flutter 环境时，它会去找ANDROID_HOME，然后检查 platform-tools、platforms、build-tools 是否存在，缺了就让开发者用 sdkmanager 或者 Android Studio 补齐。

React Native 也是类似逻辑，它的 Android 构建走的是 Gradle，底层依赖同一套 SDK。所以只要你把 commandlinetools 配好，Flutter、RN、原生 Android 三套技术栈在环境层面是共通的，不用每套框架各装一遍 SDK。这也是为什么我强烈建议新手先花半小时把命令行工具搞明白，后面开发环境会顺畅很多。

6. 常见问题与排查实录

6.1 报错速查表

我把这几年遇到的高频问题整理成了一个表格，方便对应检索。

以上是命令行工具相关的常见错误，实际构建时还可能遇到 Gradle 插件版本和 SDK 版本不匹配的问题，那个属于项目级配置，报错信息会更具体，按提示排查即可。

6.2 单独说说环境变量失效

环境变量配置后不生效是出现频率极高的一个问题。大部分人改了之后直接在当前终端跑命令，还想当然以为应该生效，然后开骂。Windows 环境变量只在进程启动时读取一次，已经打开的终端不会自动更新。

我的排查顺序是：先重开一个干净的终端，再执行echo %ANDROID_HOME%看变量有没有值。如果没有值，检查你配置的是用户变量还是系统变量，当前用户是否对应用户变量。如果值正确但命令还是找不到，接着检查 PATH 里是否包含%ANDROID_HOME%\cmdline-tools\latest\bin，注意路径分隔符是分号不是冒号。最后再验证一下sdkmanager.bat --version。

如果是在 IDE 里跑构建报 SDK 找不到，而命令行却正常，那大概率是 IDE 启动时没有继承最新的环境变量，重启 IDE 通常能解决。

6.3 license 与 target 相关的坑

licenses 目录是 SDK 根目录下的licenses文件夹，里面是一堆没有扩展名的文件，内容是 hash 值。如果这目录缺失或者内容不完整，sdkmanager 就会认为所有 license 都没有接受，每次构建都提示。

有一种情况：你从别人那里拷贝了 SDK，但只拷贝了 platforms、build-tools 等子目录，漏掉了licenses目录。结果 Gradle 构建时一直提示 license 未接受，而且自动下载 SDK 的机制也可能被触发重复下载。解决办法就是进到 SDK 根目录执行一次sdkmanager --licenses，重新生成 licenses 文件。

target 相关的坑更多是版本没装全。比如项目compileSdk 34，你只装了platforms;android-33，Gradle 就会提示Failed to find target。别手滑装错版本，Android 每大版本一个号，34 就是 34，不是 33 也不是 35。装了之后如果有缓存，执行一次 Gradle sync 或gradlew clean让工具重新检查。

6.4 我踩过的一些零碎坑

第一个坑是 zip 解压后直接把cmdline-tools\latest\bin里的sdkmanager.bat拷到桌面运行。Windows 下确实能跑，但因为当前目录不对，它创建的 SDK 目录会跑到桌面上去，而且之后再执行安装命令，工具会一直要求你用--sdk_root。最后我花了半天把所有文件清理掉重来。

第二个坑是在 Git Bash 里跑 sdkmanager.bat。Git Bash 会把 Windows 路径自动转换成 Unix 风格，D:\Android\Sdk会变成/d/Android/Sdk，而 sdkmanager 不认识这种路径。建议 Git Bash 里还是调sdkmanager.bat而不是sdkmanager，或者直接在 cmd 和 PowerShell 里跑更省心。

第三个坑是 SDK 目录权限。把 SDK 放到 C 盘根目录或者 Program Files 下，有时候会触发 UAC 拦截，看起来是命令执行失败，其实是没权限写入。日志里通常会出现Access is denied。SDK 目录一定放到一个普通用户完全可控的位置。

第四个坑是重复安装多个版本的 cmdline-tools。一些老教程会让你下载旧版 SDK Tools 解压到 SDK 根目录，这个方式早就废弃了。新版 cmdline-tools 只认cmdline-tools\latest，如果你把旧版tools目录和新的cmdline-tools混在一起，sdkmanager 可能会被旧版机制影响，行为变得很奇怪。

最后一个总结性的建议是：把 commandlinetools 当成一套基础设施来对待，所有和 SDK 相关的操作都尽量走命令行而不是图形界面。图形界面虽然友好，但没法脚本化，出了问题也难以复现。我自己的项目里已经习惯了"新机器装环境 5 分钟搞定"的节奏，靠的就是这份配置流程，希望这篇文章也能帮你把 Android 开发环境彻底捋顺。

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