Unity 打包 APK：Android SDK Tools 26.1.1 配置

简介：AndroidSDKTools26.1.1 压缩包面向使用 Unity 2018/2019 打包安卓 APK 的开发者，重点解决旧版工具版本兼容与配置繁琐的问题，也适合需要稳定构建环境、排查打包链路的移动开发学习者，以及讲授旧版构建流程的教学场景和需要复现旧环境的团队。包内共 1828 个文件，约 146.29MB，以 jar 库、xml 与 html 页面、png 截图及 exe、bat 脚本等为主，覆盖工具程序、许可说明与文档资源，目录体量完整，便于按组件查找内容并减少环境搭建阻力。内容围绕工具管理、设备调试与包体优化等核心能力展开，可辅助理解安卓平台组件、安装测试和版本兼容之间的关系，适合对照检查工具路径、组件缺失和报错原因并提升排错效率。已有 2833 人学习，也可作为旧项目维护、打包环境复现与团队内部培训的参考资料。

1. Android SDK Tools 26.1.1 是什么：Unity 打包 APK 的底层支撑，而不是完整 SDK

多人协作的 Unity 工程里，经常出现这类情况：代码在本地能跑，一到打包就弹Android SDK not found，或者sdkmanager窗口闪一下就消失，日志里只剩一行java.lang.NoClassDefFoundError。此时缺的往往不是整个 SDK，而是一个能用的 Android 命令行工具集。AndroidSDKTools26.1.1.rar 解开的正是这套工具，里面是sdkmanager、avdmanager、adb、aapt以及一批批处理脚本，处在 Unity3D 打包 apk 流程的最底层。它并不完整：platform-tools、build-tools、platforms都要靠它自己拉取。这个包适合仍维护老版本 Unity 工程、需要离线或半离线搭一套可控 Android 环境的人。

2. 解压后的目录与三条必通命令：把 sdkmanager 跑起来

拿到压缩包后第一件事往往容易做错：很多人直接解压到C:\Program Files\Android\sdk，然后在 Unity 里填路径，结果后面每一步都报错。原因是这个包里只有tools，它是个“安装器外壳”，真正的adb、aapt2、android.jar都不在里面。先弄清目录结构，再决定放哪儿。

2.1 目录布局：tools 只是外壳，platform-tools 和 build-tools 要自己装

解压后能看到的核心目录只有tools，其下是bin、lib、source.properties。bin里放着 Windows 的.bat和类 Unix 的 shell 脚本，sdkmanager、avdmanager、sdkmanager.bat都在这里；source.properties记录了这套工具的版本号，26.1.1 就是从这儿读出来的。剩下那些platform-tools、build-tools、platforms、extras、ndk-bundle目录，解压出来是空的，或者干脆不存在。原因很直接：26.x 时代的 SDK Tools 发布包只分发工具本体，组件全部走远程仓库拉取。

这就决定了安装位置的两条硬性限制。第一条，路径不能带非 ASCII 字符和空格，老版本aapt和 Gradle 的路径解析在这方面有历史问题，一旦带空格就会在链接阶段报找不到文件。第二条，路径要短，Windows 的 260 字符限制在 Gradle 缓存和 NDK 目录叠加时很容易触发。我一般会放在D:\android-sdk这类位置，把整个 SDK 根目录当成一个可以随时删掉重来的目录，不要和系统盘里的其他工具混在一起。

放好之后确认一下 Windows 下的关键文件：tools\bin\sdkmanager.bat、tools\bin\avdmanager.bat。如果这两个文件不在，或者被杀毒软件隔离了，后面所有步骤都无从谈起。

2.2 JAVA_HOME 与 ANDROID_HOME：两个变量决定 sdkmanager 能不能启动

sdkmanager本身是个 Java 程序，启动脚本会去读JAVA_HOME。26.1.1 这一代工具编译时用的是 JDK 8 的类库，所以JAVA_HOME必须指向 JDK 8。如果指向 JDK 11 或更高版本，启动时会直接抛NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema，因为 JAXB 在 Java 11 里已经从标准库移除。有血泪教训的是：机器上装了多个 JDK 时，PATH里java -version显示的是 8，但JAVA_HOME指向 17，一样报错，脚本认的是后者。

ANDROID_HOME指向刚解压的 SDK 根目录，也就是tools的上一级。新老 Unity 对这个变量的读取顺序有差异，老版本认ANDROID_HOME，新版本优先ANDROID_SDK_ROOT。两个都设成同一个值最省事，但千万别设成两个不同的路径，否则 Unity 和 Gradle 会各读各的，出现“编辑器里显示 SDK 正常、打包时却说找不到”的玄学现象。

