简介：这份压缩包提供Android SDK Tools 26.1.1完整更新，面向Android原生开发及Unity导出安卓项目的人员，解决25.2.5及以下版本的稳定性与兼容性问题；升级后可获得模拟器性能优化、新版API支持、Gradle插件兼容性增强及AndroidX工具链改进。包内共1826个文件，以gif操作演示、jar库、png界面图、css/html说明文档为主，辅以properties配置、xml资源、exe可执行文件等，整体约148.9MB，解压后可直接替换原tools目录。压缩包附带替换说明文本，对旧环境迁移和Unity联动场景有明确提示，适合已有SDK基础、需快速升级工具链的中高级开发者。目前已有2495人学习下载，可用于排查旧版工具异常、同步新构建环境及优化Android应用构建流程。
1. 这个 zip 到底是什么：一条离线装 Android SDK 26 的捷径
当你在搜索android-sdk-26_1_1.zip时，大概率遇到的是两种场景：要么是内网环境里没法在线拉取 SDK，要么是某个镜像站打包好了一份 API 26 的离线压缩包，传到你手里当“后悔药”用。这份 zip 的核心价值很简单：它是把 Android SDK 26（也就是 API 26，对应 Android 8.0）的基础组件提前下载好、压在一起，让没有外网权限的人也能完成本地开发环境的搭建。它能省去你反复敲sdkmanager等待下载的时间，也避免了网络抖动导致下载一半失败还找不到断点续传的尴尬。
但这份 zip 又不是一个“双击下一步”的安装器，它更像是一堆半成品的零件：解压之后需要你手动决定放到哪里、配哪些环境变量、让构建工具认得出它。很多新手在这里翻车，以为解压完就等于装好了，结果一编译就报SDK location not found；老手则可能在跨机器复制时吃了权限和路径的亏。这篇文章会从校验、解压、配置、接入项目到排错，完整走一遍我平时处理这种离线 SDK 包的习惯做法，让你拿到手就能用，而不是对着命令行乱试。
如果你是要在内网搭 CI、给团队统一 SDK 版本、或者只是某个 Android 老项目需要 API 26 的构建环境，这篇文章覆盖的场景应该正好对你胃口。下面直接进入正题。
2. 拿到 zip 别急着解压：校验、看结构、判断适不适合你的项目
2.1 先算哈希：文件没坏，后面才不玄学
我见过太多人解压到一半报“CRC 失败”，第一反应是压缩包坏了，然后重新下载，结果又坏了，最后发现是传输工具截断了文件。与其赌运气，不如在解压前花十秒算一下哈希值。正常来说，给你这份 zip 的人或页面会在旁边标注 SHA-256 校验值；如果没有，至少也问一下来源方要一个。如果两边都拿不到校验值，那就只能退而求其次，用解压软件的“测试压缩包”功能先跑一遍。但那是事后补救，不算是前置校验。
# 在 zip 所在目录执行，把下面的 hash 占位符换成你拿到的 SHA-256 值 echo "你的SHA256值 android-sdk-26_1_1.zip" | sha256sum -c - # 或者直接算当前文件的哈希，然后和官方/来源方提供的比对 sha256sum android-sdk-26_1_1.zipsha256sum -c -的作用是从标准输入读取一个“哈希值 + 文件名”格式的行，然后自动比对当前目录下的文件；如果输出OK，说明文件完整。第二行命令则是直接打印出真实的 SHA-256，方便你人工比对。这两个命令在 Linux 和 macOS 都有，Windows 可以用 PowerShell 的Get-FileHash，但考虑到 Android 开发环境多半是 Linux 的 CI，我习惯用这个。
有些内网系统会给不了校验值，那建议你解压后用unzip -t测试一遍：
unzip -t android-sdk-26_1_1.zip-t会遍历 zip 内每个文件做 CRC 校验，结尾出现No errors detected in compressed data就代表解压本身没问题。这一步能过滤掉大部分“文件损坏”玄学。
2.2 解压后目录结构：platforms、build-tools、platform-tools 各管什么
解压这份 zip 之后，你会看到一个标准的 Android SDK 目录壳子。最常见的几个子目录需要先认清楚，因为后面配置环境变量和排查错误都要用到它们。我直接用表格列出来：
| 目录名 | 作用 | 什么时候必须存在 |
|---|---|---|
platforms/android-26 | 存放 API 26 的 android.jar，编译和运行时引用 | 需要编译 targetSdk 26 的项目时 |
build-tools/26.x.x | 包含 aapt2、d8、zipalign 等构建工具 | 所有 Android 构建都必须要，且版本要和 Gradle 匹配 |
platform-tools | 包含 adb、fastboot、sqlite3 等调试工具 | 只要连接设备或执行 adb 命令就需要 |
cmdline-tools | 包含 sdkmanager、avdmanager，用于后续管理组件 | 想补装缺失组件、创建模拟器时 |
system-images/android-26 | 模拟器用的系统镜像 | 只有要开 AVD 模拟器时才需要 |
tools | 旧版的 SDK 管理器等工具 | 新版可能已经迁移到cmdline-tools |
有些压缩包会把cmdline-tools也打进去，有些则没有。如果解压后只有platforms和build-tools而缺少platform-tools，那说明打包者只考虑编译，没考虑调试。对于这种情况，你在后面用 sdkmanager 补装即可，不用慌。
另外，注意build-tools目录下的版本号。API 26 对应的构建工具常用版本是 26.0.0、26.0.1、26.0.2，但你要看 zip 里实际提供的是哪个。版本号直接决定 AGP（Android Gradle Plugin）是否认账，后面第 4 节会专门讲这个坑。
2.3 三个关键判断：能不能用，全看这三条
在动手安装之前，先花两分钟做三个判断，能帮你省掉后面好几个小时。第一个判断是你的项目到底需要哪个 API 级别。android-sdk-26_1_1.zip里面装的是 API 26，也就是 Android 8.0。如果你的项目是compileSdk 34，那这份包根本不够用，你还需要额外下载 API 34 的 platform。这不是 zip 本身的问题，而是你选择的使用场景不匹配。
第二个判断是 build-tools 版本是否和 Gradle 插件版本兼容。一般 AGP 3.x 对应 build-tools 26~30，AGP 7.x 则可能要 build-tools 30+。如果你拿这份 zip 去跑一个 AGP 8.x 的项目，大概率会卡在Failed to find Build Tools revision。所以在解压前先看一眼项目build.gradle里的buildToolsVersion，如果写死了 26.0.2，那这份 zip 就正好对口；如果写的 30.0.3，建议直接去在线装新的。
第三个判断是你需不需要 system-image。如果你只是打 apk，那么 zip 里有没有system-images根本无所谓；但如果你想建 AVD 模拟器跑 App，没有 system-image 就是白搭。我见过有人用这类离线包装完，发现模拟器起不来，查了半天才发现少了镜像。这个判断就是这么简单：需要模拟器的话，先确认 zip 里有没有system-images/android-26，没有就做好补装准备。
3. 从 zip 到可用的 SDK：安装、环境变量与项目接入
3.1 最小一步：解压到目标目录，跑通 adb
拿到确认完好的 zip，现在开始真正落地。先选一个安装目录。Linux 环境下我习惯放在/opt/android-sdk，macOS 用~/Library/Android/sdk，Windows 则放在不带空格和中文的路径下，比如C:\Android\sdk。命名里不要带空格，不然后续很多脚本分隔符会把路径切碎，这是第一层血泪教训。
# 以 Linux 为例，目标目录选 /opt/android-sdk sudo mkdir -p /opt/android-sdk sudo chown -R 你的用户名:你的用户组 /opt/android-sdk # 解压，保留顶层目录 unzip -q android-sdk-26_1_1.zip -d /opt/android-sdk/ ls /opt/android-sdk/一般这种 zip 在打包时会带一个顶层文件夹，比如android-sdk-26_1_1，解压后你会看到/opt/android-sdk/android-sdk-26_1_1/，里面才是platforms等子目录。如果你希望 SDK 直接放在/opt/android-sdk下而不是多套一层，可以解压后把内容移动一下：
cd /opt/android-sdk mv android-sdk-26_1_1/* . mv android-sdk-26_1_1/.gitignore . 2>/dev/null || true rmdir android-sdk-26_1_1移动后确认platforms、build-tools、platform-tools直接在/opt/android-sdk下一层。这样做的原因是很多工具会直接拿ANDROID_HOME去寻找platform-tools，如果多一层目录，要么你的环境变量指向内层，要么后续配置还得再改一次。我习惯直接铺平，省得日后搞得像俄罗斯套娃。
解压本身没有太多参数需要解释，-q是安静模式，避免一屏刷不完的文件列表。-d是指定解压目标目录，这样不管 zip 内是否包含顶层目录，都会先放到目标目录里。
3.2 环境变量：ANDROID_HOME 与 PATH 一个都不能少
很多人的“装好了”其实只是解压了，紧接着就在终端输入adb version，然后得到command not found。为什么？因为 shell 压根不知道去哪里找这些二进制。所以环境变量必须配，而且要配到 shell 的启动文件里，否则你每次新开终端都要重新 export 一次，那不是人过的日子。
# 编辑 ~/.bashrc，或者 ~/.zshrc echo 'export ANDROID_HOME=/opt/android-sdk' >> ~/.bashrc echo 'export ANDROID_SDK_ROOT=/opt/android-sdk' >> ~/.bashrc echo 'export PATH=$ANDROID_HOME/platform-tools:$ANDROID_HOME/cmdline-tools/latest/bin:$PATH' >> ~/.bashrc source ~/.bashrc三个变量各管什么事要说清楚。ANDROID_HOME是老牌变量，几乎所有 Gradle、Flutter、React Native 工具树都会读它。ANDROID_SDK_ROOT是 Android Studio 与部分新版命令行工具的补充变量，两者最好都指向同一个目录，避免有些工具读一个、另一些读另一个，结果路径不一致。PATH里要包含platform-tools和cmdline-tools/latest/bin，前者为了adb、fastboot，后者为了sdkmanager、avdmanager。注意我这里假设解压后cmdline-tools被重命名或放置成latest目录，实际要看 zip 内部结构；如果只有cmdline-tools没有latest，你需要自己建目录结构，后面 3.3 会提到。
配完后验证一把：
adb version sdkmanager --version第一条能输出版本，说明 adb 已经可用；第二条能出版本，说明命令行工具链可用。如果sdkmanager报错，多半是cmdline-tools目录结构不对，这是个高频坑，等下避坑章节讲。
3.3 用 sdkmanager 把离线包转正：识别、补全、维持后续更新
离线包最大的问题是它是一次性的，如果项目里还有其他依赖组件没被打进来，你就需要 sdkmanager 帮忙补。但 sdkmanager 又需要网络源，这就有了“鸡生蛋”的问题。解决办法是把离线包当作 SDK 的根目录，用--sdk_root显式告诉 sdkmanager“我现在用的 SDK 在这个位置”，然后让它把缺失的组件当作增量下载补上。
# 先确认 sdkmanager 在哪个位置 find /opt/android-sdk -name sdkmanager -type f # 如果发现 cmdline-tools 的目录不是 latest，先调整： mkdir -p /opt/android-sdk/cmdline-tools/latest mv /opt/android-sdk/cmdline-tools/bin /opt/android-sdk/cmdline-tools/latest/bin mv /opt/android-sdk/cmdline-tools/lib /opt/android-sdk/cmdline-tools/latest/lib这段调整是网上很多人没说透的。新版sdkmanager要求它的路径必须遵循cmdline-tools/latest/bin，否则就算文件在，也会报The sdkmanager was not found at the expected location。调整完再执行：
sdkmanager --sdk_root=/opt/android-sdk --list sdkmanager --sdk_root=/opt/android-sdk "build-tools;26.0.2"--list会列出当前 SDK 里已安装和可更新的组件，同时也会显示远程仓库里的新版本。第二行命令则会安装指定的 build-tools 版本。这里的--sdk_root参数很关键，它直接让 sdkmanager 把/opt/android-sdk当作它的工作目录，避免默认跑到~/Library/Android之类的系统默认路径去。
如果你完全内网，没有任何外网仓库可以访问，那--list会卡住或报错。这种情况请直接跳过 sdkmanager 联网操作，把你所有需要的组件都从别处的完整 SDK 目录里拷贝过来，放到对应子目录下。常见做法是找一台已经配好的开发机，把platforms、build-tools、platform-tools整个 rsync 过来。反正你们是一个内网，网络传输 zip 不会像外网那样容易被打断。
3.4 写进项目：让 Gradle 找到你的 SDK
SDK 装好、环境变量设好，最后一步是让项目构建工具认账。Android Gradle 插件定位 SDK 有两个途径：一个是读local.properties文件里的sdk.dir，另一个是环境变量ANDROID_HOME。两个都设一下最稳妥，因为 IDE 和命令行工具有时候逻辑不一样。
# 在项目根目录下，如果不存在 local.properties 则新建 echo 'sdk.dir=/opt/android-sdk' > local.properties然后重新执行 Gradle 构建，比如./gradlew assembleDebug。如果你用的compileSdk是 26，buildToolsVersion是 26.0.2，那么构建会直接通过。如果项目较大，可能还要检查 JDK 版本、AGP 版本，但那些就不是这份 zip 能解决的了。
这里我要特别说明一个常见误区：local.properties里的sdk.dir不能写~这种 shell 展开符，也不能加引号，必须是绝对路径。我见过有人写sdk.dir=~\Android\sdk，结果 Gradle 把这个当相对路径处理，跑去项目目录下找~/Android/sdk，直接报错。所以路径就老老实实写绝对路径，别偷懒。
4. 避坑与排查：装完跑不起来的典型案例
4.1 adb 明明在目录里，却 command not found
现象：ls /opt/android-sdk/platform-tools/adb能看到 adb 存在，但终端执行adb version却提示command not found。
原因：PATH环境变量没有重新加载，或者export写进了一个不会在交互 shell 中生效的文件。如果你改的是/etc/profile但没重启会话，新开的终端不一定继承；如果你在.bashrc里写错了变量名，比如ANDROID_HOME少了后缀，那 PATH 里引用的路径就是错的。
解决：先打印当前 PATH，看里面有没有/opt/android-sdk/platform-tools：
echo $PATH | tr ':' '\n' | grep android如果没有，重新检查.bashrc里的export行，然后用source ~/.bashrc重载，最后再试。我有一次犯的错是把 export 写在了if [[ $- == *i* ]]判断外面，结果非交互 shell 读到，交互 shell 反而没读到，卡了半天。所以排查时就老老实实打印$PATH，比瞎猜快得多。
4.2 日志说 SDK 找不到，路径却写对了
现象：local.properties里明明写了sdk.dir=/opt/android-sdk，Gradle 还是报SDK location not found. Define location with an sdk.dir in the local.properties file or with an ANDROID_HOME environment variable.
原因：大概率是sdk.dir指向的目录下缺少必要的子目录或文件。Gradle 判断一个目录是否算 SDK，不是看它是不是非空，而是看它是否存在platforms/android-XX或build-tools等特征目录。如果你解压时把结构搞乱了，比如多套了一层，或者platforms目录下没有android-26，Gradle 就不认。
解决：验证目录结构：
ls /opt/android-sdk ls /opt/android-sdk/platforms ls /opt/android-sdk/build-tools确保platforms下有个android-26目录。如果没有，用 sdkmanager 补装，或者把解压后多出来的那层目录挪正。注意 Gradle 对sdk.dir指向的目录必须是 SDK 根，而不是 SDK 内部的某个子目录。
4.3 build-tools 版本不对，AGP 当场翻车
现象：构建时报错Failed to find Build Tools revision 26.0.2，但ls /opt/android-sdk/build-tools显示明明有26.0.2文件夹。
原因：最常见的是 build-tools 目录里的版本号文件夹名和 Gradle 要求的不完全一致。比如你解压出来的是26.0.0，但项目写的是26.0.2；或者文件夹存在，但里面缺了aapt2或d8等关键可执行文件。另一种可能是 Gradle 客户端和 SDK 不在同一个文件系统，符号链接导致的误判。
解决：进入build-tools目录实际看文件名，确认版本号，然后在项目的build.gradle里显式指定buildToolsVersion，或者直接修改 Gradle 要求的版本号。如果你确实想要 26.0.2，但离线包里只有 26.0.0，那就只能尝试从其他地方复制 26.0.2 的完整目录过来，别试图改目录名蒙混过关，内部二进制对不上一样会崩。
4.4 解压报文件损坏，但压缩包真的没坏
现象：unzip解压到某个文件时报invalid compressed data to inflate，但用unzip -t测试却显示No errors。
原因：很可能不是压缩包损坏，而是磁盘空间不足、权限不足，或者解压过程中被杀毒软件/安全策略拦截。Linux 下的unzip -q遇到无法创建文件时会跳过，但不会主动提示，很容易被误解为数据损坏。还有一种玄学：老版本的 unzip 对 zip64 大文件支持不全，解压超过 4GB 的包会出错。
解决：先用df -h .看磁盘剩余；接着用sudo unzip提升权限；最后如果还是报错，试着换jar xf或python3 -m zipfile -e来解压，能绕开 unzip 的旧版本 bug。我的一次实际经历是，某内网服务器上的 unzip 是 20 年前的版本，换成7z x后一分钟解压完毕，之前却反复报“损坏”。
4.5 做模拟器才发现没有 system-image
现象：SDK 装完，adb和编译都正常，但avdmanager create avd创建成功后，启动模拟器时报ERROR: No system images installed for this target.
原因：离线包打包者只打入了编译所需的组件，没有包含system-images/android-26。这是最常见的删减策略，因为模拟器镜像动辄几百 MB，打包时为了控制体积往往就不带。
解决：如果你确实要跑模拟器，单独补装镜像。在有网环境下执行：
sdkmanager --sdk_root=/opt/android-sdk "system-images;android-26;google_apis;x86_64"装完后再创建 AVD。如果完全没网，只能从另一台机器上拷贝整个system-images目录到/opt/android-sdk/system-images。特别提醒，模拟器镜像必须和 AVD 的target、tag、abi完全匹配，否则模拟器会报The system image is missing。这一点没有工作中踩过很难想到，属于黑匣子里的黑匣子。
5. 装好之后的进阶：把这份离线 SDK 的价值榨干
5.1 用 sdkmanager --list 验证组件完整性
安装完成不是结束，至少要做一次完整性验证。写一个简单的检查命令，把关键组件是否存在打在输出里：
sdkmanager --sdk_root=/opt/android-sdk --list_installed--list_installed只列出本地已安装的包，不访问网络，非常适合离线环境做快速确认。你可以看到platforms;android-26、build-tools;26.0.2、platform-tools等条目。如果某一行缺失，就回到第 3 节补装。这个命令比ls更靠谱，因为它读取的是 SDK 内部的包元数据，能够识别那些“文件夹存在但注册不完整”的假安装。
5.2 写一个 5 秒钟的环境自检脚本
下次换机器或者同事问你怎么确认 SDK 是否可用，别让他手动敲一堆命令。把它写成一个脚本放到~/check-android-sdk.sh：
#!/bin/bash set -e [ -d "$ANDROID_HOME/platforms/android-26" ] || { echo "API 26 platform missing"; exit 1; } [ -d "$ANDROID_HOME/build-tools/26.0.2" ] || { echo "build-tools missing"; exit 1; } command -v adb >/dev/null || { echo "adb not in PATH"; exit 1; } echo "SDK OK: $ANDROID_HOME"脚本里的set -e让任何失败直接终止，后面三个检查分别验证 platform、build-tools 和 adb。执行chmod +x后，每次新环境打开终端跑一下，心里就有底了。我还习惯在这个脚本里加上java -version和gradle -v的前置检查，因为很多时候 SDK 没问题，问题出在 JDK 版本匹配上。
5.3 把离线包变成团队共享的本地源
如果你的团队都在同一内网，与其每个人拿同一个 zip 解压，不如把它解压到一个统一目录，然后用ANDROID_HOME集中指向它。但更省事的做法是把它做成一个只读的共享目录，配合 sdkmanager 使用。你可以用 NFS、Samba，或者直接放在一台 CI 服务器上，让每个开发者通过符号链接ln -s /mnt/android-sdk $HOME/android-sdk引用。这样能保证所有人的 build-tools 版本完全一致，避免“我这边能编译”而“你那边报版本错误”的典型内耗。
我记得有一次在某公司，团队几十个人各自用自己下载的 SDK，结果某天统一升级 build-tools 后，一半人构建失败，原因就是新旧版本混用。后来我们直接把共享目录设为唯一事实源，所有项目在local.properties里写死sdk.dir=/mnt/android-sdk，之后再也没出现过 SDK 版本不一致的幺蛾子。这就是把一份离线包价值最大化的方式：它不是给你一个人救急用的，而是能变成团队基建。
所以，如果你现在手里有这份 zip，别急着删，先把它放到一个稳定的位置、配好环境变量、写进自检脚本，然后告诉同事“这个能省事”。我吃过太多“临时下载”的亏，最后都是自己保留一份本地离线包才睡得着觉。希望这个流程能帮到你，少走点我走过的弯路。
本文还有配套的精品资源，点击获取
