装 Android Studio 时被一堆 SDK、Platform-Tools、Build-Tools、命令行工具搞得晕头转向，或者打开 SDK 目录看到十几个文件夹不知道该删哪个——这篇就是解决这个场景的。我们不背概念，而是按「它是什么、里面有什么、每个组件负责哪段活、出问题先查谁」的顺序走一遍，让你打开目录就知道自己在看什么。
装 Android Studio 的时候进度条里滚过一串 SDK、Platform-Tools、Build-Tools、Command-line Tools，很多人当场就懵了；等你打开 SDK 安装目录，又看到十几个文件夹，想清个硬盘都不知道从哪个下手。这篇不背概念，就按「它是什么、里面有什么、每块负责哪段活、出问题先查谁」的顺序走一遍。
看完你应该能做到：打开 SDK 目录知道每个文件夹干嘛用、按自己要做的活反推该装哪些包、真机连不上或者编译报错时知道从哪一层开始查。要对照价格或者工具信息，去站内页面看当时的数字。
Android SDK Tools 到底指什么：一套还是一堆
Android SDK Tools 不是某一个单独的 exe，而是「开发安卓应用要用到的整套工具集合」的统称。它包含编译用的接口文件、打包用的工具、跟设备通信的命令行程序、模拟器等等，是一堆组件装在一个目录下的结果。平时大家说「装个 SDK Tools」，语义上其实指的是「把开发安卓需要的那套 SDK 组件装上」。
歧义出在历史上：早些年确实有一个叫 SDK Tools 的管理入口，负责下载和更新其它组件，后来它的活逐步被 Studio 内置的 SDK 管理器和命令行工具接管了。所以你在老教程里看到「Tools」是个按钮，在新版本里可能已经换成别的名字，这也是为什么目录里的文件夹名跟别人嘴里说的名字经常对不上。
- Android SDK
- 整套开发工具集合的总根目录，下面按组件分文件夹
- 早期 SDK Tools
- 曾经负责下载和更新组件的管理入口，功能已被内置管理器和命令行工具分摊
- SDK 管理器
- 现在用来勾选、安装、更新各个组件的界面，Studio 里自带一个
- 组件包
- platform-tools、build-tools、platforms 这些可单独装卸的单元
打开 SDK 目录：几个文件夹分别管什么
打开 SDK 根目录，先认这几个高频文件夹就够了，剩下的多半是它们的附属或者旧版本残留。判断标准很简单：看这个文件夹里的可执行文件名，名字基本能透露它的职责。
| 文件夹 | 主要用途 | 什么时候你会用到它 |
|---|---|---|
| platform-tools | 跟设备、模拟器通信，核心是 adb 这一层 | 真机调试、装包、抓日志、刷机相关操作 |
| build-tools | 把源码和资源加工成能安装的包 | 编译打包，aapt、d8 一类工具住在这里 |
| platforms | 每个安卓版本一套编译用的接口文件 | 你要针对某个安卓版本编译时必须装 |
| cmdline-tools | 纯命令行入口，不依赖图形界面 | 服务器、CI、或者你想脚本化操作时 |
| emulator | 模拟器本体 | 没有真机但要跑起来看效果时 |
- platform-tools 和 build-tools 名字像，职责完全不同：一个对着设备，一个对着代码，装错了不报错但用不上
- platforms 是按版本装的，装了哪个版本才能对着哪个版本编，别指望一个包通吃
- cmdline-tools 不是「精简版」，它是另一条入口，跟图形界面并行存在
- emulator 和系统镜像不是一回事，模拟器装好之后还要单独装镜像才能跑
- 看到名字里带旧版本号、又长期不用的文件夹，先别急着删，先确认没项目引用
快速自查你缺哪个
- 先敲一遍命令行在终端里跑一下 adb 的设备列表命令。能出结果说明 platform-tools 这条路是通的；提示找不到命令，说明路径或者包没配好。
- 再看目标版本确认你要编译的安卓版本对应的接口文件在不在 platforms 里，不在就去 SDK 管理器里勾上再装。
- 最后看打包工具build-tools 里至少留一个可用的版本，项目里声明的和本地装的对不上时，报错一般会直接把版本名写出来。
从零装一遍：走哪几步、装哪些就够
两条路：装完整 Studio，或者只装命令行工具自己拼。判断标准看你要干什么——只是跟着教程跑跑现成项目、改改界面，Studio 一路下一步最省事；想在服务器或者脚本里自动构建，命令行工具更轻。不用纠结哪个更专业，按使用场景选就行。
装哪些包，反过来推：只跑现成项目，需要的是目标版本接口文件加打包工具；要自己编、要连真机调试，再加 platform-tools；要跑模拟器，再加模拟器本体和系统镜像。一上来全勾是最常见的浪费，装完一堆用不上的版本，占空间还容易在版本对齐时添乱。
- 定目标先明确你要编译或运行的安卓版本，这就是你需要装的接口文件版本。
- 装最小集平台接口文件加一个打包工具，先把环境跑起来，能编出包再谈别的。
- 补设备相关需要连真机或者装包调试，再把 platform-tools 配上并加进环境变量。
- 验证命令行能列出设备、项目能编译出包，两条都过就算到位；只有一条过，说明缺的还在另一层。
跟设备相关的那部分：adb 在干什么
adb 干三件高频的事：把电脑和手机连起来、传文件、抓日志。它属于 platform-tools，因为它的活是跟设备对话，跟怎么打包代码没关系。这个归属关系记住之后，以后看到「设备连不上」就不会往打包工具那边查。
- 授权弹窗：手机上没点允许调试，电脑这边怎么折腾都不会出现设备
- 驱动：系统认不出设备时，先在系统设备列表里确认有没有识别成一个可调试设备
- 端口占用：连不上、一连就断，很多时候是别的程序占着通信端口
- 线材和接口：换根线、换个口，能排除掉相当一部分玄学问题
- 多设备同时连：不指定目标设备时，命令可能落到你不想要的那台上
什么情况下模拟器不够用、必须上真机：涉及摄像头、传感器、特定网络环境或者性能表现的时候，模拟器给出的结果和真机差距可能很大。反过来，只是看布局和流程，模拟器完全够，还省得反复插拔。
连上之后的验证顺序
# 先确认工具本身可用
adb version
# 列出当前被识别的设备
adb devices -l
# 设备在线后看日志
adb logcat跟编译打包相关的那部分：为什么换个版本就报错
把 platforms 和 build-tools 分清楚是关键：一个管编译目标（对着哪个安卓版本编），一个管打包动作（用什么工具把代码和资源加工成包）。两者各自有版本，互相不绑定，所以会出现「平台版本对但打包工具太旧」这类报错。
Gradle 里声明的版本和本地实际装的对不上时，报错信息通常会把那个版本名直接写出来，还会提示去装或者去改。看到这种报错别急着改代码，先按名字去 SDK 目录里核对到底装没装。
| 报错里出现的名字 | 先去哪里核对 |
|---|---|
| 平台接口文件相关的名字 | SDK 目录里 platforms 下有没有对应版本 |
| 打包工具相关的名字 | build-tools 下有没有对应版本或者更新版本可用 |
| 构建插件相关的名字 | 不一定是 SDK 的问题，先看项目配置里声明的版本 |
多项目共存时冲突的常见来源：每个项目声明的版本不一样，而你本机只装了其中一部分。对齐顺序建议从旧到新——先保证老项目还能编，再往上加新版本，别为了新项目把老项目依赖的版本删掉。
版本、路径与环境变量：三个最容易踩的坑
- 路径含中文或空格
- 某些工具对这种路径处理不好，可能出现莫名其妙的失败，装之前换成一个纯英文、不带空格的目录最省事
- 只配 platform-tools
- 这样只有 adb 这类命令能全局用，打包相关命令仍然要在 SDK 目录里找，按需决定要不要加
- 装多套 SDK
- 好处是能隔离不同项目和依赖；坏处是环境变量只能指向一个，容易敲出来的命令和项目用的不是同一套
路径这个坑，最典型的失败表现是：图形界面里一切正常，一进命令行就各种找不到或者构建失败。这时候先看环境变量指到哪，再看那个目录是不是你正在用的那套。
多套 SDK 什么时候是好事：需要同时维护差异很大的老项目和新项目、又不想互相污染的时候。什么时候是灾难：你自己都记不清环境变量指向哪套，命令行和 IDE 各用各的，排查半天发现问题根本不在代码上。
想清理或换电脑：哪些能删、哪些别动
按占用空间排，最占地方的通常是系统镜像、模拟器数据和多装的旧版本文件。相对安全的删法是：先删你确定不会再跑的目标平台和对应打包工具版本，删完用项目编译验证一遍；出问题再装回来。别一上来就动 platform-tools。
- 可以优先考虑清的：长期不用的旧版本平台接口文件、对应的旧打包工具、用不到的模拟器系统镜像
- 删之前想一想的：模拟器数据，删了相当于把那个虚拟设备重置
- 尽量别动的：platform-tools，删了 adb 相关操作直接全废
- 删完要重下很久的：系统镜像这类体积大的，网络不好时非常耗时
- 清理的判断标准只有一个：删完之后你的项目还能不能编、设备还能不能连
换电脑时，能直接拷的通常是整个 SDK 目录，但拷过去之后要重新配环境变量和 Studio 里的 SDK 路径；必须重装的一般是跟系统绑定的组件和模拟器里的虚拟设备数据。迁移后项目打不开的典型表现是找不到 SDK 路径或者版本对不上，回退思路就是先在新机器上把缺的组件补装齐，别急着改项目配置。
迁移后的检查清单
- 配路径把 Studio 和命令行指向新机器上的 SDK 目录，确认两边指的是同一套。
- 补缺失组件打开项目，看报错里提到哪个版本，就去补哪个，不要提前批量装。
- 跑一遍验证依次确认命令行能列设备、项目能编出包，两条都过再继续往下开发。
出问题时的排查顺序：从哪一层开始查
固定一条顺序，能省掉大量来回试：先看命令行能不能跑通，再看目标平台版本装没装，再看打包工具版本，最后才怀疑 IDE 配置。顺序的意义在于从底层往上排，底层不通的时候改上层配置都是白费。
- 报错里出现设备、连接、日志这类词，去 platform-tools 那边核对
- 报错里出现平台、接口、目标版本这类词，去 platforms 那边核对
- 报错里出现打包、资源、编译输出这类词，去 build-tools 那边核对
- 报错里出现构建插件、依赖解析这类词，先看项目配置文件而不是 SDK
- 命令行能过、IDE 不过，问题多半在 IDE 的 SDK 路径设置上
有些情况问题根本不在 SDK 本身：网络代理不通导致组件下不下来、镜像源配错导致装的是错的包、目录权限不够导致文件写不进去。这几类如果按 SDK 组件去修，方向就错了——判断方法很简单，如果连下载和安装这一步都失败，先查网络和权限，别查版本。
SDK 的问题大多能靠「这条命令在哪一层跑」定位，定位不清的时候，先问自己现在卡在下载、安装还是使用。下一步站内有各家官方接口的价格与模型资料、中转站可信度检测和价格追踪，装好环境之后要选服务或者比对成本，去那边看当时的数字比凭印象靠谱。→
常见问题
Android SDK Tools 和 Android Studio 是一回事吗？
不是。Studio 是写代码的界面工具，SDK Tools 是它背后干活的那套命令行组件集合。Studio 安装时通常会顺带把 SDK 装好，但你也可以只装命令行那部分，不带界面照样能编译打包。两者是配合关系，不是替代关系。
platform-tools、build-tools、platforms 到底有什么区别？
可以这么记：platform-tools 管跟设备通信（adb 那些），build-tools 管把代码打包成安装包，platforms 里放的是某个安卓版本对应的编译接口文件。一个连设备，一个做打包，一个提供编译目标，三者各管一段，缺哪段都会在对应环节报错。
只做调试不写代码，需要装整套吗？
不需要。如果只是连真机抓日志、装现成的包，装 platform-tools 拿到 adb 通常就够了。涉及自己编代码、调资源、出安装包，才需要 build-tools 和对应版本的 platforms。按实际要做的事反推，比全部勾上更快也更省磁盘。
换电脑之后直接把 SDK 文件夹拷过去能行吗？
部分能，但别指望全对。纯资源类的目录通常可以搬，涉及命令行入口、模拟器镜像和本机路径绑定的部分，换机器后大概率要重装或重新指定路径。搬完之后如果命令跑不起来，优先检查环境变量指向和路径里有没有中文空格。
报错里出现某个工具名，我该去哪找它？
把报错里的工具名跟目录对应一下：命令类的多在 platform-tools 或 cmdline-tools，打包相关多在 build-tools，编译目标相关多在 platforms。先确认这个文件夹在不在、版本对不对，再往上查 Gradle 或 IDE 里的配置声明，顺序别反。