# Windows 命令行临时生效，验证用 set JAVA_HOME=D:\jdk8 set ANDROID_HOME=D:\android-sdk set ANDROID_SDK_ROOT=%ANDROID_HOME% set PATH=%JAVA_HOME%\bin;%ANDROID_HOME%\tools\bin;%ANDROID_HOME%\platform-tools;%PATH% java -version sdkmanager --version

# macOS / Linux，写进 ~/.bashrc 或 ~/.zshrc 才是永久的 export JAVA_HOME=/opt/jdk8 export ANDROID_HOME=/opt/android-sdk export ANDROID_SDK_ROOT=$ANDROID_HOME export PATH=$JAVA_HOME/bin:$ANDROID_HOME/tools/bin:$ANDROID_HOME/platform-tools:$PATH

参数说明只有三点：JAVA_HOME必须是 JDK 8 的根目录而不是bin；ANDROID_HOME必须是tools的上一级；PATH里tools\bin要排在前面，否则机器上如果另装过一个新版 SDK，sdkmanager命令可能被解析到别的版本上去。验证成功的标志是sdkmanager --version输出版本号而不是一堆堆栈。

2.3 sdkmanager 装组件与 licenses 落地

变量通了之后，第一件事不是急着装组件，而是先看一眼仓库能不能连上。sdkmanager --list会输出已安装和可安装的组件清单；如果卡住不动或者报 SSL 相关错误，多半是网络层的问题，此时不要反复重试，先确认代理设置和证书链是否正常。我一般会先跑--list确认能拿到远端清单，再执行安装。

# 指定 sdk_root，避免 sdkmanager 猜错安装位置 sdkmanager --sdk_root=D:/android-sdk --list # 安装最小可用组合：平台工具 + 一个 build-tools + 一个 platform sdkmanager --sdk_root=D:/android-sdk "platform-tools" "build-tools;26.0.1" "platforms;android-26" # 接受许可，交互式逐条回车 sdkmanager --sdk_root=D:/android-sdk --licenses

--sdk_root这个参数值得单独说：不加它的时候，sdkmanager会根据自身所在路径往上推断 SDK 根目录。如果你把tools单独拷出来放在别处，推断就会错位，组件被装到一个谁也找不到的目录里。加上它等于显式告诉工具“根目录在这儿”，是离线分发场景下最稳的做法。

--licenses会在 SDK 根目录下生成licenses文件夹，里面是几个文本文件，内容是对应许可证的哈希值。Unity 打包时会检查这些文件，缺了就卡在license not accepted。无交互环境（比如自动化脚本里）可以用管道批量确认：

# Linux / macOS yes | sdkmanager --sdk_root=/opt/android-sdk --licenses # Windows 命令行的等价写法 for /l %i in (1,1,30) do echo y| sdkmanager --sdk_root=D:/android-sdk --licenses

装完立刻验证三个命令：adb version、aapt version（在build-tools/<版本>目录下）、sdkmanager --list_installed。三个都出信息，说明这套底座立住了，可以往 Unity 里接。

3. 版本搭配：build-tools、platforms、JDK 与 Unity 版本怎么对上

这套工具之所以还有人在用，很大原因是它能装到一些新版sdkmanager已经下架的组件。但这个优势只在一件事成立时才有意义：版本之间必须搭配正确。Unity 打包 APK 报的错里，有一半以上是版本错配，而不是功能缺失。

3.1 为什么 26.1.1 的 sdkmanager 反而是优势

从 25.3.0 开始，android命令被sdkmanager取代，26.x 是这套新命令行的早期稳定版本。它的优势有两个。第一，命令行接口简单，sdkmanager "包名;版本"这种写法没有后来那些--channel、--include_obsolete的额外概念，脚本里好写。第二，也是更实用的，它还能拉到ndk-bundle——新版 SDK 仓库早已把这个包移除，只保留独立分发的 NDK 压缩包。对于还在用老版本 Unity 的工程，ndk-bundle目录结构是硬编码期待的，装不上就只能在 Unity 里手工指一个 NDK 路径，容易出岔子。

代价也要说清楚：26.1.1 不认识后来新增的仓库元数据格式，某些镜像源的清单它解析不了，--list可能只显示一部分组件。这不是包坏了，是年代差异。遇到这种情况，换回官方源或者改用离线 zip 手工解压到对应目录，都比硬折腾sdkmanager快。

3.2 用 sdkmanager 装一套最小可用组合

