简介本资源为 Android 官方命令行工具 Windows 版commandlinetools-win-11076708-latest.zip面向无需完整 Android Studio 的开发者、CI/CD 工程师及轻量级安卓构建场景用户解决 SDK 管理、AVD 创建、APK 分析与混淆调试等核心命令行需求。压缩包共 104 个文件含 93 个 Java 工具类 jar 包支撑 sdkmanager、avdmanager、apkanalyzer、lint 等核心功能、8 个 Windows 批处理脚本如 sdkmanager.bat、avdmanager.bat、1 个说明文档及配置文件整体体积 146.47MB结构精简、开箱即用。目前已有 561 人学习下载适合熟悉 Android 构建流程的中高级开发者快速部署离线 SDK 环境。读者可直接执行命令行工具完成 SDK 平台安装、模拟器管理、资源缩减、堆栈还原retrace及 Kotlin 编译支持等全链路操作无需依赖 IDE特别适用于自动化构建、容器化开发与教学环境复现。 很多人在搭建Android开发环境时第一步就卡在SDK的获取上。以前装Android Studio顺手就把SDK装了但当你只需要命令行编译、做CI自动化打包或者要给一台没有图形界面的服务器配环境时那个几百MB的commandlinetools-win-11076708-latest.zip就成了绕不开的起点。这篇文章就把这东西从头到尾讲透从它是什么、怎么装、怎么用到实战中会踩到的各种坑一次说清。1. 认识commandlinetoolsAndroid SDK的“最小启动器”1.1 为什么现在的SDK要从命令行工具开始装早期Android SDK是一个体积庞大的离线包下载下来解压即用。后来Google改变了分发策略不再提供完整SDK的独立压缩包而是只给一个很小的“安装器”——也就是commandlinetools。它本身不包含任何平台版本、构建工具只包含sdkmanager、avdmanager等几个核心命令真正的SDK组件全靠这些命令去下载。这个设计很像Linux系统的包管理器先装apt再用apt装别的。commandlinetools就是Android世界的“包管理器外壳”而platform-tools、platforms;android-34、build-tools;34.0.0这些才是实际干活的东西。所以你在命令行环境里安装SDK第一步永远是拿这个zip第二步永远是跑sdkmanager。1.2 zip包内部有什么每个目录都是干什么的拿到手先别急着解压看一下目录结构会更清楚。解压后你会得到一个cmdline-tools文件夹里面主要是bin和lib两个目录。bin目录里放着三个关键脚本sdkmanager.bat用于管理SDK组件的安装和卸载avdmanager.bat用于创建和管理虚拟设备apkanalyzer.bat用于分析APK文件。Windows下是.bat批处理Linux/macOS下是对应的无扩展名shell脚本功能完全一样。lib目录里是一堆jar包包括sdkmanager.jar、avdmanager.jar等。这些脚本本质上是“壳”真正逻辑都在jar里外层用Java启动它们。所以你会发现一个硬性前提系统必须先装好JDK否则.bat双击后一闪而过窗口都来不及看清。这一点后文会详细讲。1.3 版本号11076708到底代表什么commandlinetools-win-11076708-latest.zip这串名字里win表示Windows平台对应还有linux和darwin版本11076708是构建版本号latest表示这是当前最新稳定渠道的包。版本号本身没有直接的“API level”含义它对应的是工具自身的迭代。比如这个版本对应JDK 17是没问题的也支持后续下载最新的platforms;android-34、build-tools;34.0.0。实际使用时没必要纠结具体版本号认准“从官方渠道拿最新”就行。因为SDK工具版本太旧时可能不支持新发布的Android平台这时sdkmanager --list能看到新组件但安装时提示版本不匹配只要换最新款commandlinetools即可解决。2. 从零开始下载、解压与目录规划2.1 下载前先想清楚的事下载地址是Android开发者官网的“命令行工具”页面。页面会列出Windows、Linux、macOS三套包千万别下错平台。Windows下选commandlinetools-win-...Linux服务器选commandlinetools-linux-...macOS选commandlinetools-mac-...mac还有Apple Silicon的变体darwin-aarch64根据芯片选。下载时另一个容易忽略的点是版本一致性。如果你后面要跑的是老项目compileSdkVersion可能只有30或31那没必要追最新下载一个对应年代的commandlinetools版本反而更稳。但正常情况下直接拿最新就好因为有--sdk_root参数可以隔离不同SDK版本多版本共存也不冲突。另外下载完建议先校验一下文件完整性。Windows下可以用certutil -hashfile commandlinetools-win-11076708-latest.zip SHA256Linux下用sha256sum拿算出来的哈希值和官网给的对一下。这个问题我踩过一次由于网络中断下载的zip不完整解压时一直提示文件损坏或CRC校验失败当时一度以为是电脑问题最后才发现是被“好心”的下载工具改坏了文件格式。2.2 解压到哪、目录怎么命名最常见的低级错误解压这一步看着简单实际很多人在这里翻车。Google在文档里明确说了cmdline-tools目录下面必须再套一层latest。也就是说最终的目录结构应该是你的SDK目录/ └─ cmdline-tools/ └─ latest/ ├─ bin/ ├─ lib/ ├─ NOTICE.txt └─ source.properties如果你直接解压成cmdline-tools/bin这样的结构运行sdkmanager时会报错因为它找不到自己的lib目录和版本信息。网上很多人问“为什么sdkmanager双击闪退”“为什么提示找不到SDK”八成就是目录结构错了。推荐的安装路径是放在一个独立的目录比如D:\Android\Sdk或~/Android/Sdk。为什么不建议放在C盘默认位置呢因为SDK组件全装完有好几个GBC盘空间紧张的同学很快会后悔。把commandlinetools解压到SDK目录下的cmdline-tools/latest后后续通过sdkmanager下载的所有组件都会默认装到同一根目录下方便统一管理。如果非要用不叫latest的文件夹名理论上也能通过--sdk_root参数指定但那就把自己绕进复杂度里了老老实实用latest是最省心的做法。2.3 配置环境变量让命令随手可用解压完成后需要把cmdline-tools\latest\bin加入PATH这样在任何目录下敲sdkmanager都能识别。Windows下的方法是设置里搜索“编辑系统环境变量” → 环境变量 → 在Path中新建一行填入你的cmdline-tools\latest\bin路径。Linux下则写入~/.bashrc或~/.zshrcexport ANDROID_HOME$HOME/Android/Sdk export PATH$PATH:$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools建议顺手把ANDROID_HOME也配了。虽然sdkmanager本身不强制读这个变量但后面的Gradle、Flutter、React Native等工具都会读它。特别是做Flutter开发时flutter doctor会检查ANDROID_HOME是否存在没配好它就只能报错提示找不到Android SDK。配置完成后别急着高兴先敲一句sdkmanager --version验证一下。如果提示“不是内部或外部命令”说明PATH没配上或当前终端没重新加载Linux下记得先source ~/.bashrc。如果提示找不到Java那就是JDK这一步还没解决看后面的排查部分。3. 核心实操sdkmanager的安装与常用命令3.1 先确认JDK这个工具的全部前提sdkmanager是用Java写的所以第一步是确认系统里有可用的JDK。这个工具对JDK版本有硬性要求——较新版本如11076708这个时期要求JDK 17及以上。装个OpenJDK 17或Oracle JDK 17都很常见从Eclipse Adoptium或各发行版软件源都能拿到安装后配好JAVA_HOME环境变量就行。验证JDK是否就绪打开终端敲java -version能看到版本号比如openjdk version 17.0.8就是正常的。注意Windows下如果装了多个Java版本最好在环境变量里把JAVA_HOME指清楚否则java命令可能被其他软件带的JRE抢占导致sdkmanager启动时出现奇妙的问题。有个常见误导是“运行sdkmanager一定要把JAVA_HOME配好”实际只要java命令在PATH中可用就能跑。但很多工具链比如Gradle、Android Studio都在读JAVA_HOME所以还是建议一步到位把JAVA_HOME配好省得以后再来补。3.2 列出可安装组件选对platform和build-tools安装任何东西之前建议先看看有哪些组件可以装。运行sdkmanager --list输出内容很多会分两个区域Installed packages和Available Packages。Available Packages里比较重要的几类platforms;android-XX对应Android API Level的开发平台。比如platforms;android-34就是Android 14的SDK平台。build-tools;XX.X.X编译、打包APK所需的工具链。比如build-tools;34.0.0。platform-tools包含adb、fastboot这些连接真机和平板的关键工具。ndk;XX.X.X做C/C原生开发时的Native Development Kit。cmake;X.X.XNDK开发中用于构建原生代码的构建系统。system-images;android-XX;...创建模拟器时需要的系统镜像。对于常规Android开发最基础的是sdkmanager platform-tools platforms;android-34其中platforms;android-34可以换成项目里compileSdkVersion对应的值。如果你的项目compileSdkVersion是33装platforms;android-33就够过度装高版本也不会带来额外收益。3.3 实际安装命令的细节与提示安装是一件“看似简单坑却不少”的事。直接运行sdkmanager platform-tools platforms;android-34 build-tools;34.0.0它会先显示一些许可协议要求你输入y确认。这里有个升级版的需求——如果你在脚本或CI里自动安装不可能每次都人工去输y所以官方提供了这样的写法yes | sdkmanager --licenses这个命令会一次性接受所有许可协议。建议在任何新机器上装完SDK后先执行一次这条命令能省掉后面无数次的“y/N”交互。安装过程中你会发现它并不显示下载进度条只有一些类似[]的简单进度信息不要以为卡住了。国内网络环境下某些组件下载速度可能会很慢甚至超时这时候可以考虑设置镜像源后文会单独说。装完之后再执行sdkmanager --list_installed看到刚才安装的包出现在列表里就说明成功了。此时platform-tools目录下应该有adb.exeWindows或adbLinux/macOS。adb version能跑出版本号证明整个环境已经可用。3.4 接受许可协议一条命令解决所有y/N交互可能有人会问“为什么Google要搞这么多次许可协议确认”因为Android SDK的各个组件分别受不同开源协议约束比如NDK有LGPL系统镜像有Google的Terms and Conditions所以首次安装必须逐一确认。在交互终端里一个一个y还能接受但在无人值守的安装脚本里就成了灾难。yes | sdkmanager --licenses这个组合是社区的标准做法yes命令会不断输出y并管道传给sdkmanager相当于自动把所有的“Do you accept the license?”都回答了。实测下来这一步执行完后面任何常规安装都不再出现许可确认体验顺畅得多。有一个细节值得注意yes会持续输出直到目标进程退出。如果sdkmanager已经接受完所有许可管道的另一端结束了yes自然会被中断不会无限刷屏。这个命令在Windows的CMD下也能用只是如果你用的是PowerShellyes命令不被原生支持需要装GNU工具或改用cmd /c echo y | sdkmanager --licenses。4. 进阶用法命令行SDK的实战场景4.1 搭建“无Android Studio”的编译环境有了sdkmanager就算电脑上完全没装Android Studio也能构建出一个能编译APK的开发环境。这在很多场景很有用CI服务器、Docker镜像、内存有限的云开发机等。基本步骤是以Android目录为根用sdkmanager装齐platform-tools、platforms;android-XX、build-tools;XX.X.X再用Gradle拉取项目依赖并执行gradlew assembleDebugGradle会通过ANDROID_HOME自动定位SDK并完成编译。整个过程不需要打开任何IDE。但需要注意Gradle本身需要下载第一次构建时它还要下载对应版本的全部分发包所以这类环境务必保证网络稳定。如果你在CI上构建建议把Gradle和Android依赖的缓存目录设为持久化卷否则每次构建都全量下载慢到你怀疑人生。4.2 avdmanager创建模拟器命令行也能开虚拟机sdkmanager装好以后旁边还坐着一个avdmanager它是创建Android虚拟设备AVD的命令行工具。平时大家都用Android Studio的可视化界面创建模拟器但其实命令行也能搞定而且更适合脚本化配置。先装一个系统镜像sdkmanager system-images;android-33;google_apis;x86_64然后创建AVDavdmanager create avd -n test_device -k system-images;android-33;google_apis;x86_64 -d pixel_5-n是给设备起名-k指定系统镜像包-d指定设备定义可以在avdmanager list device里查看所有可选设备。创建完成后可以直接用emulator -avd test_device启动模拟器。这条路径特别适合对模拟器做批量测试的团队把AVD创建、SDK安装全部写进脚本新入职同事一条命令就能拉起完整的本地Android环境。省去打开Android Studio、点半天图形界面的功夫。4.3 用命令行工具直接做APK分析apkanalyzer是commandlinetools包里的另一个实用工具。它能在不安装IDE的情况下对APK做深度分析。查看APK的基本信息apkanalyzer manifest print app.apk这条命令会输出APK的AndroidManifest.xml可读内容如包名、版本、权限、组件声明等。要查看APK的下载大小和APK的原始文件大小对比apkanalyzer apk download-size app.apk apkanalyzer apk file-size app.apk以前要分析APK都得去下载Android Studio或者用第三方工具。现在命令行直接搞定写个脚本批量分析应用市场的APK也不在话下。安全检查场景下可以用它看APK申请了哪些敏感权限不需要反编译工具。4.4 把sdkmanager接入自动化脚本如果你维护着多台开发机或CI节点建议把所有安装步骤写成脚本而不是每台机器都手动操作一遍。Windows下可以写个批处理echo off set ANDROID_HOMED:\Android\Sdk mkdir %ANDROID_HOME%\cmdline-tools tar -xf commandlinetools-win-11076708-latest.zip -C %ANDROID_HOME%\cmdline-tools move %ANDROID_HOME%\cmdline-tools\cmdline-tools %ANDROID_HOME%\cmdline-tools\latest yes | sdkmanager --licenses sdkmanager platform-tools platforms;android-34 build-tools;34.0.0Linux下同理可以用一行行的bash命令组合。核心思路就三步解压到正确目录 → 接受许可 → 安装组件。多台机器全部Copy-Paste运行环境保证一致不会出现“我本地好好的你那怎么不行”的尴尬。一个小提示如果团队有统一的Gradle项目还可以借助Gradle的android-sdk-manager插件自动安装SDK但那是另一个话题。纯命令行脚本的方式最透明、最好排查问题。5. 常见问题与排查技巧实录5.1 “找不到Java”或“UnsupportedClassVersionError”这是新手最容易撞的墙。症状是运行sdkmanager时提示java: command not found或者更高级一点Error: A JNI error has occurred, please check your installation and try again。原因基本是JDK没装或装了但没进PATH或版本太旧。新版commandlinetools要求JDK 17如果系统里是JDK 8或11启动时就会抛出UnsupportedClassVersionError。解决办法安装JDK 17及以上确保JAVA_HOME和PATH配置正确然后注销重登或刷新终端再试。Windows下还有一个隐性问题如果安装过Oracle自带JRE它可能把java.exe放到C:\Windows\System32里导致PATH优先级被干扰。排查方法是在命令行里敲where java看它实际解析到哪个目录就能定位到底是哪个Java在被调用。5.2 目录结构不对导致的“SDK not found”类报错就像前文说的cmdline-tools目录下必须有latest子目录。如果解压时少了这一层运行sdkmanager --list_installed可能不会立刻报错但后续Gradle、本地的flutter doctor可能会提示找不到SDK。因为Gradle查找SDK时会找$ANDROID_HOME/platforms、$ANDROID_HOME/build-tools这些目录。如果ANDROID_HOME指到了D:\Android\Sdk但SDK组件实际被安装到了其他层级目录错乱就会导致Gradle的SDK定位失败。我的建议是把目录结构严格做成D:\Android\Sdk ├─ cmdline-tools │ └─ latest ├─ platform-tools ├─ platforms ├─ build-tools └─ ndk这样所有工具默认自动归位Gradle、Flutter、React Native都能正确识别。不要去自定义“个人风格”的目录命名代价是各种工具找不到路径。5.3 网络下载慢或超时换镜像源的方案国内连接官方源下载SDK组件经常出现几十KB/s的龟速甚至直接超时。这里不建议用什么第三方商业加速工具也不建议折腾额外网络设备最稳妥的方案是使用国内开源镜像站。比如阿里云镜像、腾讯云镜像都提供Android SDK的镜像地址。用sdkmanager时可以通过--channel和仓库地址调整吗其实sdkmanager一直没有提供直接改源的官方参数但可以通过设置REPO_OS_OVERRIDE或修改repositories.cfg来影响。更简单的方法是在Gradle的init.gradle或项目的build.gradle里配置阿里云镜像仓库来拉取依赖SDK组件本身可以通过下载镜像站打包好的SDK文件来实现。更实际的操作是从镜像站直接下载完整SDK压缩包比如平台、build-tools解压到对应目录然后用sdkmanager补装缺失的组件。这样既绕过了最慢的部分又保留了sdkmanager后续自动安装能力。另外分享一个经验避免在高峰时段执行大批量安装。清晨或午夜的下载成功率明显高很多这也是不少CI团队把环境预置放在深夜定时任务的原因。如果实在是公司网络限制可以下载用离线包放入本地缓存Gradle或sdkmanager会自动发现缓存不再重复下载。5.4 提示“Warning: File ... could not be copied”或权限问题Windows下如果SDK目录安装在C:\Program Files这类系统保护目录普通用户执行sdkmanager安装组件时经常出现权限不足导致文件无法写入。典型的报错长这样Warning: File C:\Program Files\Android\... could not be copied.解决办法有两个方向一是用管理员权限运行终端再执行sdkmanager二是把SDK目录改到用户目录下比如C:\Users\你的用户名\Android\Sdk或D:\Android\Sdk。我更推荐后者因为以管理员身份运行容易把目录里的文件权限搞乱后续非管理员工具的读写会受影响。Linux下类似别把SDK放到/usr或/opt下然后纠结权限直接放~/Android/Sdk设置ANDROID_HOME后完全无障碍。既然是开发工具使用者就该有完整的读写控制权这是最舒服的状态。5.5 和Android Studio的SDK目录冲突问题很多人的电脑上既有Android Studio又在折腾命令行SDK。这时要确认你希望ANDROID_HOME指向哪边。如果Android Studio已经自动装了一套SDK理论上可以共用同一套没必要再装第二份。Android Studio的SDK Manager里显示的“Android SDK Location”就是ANDROID_HOME应该指的位置。如果你决定用命令行管理新SDK可以不改动Android Studio自身配置只把ANDROID_HOME环境变量指向新SDK目录。这样的话Android Studio里通过图形界面安装的组件和新命令行装的状态是隔离的。但如果你某个项目打开时用的是Android Studio内置SDK另一些脚本用命令行SDK很容易出现“版本不一致”的怪问题。我的习惯是统一非特殊需求ANDROID_HOME只指一个SDK根目录cmdline-tools和Android Studio共用。这样两边装的东西都落在同一目录树基本不会出幺蛾子。6. 实用总结与我的个人经验把commandlinetools-win-11076708-latest.zip从“一个看不懂的压缩包”变成“顺手好用的SDK管理工具”其实本质就三步解压到cmdline-tools/latest配置好JDK和PATH用sdkmanager装组件。整个过程不复杂但每一步都有细节目录结构、许可协议、网络源都是最常见的绊脚石。我个人的体会是不要嫌命令行麻烦。就算你平时都用Android Studio学会sdkmanager也会让你在排查环境问题、写自动化任务时快人一步。比如同事报“SDK缺了build-tools 30.0.3”你一行sdkmanager build-tools;30.0.3就解决了不用让他打开IDE点点点。最后分享一个我一直在用的小技巧新机器完成SDK安装后立刻执行一次yes | sdkmanager --licenses然后全量安装你项目常用到的所有platform和build-tools版本。因为等你真的要用某个旧版本时再临时装一方面慢另一方面容易因为网络问题卡在一半。提前把许可交了、常用组件装了后续所有构建都能直接从本地读取那种顺手的感觉试一次就知道。本文还有配套的精品资源点击获取 Android SDK命令行工具完全指南：从下载到实战踩坑
简介本资源为 Android 官方命令行工具 Windows 版commandlinetools-win-11076708-latest.zip面向无需完整 Android Studio 的开发者、CI/CD 工程师及轻量级安卓构建场景用户解决 SDK 管理、AVD 创建、APK 分析与混淆调试等核心命令行需求。压缩包共 104 个文件含 93 个 Java 工具类 jar 包支撑 sdkmanager、avdmanager、apkanalyzer、lint 等核心功能、8 个 Windows 批处理脚本如 sdkmanager.bat、avdmanager.bat、1 个说明文档及配置文件整体体积 146.47MB结构精简、开箱即用。目前已有 561 人学习下载适合熟悉 Android 构建流程的中高级开发者快速部署离线 SDK 环境。读者可直接执行命令行工具完成 SDK 平台安装、模拟器管理、资源缩减、堆栈还原retrace及 Kotlin 编译支持等全链路操作无需依赖 IDE特别适用于自动化构建、容器化开发与教学环境复现。 很多人在搭建Android开发环境时第一步就卡在SDK的获取上。以前装Android Studio顺手就把SDK装了但当你只需要命令行编译、做CI自动化打包或者要给一台没有图形界面的服务器配环境时那个几百MB的commandlinetools-win-11076708-latest.zip就成了绕不开的起点。这篇文章就把这东西从头到尾讲透从它是什么、怎么装、怎么用到实战中会踩到的各种坑一次说清。1. 认识commandlinetoolsAndroid SDK的“最小启动器”1.1 为什么现在的SDK要从命令行工具开始装早期Android SDK是一个体积庞大的离线包下载下来解压即用。后来Google改变了分发策略不再提供完整SDK的独立压缩包而是只给一个很小的“安装器”——也就是commandlinetools。它本身不包含任何平台版本、构建工具只包含sdkmanager、avdmanager等几个核心命令真正的SDK组件全靠这些命令去下载。这个设计很像Linux系统的包管理器先装apt再用apt装别的。commandlinetools就是Android世界的“包管理器外壳”而platform-tools、platforms;android-34、build-tools;34.0.0这些才是实际干活的东西。所以你在命令行环境里安装SDK第一步永远是拿这个zip第二步永远是跑sdkmanager。1.2 zip包内部有什么每个目录都是干什么的拿到手先别急着解压看一下目录结构会更清楚。解压后你会得到一个cmdline-tools文件夹里面主要是bin和lib两个目录。bin目录里放着三个关键脚本sdkmanager.bat用于管理SDK组件的安装和卸载avdmanager.bat用于创建和管理虚拟设备apkanalyzer.bat用于分析APK文件。Windows下是.bat批处理Linux/macOS下是对应的无扩展名shell脚本功能完全一样。lib目录里是一堆jar包包括sdkmanager.jar、avdmanager.jar等。这些脚本本质上是“壳”真正逻辑都在jar里外层用Java启动它们。所以你会发现一个硬性前提系统必须先装好JDK否则.bat双击后一闪而过窗口都来不及看清。这一点后文会详细讲。1.3 版本号11076708到底代表什么commandlinetools-win-11076708-latest.zip这串名字里win表示Windows平台对应还有linux和darwin版本11076708是构建版本号latest表示这是当前最新稳定渠道的包。版本号本身没有直接的“API level”含义它对应的是工具自身的迭代。比如这个版本对应JDK 17是没问题的也支持后续下载最新的platforms;android-34、build-tools;34.0.0。实际使用时没必要纠结具体版本号认准“从官方渠道拿最新”就行。因为SDK工具版本太旧时可能不支持新发布的Android平台这时sdkmanager --list能看到新组件但安装时提示版本不匹配只要换最新款commandlinetools即可解决。2. 从零开始下载、解压与目录规划2.1 下载前先想清楚的事下载地址是Android开发者官网的“命令行工具”页面。页面会列出Windows、Linux、macOS三套包千万别下错平台。Windows下选commandlinetools-win-...Linux服务器选commandlinetools-linux-...macOS选commandlinetools-mac-...mac还有Apple Silicon的变体darwin-aarch64根据芯片选。下载时另一个容易忽略的点是版本一致性。如果你后面要跑的是老项目compileSdkVersion可能只有30或31那没必要追最新下载一个对应年代的commandlinetools版本反而更稳。但正常情况下直接拿最新就好因为有--sdk_root参数可以隔离不同SDK版本多版本共存也不冲突。另外下载完建议先校验一下文件完整性。Windows下可以用certutil -hashfile commandlinetools-win-11076708-latest.zip SHA256Linux下用sha256sum拿算出来的哈希值和官网给的对一下。这个问题我踩过一次由于网络中断下载的zip不完整解压时一直提示文件损坏或CRC校验失败当时一度以为是电脑问题最后才发现是被“好心”的下载工具改坏了文件格式。2.2 解压到哪、目录怎么命名最常见的低级错误解压这一步看着简单实际很多人在这里翻车。Google在文档里明确说了cmdline-tools目录下面必须再套一层latest。也就是说最终的目录结构应该是你的SDK目录/ └─ cmdline-tools/ └─ latest/ ├─ bin/ ├─ lib/ ├─ NOTICE.txt └─ source.properties如果你直接解压成cmdline-tools/bin这样的结构运行sdkmanager时会报错因为它找不到自己的lib目录和版本信息。网上很多人问“为什么sdkmanager双击闪退”“为什么提示找不到SDK”八成就是目录结构错了。推荐的安装路径是放在一个独立的目录比如D:\Android\Sdk或~/Android/Sdk。为什么不建议放在C盘默认位置呢因为SDK组件全装完有好几个GBC盘空间紧张的同学很快会后悔。把commandlinetools解压到SDK目录下的cmdline-tools/latest后后续通过sdkmanager下载的所有组件都会默认装到同一根目录下方便统一管理。如果非要用不叫latest的文件夹名理论上也能通过--sdk_root参数指定但那就把自己绕进复杂度里了老老实实用latest是最省心的做法。2.3 配置环境变量让命令随手可用解压完成后需要把cmdline-tools\latest\bin加入PATH这样在任何目录下敲sdkmanager都能识别。Windows下的方法是设置里搜索“编辑系统环境变量” → 环境变量 → 在Path中新建一行填入你的cmdline-tools\latest\bin路径。Linux下则写入~/.bashrc或~/.zshrcexport ANDROID_HOME$HOME/Android/Sdk export PATH$PATH:$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools建议顺手把ANDROID_HOME也配了。虽然sdkmanager本身不强制读这个变量但后面的Gradle、Flutter、React Native等工具都会读它。特别是做Flutter开发时flutter doctor会检查ANDROID_HOME是否存在没配好它就只能报错提示找不到Android SDK。配置完成后别急着高兴先敲一句sdkmanager --version验证一下。如果提示“不是内部或外部命令”说明PATH没配上或当前终端没重新加载Linux下记得先source ~/.bashrc。如果提示找不到Java那就是JDK这一步还没解决看后面的排查部分。3. 核心实操sdkmanager的安装与常用命令3.1 先确认JDK这个工具的全部前提sdkmanager是用Java写的所以第一步是确认系统里有可用的JDK。这个工具对JDK版本有硬性要求——较新版本如11076708这个时期要求JDK 17及以上。装个OpenJDK 17或Oracle JDK 17都很常见从Eclipse Adoptium或各发行版软件源都能拿到安装后配好JAVA_HOME环境变量就行。验证JDK是否就绪打开终端敲java -version能看到版本号比如openjdk version 17.0.8就是正常的。注意Windows下如果装了多个Java版本最好在环境变量里把JAVA_HOME指清楚否则java命令可能被其他软件带的JRE抢占导致sdkmanager启动时出现奇妙的问题。有个常见误导是“运行sdkmanager一定要把JAVA_HOME配好”实际只要java命令在PATH中可用就能跑。但很多工具链比如Gradle、Android Studio都在读JAVA_HOME所以还是建议一步到位把JAVA_HOME配好省得以后再来补。3.2 列出可安装组件选对platform和build-tools安装任何东西之前建议先看看有哪些组件可以装。运行sdkmanager --list输出内容很多会分两个区域Installed packages和Available Packages。Available Packages里比较重要的几类platforms;android-XX对应Android API Level的开发平台。比如platforms;android-34就是Android 14的SDK平台。build-tools;XX.X.X编译、打包APK所需的工具链。比如build-tools;34.0.0。platform-tools包含adb、fastboot这些连接真机和平板的关键工具。ndk;XX.X.X做C/C原生开发时的Native Development Kit。cmake;X.X.XNDK开发中用于构建原生代码的构建系统。system-images;android-XX;...创建模拟器时需要的系统镜像。对于常规Android开发最基础的是sdkmanager platform-tools platforms;android-34其中platforms;android-34可以换成项目里compileSdkVersion对应的值。如果你的项目compileSdkVersion是33装platforms;android-33就够过度装高版本也不会带来额外收益。3.3 实际安装命令的细节与提示安装是一件“看似简单坑却不少”的事。直接运行sdkmanager platform-tools platforms;android-34 build-tools;34.0.0它会先显示一些许可协议要求你输入y确认。这里有个升级版的需求——如果你在脚本或CI里自动安装不可能每次都人工去输y所以官方提供了这样的写法yes | sdkmanager --licenses这个命令会一次性接受所有许可协议。建议在任何新机器上装完SDK后先执行一次这条命令能省掉后面无数次的“y/N”交互。安装过程中你会发现它并不显示下载进度条只有一些类似[]的简单进度信息不要以为卡住了。国内网络环境下某些组件下载速度可能会很慢甚至超时这时候可以考虑设置镜像源后文会单独说。装完之后再执行sdkmanager --list_installed看到刚才安装的包出现在列表里就说明成功了。此时platform-tools目录下应该有adb.exeWindows或adbLinux/macOS。adb version能跑出版本号证明整个环境已经可用。3.4 接受许可协议一条命令解决所有y/N交互可能有人会问“为什么Google要搞这么多次许可协议确认”因为Android SDK的各个组件分别受不同开源协议约束比如NDK有LGPL系统镜像有Google的Terms and Conditions所以首次安装必须逐一确认。在交互终端里一个一个y还能接受但在无人值守的安装脚本里就成了灾难。yes | sdkmanager --licenses这个组合是社区的标准做法yes命令会不断输出y并管道传给sdkmanager相当于自动把所有的“Do you accept the license?”都回答了。实测下来这一步执行完后面任何常规安装都不再出现许可确认体验顺畅得多。有一个细节值得注意yes会持续输出直到目标进程退出。如果sdkmanager已经接受完所有许可管道的另一端结束了yes自然会被中断不会无限刷屏。这个命令在Windows的CMD下也能用只是如果你用的是PowerShellyes命令不被原生支持需要装GNU工具或改用cmd /c echo y | sdkmanager --licenses。4. 进阶用法命令行SDK的实战场景4.1 搭建“无Android Studio”的编译环境有了sdkmanager就算电脑上完全没装Android Studio也能构建出一个能编译APK的开发环境。这在很多场景很有用CI服务器、Docker镜像、内存有限的云开发机等。基本步骤是以Android目录为根用sdkmanager装齐platform-tools、platforms;android-XX、build-tools;XX.X.X再用Gradle拉取项目依赖并执行gradlew assembleDebugGradle会通过ANDROID_HOME自动定位SDK并完成编译。整个过程不需要打开任何IDE。但需要注意Gradle本身需要下载第一次构建时它还要下载对应版本的全部分发包所以这类环境务必保证网络稳定。如果你在CI上构建建议把Gradle和Android依赖的缓存目录设为持久化卷否则每次构建都全量下载慢到你怀疑人生。4.2 avdmanager创建模拟器命令行也能开虚拟机sdkmanager装好以后旁边还坐着一个avdmanager它是创建Android虚拟设备AVD的命令行工具。平时大家都用Android Studio的可视化界面创建模拟器但其实命令行也能搞定而且更适合脚本化配置。先装一个系统镜像sdkmanager system-images;android-33;google_apis;x86_64然后创建AVDavdmanager create avd -n test_device -k system-images;android-33;google_apis;x86_64 -d pixel_5-n是给设备起名-k指定系统镜像包-d指定设备定义可以在avdmanager list device里查看所有可选设备。创建完成后可以直接用emulator -avd test_device启动模拟器。这条路径特别适合对模拟器做批量测试的团队把AVD创建、SDK安装全部写进脚本新入职同事一条命令就能拉起完整的本地Android环境。省去打开Android Studio、点半天图形界面的功夫。4.3 用命令行工具直接做APK分析apkanalyzer是commandlinetools包里的另一个实用工具。它能在不安装IDE的情况下对APK做深度分析。查看APK的基本信息apkanalyzer manifest print app.apk这条命令会输出APK的AndroidManifest.xml可读内容如包名、版本、权限、组件声明等。要查看APK的下载大小和APK的原始文件大小对比apkanalyzer apk download-size app.apk apkanalyzer apk file-size app.apk以前要分析APK都得去下载Android Studio或者用第三方工具。现在命令行直接搞定写个脚本批量分析应用市场的APK也不在话下。安全检查场景下可以用它看APK申请了哪些敏感权限不需要反编译工具。4.4 把sdkmanager接入自动化脚本如果你维护着多台开发机或CI节点建议把所有安装步骤写成脚本而不是每台机器都手动操作一遍。Windows下可以写个批处理echo off set ANDROID_HOMED:\Android\Sdk mkdir %ANDROID_HOME%\cmdline-tools tar -xf commandlinetools-win-11076708-latest.zip -C %ANDROID_HOME%\cmdline-tools move %ANDROID_HOME%\cmdline-tools\cmdline-tools %ANDROID_HOME%\cmdline-tools\latest yes | sdkmanager --licenses sdkmanager platform-tools platforms;android-34 build-tools;34.0.0Linux下同理可以用一行行的bash命令组合。核心思路就三步解压到正确目录 → 接受许可 → 安装组件。多台机器全部Copy-Paste运行环境保证一致不会出现“我本地好好的你那怎么不行”的尴尬。一个小提示如果团队有统一的Gradle项目还可以借助Gradle的android-sdk-manager插件自动安装SDK但那是另一个话题。纯命令行脚本的方式最透明、最好排查问题。5. 常见问题与排查技巧实录5.1 “找不到Java”或“UnsupportedClassVersionError”这是新手最容易撞的墙。症状是运行sdkmanager时提示java: command not found或者更高级一点Error: A JNI error has occurred, please check your installation and try again。原因基本是JDK没装或装了但没进PATH或版本太旧。新版commandlinetools要求JDK 17如果系统里是JDK 8或11启动时就会抛出UnsupportedClassVersionError。解决办法安装JDK 17及以上确保JAVA_HOME和PATH配置正确然后注销重登或刷新终端再试。Windows下还有一个隐性问题如果安装过Oracle自带JRE它可能把java.exe放到C:\Windows\System32里导致PATH优先级被干扰。排查方法是在命令行里敲where java看它实际解析到哪个目录就能定位到底是哪个Java在被调用。5.2 目录结构不对导致的“SDK not found”类报错就像前文说的cmdline-tools目录下必须有latest子目录。如果解压时少了这一层运行sdkmanager --list_installed可能不会立刻报错但后续Gradle、本地的flutter doctor可能会提示找不到SDK。因为Gradle查找SDK时会找$ANDROID_HOME/platforms、$ANDROID_HOME/build-tools这些目录。如果ANDROID_HOME指到了D:\Android\Sdk但SDK组件实际被安装到了其他层级目录错乱就会导致Gradle的SDK定位失败。我的建议是把目录结构严格做成D:\Android\Sdk ├─ cmdline-tools │ └─ latest ├─ platform-tools ├─ platforms ├─ build-tools └─ ndk这样所有工具默认自动归位Gradle、Flutter、React Native都能正确识别。不要去自定义“个人风格”的目录命名代价是各种工具找不到路径。5.3 网络下载慢或超时换镜像源的方案国内连接官方源下载SDK组件经常出现几十KB/s的龟速甚至直接超时。这里不建议用什么第三方商业加速工具也不建议折腾额外网络设备最稳妥的方案是使用国内开源镜像站。比如阿里云镜像、腾讯云镜像都提供Android SDK的镜像地址。用sdkmanager时可以通过--channel和仓库地址调整吗其实sdkmanager一直没有提供直接改源的官方参数但可以通过设置REPO_OS_OVERRIDE或修改repositories.cfg来影响。更简单的方法是在Gradle的init.gradle或项目的build.gradle里配置阿里云镜像仓库来拉取依赖SDK组件本身可以通过下载镜像站打包好的SDK文件来实现。更实际的操作是从镜像站直接下载完整SDK压缩包比如平台、build-tools解压到对应目录然后用sdkmanager补装缺失的组件。这样既绕过了最慢的部分又保留了sdkmanager后续自动安装能力。另外分享一个经验避免在高峰时段执行大批量安装。清晨或午夜的下载成功率明显高很多这也是不少CI团队把环境预置放在深夜定时任务的原因。如果实在是公司网络限制可以下载用离线包放入本地缓存Gradle或sdkmanager会自动发现缓存不再重复下载。5.4 提示“Warning: File ... could not be copied”或权限问题Windows下如果SDK目录安装在C:\Program Files这类系统保护目录普通用户执行sdkmanager安装组件时经常出现权限不足导致文件无法写入。典型的报错长这样Warning: File C:\Program Files\Android\... could not be copied.解决办法有两个方向一是用管理员权限运行终端再执行sdkmanager二是把SDK目录改到用户目录下比如C:\Users\你的用户名\Android\Sdk或D:\Android\Sdk。我更推荐后者因为以管理员身份运行容易把目录里的文件权限搞乱后续非管理员工具的读写会受影响。Linux下类似别把SDK放到/usr或/opt下然后纠结权限直接放~/Android/Sdk设置ANDROID_HOME后完全无障碍。既然是开发工具使用者就该有完整的读写控制权这是最舒服的状态。5.5 和Android Studio的SDK目录冲突问题很多人的电脑上既有Android Studio又在折腾命令行SDK。这时要确认你希望ANDROID_HOME指向哪边。如果Android Studio已经自动装了一套SDK理论上可以共用同一套没必要再装第二份。Android Studio的SDK Manager里显示的“Android SDK Location”就是ANDROID_HOME应该指的位置。如果你决定用命令行管理新SDK可以不改动Android Studio自身配置只把ANDROID_HOME环境变量指向新SDK目录。这样的话Android Studio里通过图形界面安装的组件和新命令行装的状态是隔离的。但如果你某个项目打开时用的是Android Studio内置SDK另一些脚本用命令行SDK很容易出现“版本不一致”的怪问题。我的习惯是统一非特殊需求ANDROID_HOME只指一个SDK根目录cmdline-tools和Android Studio共用。这样两边装的东西都落在同一目录树基本不会出幺蛾子。6. 实用总结与我的个人经验把commandlinetools-win-11076708-latest.zip从“一个看不懂的压缩包”变成“顺手好用的SDK管理工具”其实本质就三步解压到cmdline-tools/latest配置好JDK和PATH用sdkmanager装组件。整个过程不复杂但每一步都有细节目录结构、许可协议、网络源都是最常见的绊脚石。我个人的体会是不要嫌命令行麻烦。就算你平时都用Android Studio学会sdkmanager也会让你在排查环境问题、写自动化任务时快人一步。比如同事报“SDK缺了build-tools 30.0.3”你一行sdkmanager build-tools;30.0.3就解决了不用让他打开IDE点点点。最后分享一个我一直在用的小技巧新机器完成SDK安装后立刻执行一次yes | sdkmanager --licenses然后全量安装你项目常用到的所有platform和build-tools版本。因为等你真的要用某个旧版本时再临时装一方面慢另一方面容易因为网络问题卡在一半。提前把许可交了、常用组件装了后续所有构建都能直接从本地读取那种顺手的感觉试一次就知道。本文还有配套的精品资源点击获取