Unity 打包 APK 对 SDK 的需求其实很小：platform-tools（提供 adb，安装和调试用）、一个build-tools（提供 aapt、zipalign、apksigner）、一个platforms（提供android.jar编译期依赖）。三个组件版本之间要能对上，platforms;android-26配build-tools;26.0.1是同一代，platforms;android-28配build-tools;28.0.3是同一代。跨代混用不是绝对不行，但编译期常量对不上时会报cannot find symbol，这类错误查起来很费时间。

我一般按 Unity 版本倒推装哪一代，下面这张表是这些年反复验证过的常见搭配，不是官方推荐表，是按实际能跑通整理出来的：

安装命令是幂等的，重复执行只会提示 already installed，不会把已有组件弄坏：

# 装第二代组合（对应 2018.4 那档） sdkmanager --sdk_root=D:/android-sdk "platform-tools" "build-tools;28.0.3" "platforms;android-28" # 装完核对 sdkmanager --sdk_root=D:/android-sdk --list_installed

参数上只有一个坑：包名里的分号在 Windows 命令行下要加引号，build-tools;28.0.3不加引号会被 cmd 当成命令分隔符，结果只装了build-tools，版本参数被丢掉，装出来的东西根本不是你要的。

3.3 NDK：老源能装、新源装不上的那一块

Unity 里勾了 IL2CPP 或者工程里有原生插件时，NDK 就是必需品。sdkmanager装 NDK 的写法是：

sdkmanager --sdk_root=D:/android-sdk "ndk-bundle"

装完之后目录是<sdk>/ndk-bundle，这个固定名字很关键，很多老工程和构建脚本默认就是这个路径。如果换用新版独立分发的 NDK 压缩包，解压出来的目录名会带版本号（比如android-ndk-r19c），此时要么在 Unity 的 External Tools 里手工指路径，要么把它改名为ndk-bundle放到 SDK 根目录下。

还有一个隐蔽问题：NDK 解压后如果没有执行权限，Linux 和 macOS 上会在链接阶段报Permission denied。执行chmod -R +x <ndk>/就能解决，但报错信息完全不会提示这一层，容易被误判成工程配置问题。

4. 接进 Unity：External Tools 三路径与 Player Settings 对齐

组件装齐只是准备阶段，真正决定能不能打出包的是 Unity 这边的三个路径和四项设置。这一步做错，前面所有工作都白费。

4.1 Preferences 里填哪三个路径

Unity 的 Android 相关路径集中在 External Tools 面板，三个输入框分别是 SDK、JDK、NDK。填法上有几个细节。

SDK 填的是 SDK 根目录，也就是包含tools、platform-tools、build-tools的那一层，不是tools本身。这是最常见的填错点，填成tools之后 Unity 会报找不到platform-tools。

JDK 填 JDK 8 的根目录，不是bin，也不是jre子目录。有些 JDK 发行版自带一个jre子目录，样子很像但缺编译工具（javac），填进去会在编译 Java 源码那一步报找不到编译器。

NDK 在不需要 IL2CPP 和原生插件时可以留空。留空不影响 Mono 后端的打包，但会在切换脚本后端时提示缺失。

Windows 下路径分隔符反斜杠和正斜杠都能填，但我习惯统一用正斜杠，因为同一个工程在 macOS 上打开时，反斜杠路径会直接失效，而工程设置是跟着仓库走的。

4.2 Player Settings 里跟 SDK 强相关的四项

打开 Player Settings 的 Android 分页，前四项设置必须和已安装组件对上：

Minimum API Level和Target API Level决定用哪个android.jar编译。Target 设成 28，就必须装了platforms;android-28，否则 Unity 会直接报Target SDK version not installed，而且这个报错在构建队列里才出现，编辑器界面不提示。

Scripting Backend选 Mono 还是 IL2CPP，直接决定要不要 NDK。Mono 快，适合调试；IL2CPP 是上架要求，编译慢且依赖 NDK。

Build System有 Internal 和 Gradle 两个选项。Internal 是老版本 Unity 自带的一套打包流程，不依赖 Gradle 和 build-tools；Gradle 则要求build-tools版本和 Unity 内置的 Gradle 模板匹配。选 Internal 能绕开很多 SDK 版本问题，但无法处理自定义 AndroidManifest 合并、多 ABI 分包这些需求，实际项目里迟早要切到 Gradle。

Target Architectures勾选 arm64-v8a 之后，如果 NDK 缺失会立刻报错，这个组合排查起来最快。

4.3 Gradle 模板与 build-tools 的搭配验证

切到 Gradle 之后，Unity 会用工程里的mainTemplate.gradle和内置的 Gradle 版本去构建。build-tools版本不匹配的典型症状是：编辑器里一切正常，点 Build 之后进度条走到一半，控制台丢出一段 Gradle 日志，关键行是Failed to find build-tools version 28.0.3或者aapt2相关的com.android.tools.build:gradle版本冲突。

我一般会在切 Gradle 之前先手工跑一次构建验证，把问题暴露在命令行里而不是 Unity 的黑匣子里：

# 假设工程已导出为 Android Gradle 工程，在工程根目录执行 cd Build/android-project ./gradlew assembleDebug --stacktrace --info 2>&1 | tee gradle-build.log # 只看失败原因 grep -n -i "failed\|error\|not found" gradle-build.log | head -n 30

--stacktrace会打出完整调用链，虽然长，但版本冲突的信息只在这一层才看得见；--info会输出实际使用的 build-tools 路径，直接告诉你 Gradle 挑中了哪个版本。tee是为了留档，因为 Unity 的控制台窗口会截断长日志，很多关键行在编辑器里根本看不到。

这一步跑通之后再回 Unity 点 Build，成功率会高很多。如果命令行能过、Unity 过不了，问题基本就锁定在 Unity 侧的路径配置，而不是 SDK 本身。

5. 避坑：Unity 打包 APK 卡在 SDK 上的五个现场

这些都是我在不同机器、不同工程上反复遇到的，记录下来省得下次再从头查。

5.1 sdkmanager 窗口一闪而过，日志里是 NoClassDefFoundError

现象：双击sdkmanager.bat，黑窗口闪一下消失；命令行里执行，抛出一长串异常，关键行是java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema。

原因：JAVA_HOME指向了 JDK 11 或更高版本。JAXB 在 Java 11 里被移出标准库，26.1.1 的代码还在用这个包。注意机器上装多个 JDK 时，PATH里的java和JAVA_HOME可能指向不同的 JDK，脚本只认后者。

解决：把JAVA_HOME显式改成 JDK 8 的根目录，新开一个终端窗口重试（旧窗口的环境变量不会刷新）。工程如果同时需要高版本 JDK 做别的，就在打包脚本里局部设置JAVA_HOME，别改全局。

5.2 路径带非 ASCII 字符或空格，链接阶段报找不到文件

现象：编译通过，链接阶段报error: unable to open file或者aapt.exe相关的路径错误，报错里给出的路径看着就是对的。

原因：老版本aapt和 Gradle 对路径里的空格、非 ASCII 字符处理不完整，尤其中间产物目录会做一次路径拼接，拼出来的路径被截断或者转义错误。这类报错信息极具误导性，因为它显示的是拼接前的路径。

解决：SDK 根目录、JDK 目录、Unity 工程目录三者全部放在纯 ASCII、无空格的短路径下，比如D:\android-sdk、D:\jdk8、D:\proj\game。工程已经在长路径下的，可以先把工程复制到短路径验证一次，确认是路径问题再决定是否迁移。

5.3 只装了 tools，Unity 报 Android SDK is missing

现象：External Tools 里已经填了 SDK 路径，Unity 仍然提示 SDK 缺失，或者提示Unable to locate adb。

原因：解压出来的包里只有tools，platform-tools是空的，adb根本不存在。Unity 的检测逻辑里，adb是判断 SDK 是否可用的标志之一。

解决：sdkmanager "platform-tools"装上，然后确认<sdk>/platform-tools/adb.exe存在且能执行adb version。装完不需要重启 Unity，但需要在 External Tools 面板里重新点一次路径选择框让它重新探测。

5.4 构建到一半卡在 license not accepted

现象：构建进度卡在Checking Android SDK licenses，或者报You have not accepted the license agreements。

原因：licenses目录不存在，或者里面的哈希文件不完整。全新解压的 SDK 一定没有这个目录。

解决：跑一次sdkmanager --licenses并逐条确认。无交互环境下用管道批量确认（见 2.3）。确认完检查<sdk>/licenses/下是否生成文件，空目录等于没接受。CI 场景下更稳的做法是把已接受许可的licenses目录随 SDK 一起打进镜像，而不是每次构建都跑一遍交互命令。

5.5 Target API Level 与已装 platforms 不一致

现象：点 Build 后立刻失败，报Target SDK version not installed或者Failed to find target with hash string android-29。

原因：Player Settings 里的 Target API Level 指向了没装的 platform。这个设置容易被忽略，因为它藏在 Player Settings 的二级面板里，而且编辑器不会在设置时校验。

解决：两者对齐——要么装对应的platforms;android-XX，要么把 Target 改到已装版本。工程是多人协作的，改设置会同步到仓库，所以更稳妥的是补齐组件而不是降版本。改完在 External Tools 里点一下刷新，让 Unity 重新扫描已装 platform 列表。

6. 进阶：用 aapt 与 batchmode 把打包变成可复现流程

真正让打包稳定下来的，不是记住上面那些坑，而是把验证动作固化成命令，让每次出包都有可回查的证据。这一节是我自己出包前必走的两步。

6.1 aapt dump badging 反查产物

APK 打出来之后，不要只看文件大小。aapt dump badging能读出包名、版本号、最低与目标 SDK、支持的 ABI，这几项任何一项不对，装到真机上就是闪退或者装不上。

# Windows，aapt 在 build-tools 对应版本目录下 D:\android-sdk\build-tools\28.0.3\aapt.exe dump badging Build\app.apk | findstr /C:"package" /C:"sdkVersion" /C:"native-code" # macOS / Linux $ANDROID_HOME/build-tools/28.0.3/aapt dump badging Build/app.apk \ | grep -E "package:|sdkVersion|targetSdkVersion|native-code"

package:行给出包名和versionCode、versionName，用来核对发版号是否被 CI 脚本正确注入；sdkVersion和targetSdkVersion用来核对是不是你以为的那一档；native-code列出打进包里的 ABI，缺少arm64-v8a就是 IL2CPP 或 NDK 配置漏了。这一步比在真机上装一遍快得多，我现在是出包脚本里强制加的一行，不通过就不许上传产物。

6.2 Unity batchmode 无头打包

图形界面打包的问题是不可复现——同一份代码，两个人点出来的包可能不一样。把构建逻辑写成编辑器脚本，再用 batchmode 调用，能把整个流程钉死。

using UnityEditor; using UnityEngine; public class BuildScript { // 场景列表按工程实际情况改，顺序即启动顺序 private static readonly string[] Scenes = { "Assets/Scenes/Main.unity" }; public static void BuildAndroid() { string outDir = "Build"; if (!System.IO.Directory.Exists(outDir)) System.IO.Directory.CreateDirectory(outDir); var options = new BuildPlayerOptions { scenes = Scenes, locationPathName = outDir + "/app.apk", target = BuildTarget.Android, options = BuildOptions.None }; // 老版本 Unity 返回错误字符串，空串表示成功 string err = BuildPipeline.BuildPlayer(options); // 用退出码把结果传给外部脚本，CI 靠这个判断成败 EditorApplication.Exit(string.IsNullOrEmpty(err) ? 0 : 1); } }

参数说明：locationPathName是产物路径，相对路径以工程根目录为基准；scenes必须显式列出，batchmode 下不会读取 Build Settings 里保存的场景列表；BuildOptions.None表示不打 Development Build，需要调试符号就换成BuildOptions.Development。如果是 2018.1 之后的版本，返回值可以换成BuildReport，用report.summary.result判断，信息更全。

调用命令是：

# Windows，Unity 可执行文件路径按实际安装位置改 "D:\Unity\Editor\Unity.exe" -quit -batchmode -nographics \ -projectPath "D:\proj\game" \ -executeMethod BuildScript.BuildAndroid \ -logFile "D:\proj\game\build.log" # 检查退出码，0 才算成功 echo %ERRORLEVEL%

-quit让 Unity 在方法执行完后退出，-batchmode关闭交互界面，-nographics在不带显卡的构建机上必需，否则会因为初始化图形设备失败。-logFile指定日志落盘，因为 batchmode 下控制台不输出任何东西，出问题只能靠日志回查。跑完之后接上 6.1 的aapt校验，整个链路就闭环了。

6.3 把版本清单固定下来

最后一步是把当前这套能跑通的版本记录到工程里，写成android-env.txt之类的纯文本，内容包括 JDK 版本、build-tools版本、platforms版本、NDK 版本，以及sdkmanager --list_installed的完整输出。换机器、换人接手、半年后回头查，都是靠这份清单而不是靠记忆。

我吃过一次亏：某次为了试新版本随手把build-tools升上去了，当时能打，一个月后另一个同事拉代码打包，报了一堆aapt2相关错误，查了两天才发现是环境不一致。从那以后我每次配完 SDK 环境，都强制走一遍--list_installed导出清单并提交到仓库，谁改了环境谁更新清单。这套工具本身不复杂，难的是让它在一台新机器上稳定复现，而清单就是那个后悔药。希望帮到你。

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