SDK Tools 26.1.1 与 Unity 老项目 APK 打包排错

简介：面向使用 Unity 2018/2019 打包 Android APK 的开发者，这份 Android SDK Tools 26.1.1 工具包主要解决旧版 Unity 对 SDK 版本兼容性要求高、配置流程偏繁琐的问题，适合需要稳定构建、调试与发布安卓应用的初、中级开发者。压缩包共 1828 个文件、约 146.29MB，包含 jar 库、xml 与 properties 配置、html/css 文档说明、png/jpg/gif 界面素材，以及 bat、exe 等脚本和可执行工具，覆盖 SDK Manager、Adb、Zipalign 等常用组件的运行与说明文件，目录按工具模块组织，便于查找和替换。已有 2833 人学习下载，说明该版本在 Unity 安卓打包场景中仍有较高参考价值。读者可获得一套可直接解压接入 Unity 的 SDK Tools 环境，用于配置 Player Settings、管理平台与构建工具、连接设备调试、优化 APK，并借助随包文档和界面资源排查路径识别、版本匹配等常见问题，减少搭建打包环境时的试错成本。

1. 解压 AndroidSDKTools26.1.1 之后：一套老 SDK 为什么还能撑起 Unity 打包

某个下午，一个做独立游戏的朋友把 Unity 工程发过来，说打包 APK 时卡在最后一步，编辑器弹了个红字就没了下文。工程不算大，场景两个，插件三个，用到的还是几年前的编辑器版本。新装的 SDK 它认不出来，命令行工具又换了几轮目录结构，折腾半天没进展。最后翻出硬盘里躺着的AndroidSDKTools26.1.1.rar，解压、指路径、补一个 JDK，二十分钟出包。

这类场景在 Unity3D 打包 apk 的老项目维护里很常见：编辑器版本不高，构建链路还是aapt + dx + apksigner那一套，配套的 SDK 工具包反而是 26.x 这种“一体化”形态最省事。26.1.1 属于 SDK Tools 还没有被拆成独立命令行包的时期，tools/bin下有sdkmanager、avdmanager，配好platform-tools、build-tools、platforms三块就能跑通整条打包链路。它不新，但对存量工程足够用，适合手上压着老 Unity 项目、又不想为了打一个包去重装整套环境的从业者。

2. 目录与工具分工：26.1.1 里到底哪几个文件夹在干活

解压出来的目录第一眼看上去很散，真正参与打包的其实就四块。先把结构理清楚，后面所有报错定位都能落到具体目录上，不用靠猜。

2.1 解压后的目录布局与包索引

一个装好的 26.1.1 根目录大致是这样：

tools/里没有android这个旧命令，这是 26.x 相对更早版本最明显的变化。很多老教程让你执行android list targets，在 26.1.1 上必然报“命令不存在”，不是环境坏了，是入口换了。

sdkmanager本身是个 Java 程序，tools/bin/sdkmanager只是启动脚本，它读JAVA_HOME找 JVM。这意味着 JDK 没配好时，连--list都跑不出来，报错往往是Error: JAVA_HOME is not set或者一串UnsupportedClassVersionError。

2.2 platform-tools、build-tools、platforms 三者的职责边界

这三块经常被混为一谈，实际职责切得很干净：

platform-tools只管设备和传输。adb devices、adb install、adb logcat都从这里来。它跟 Android 版本基本无关，装上就能用，但版本太老会出现连上新设备识别不到的情况。

build-tools管编译和签名。aapt负责把资源编译进 APK，dx把 class 转成 dex，zipalign做对齐，apksigner做 v1/v2 签名。Unity 打包时调用的就是这一组二进制。同一个 SDK 里可以并存多个 build-tools 版本，Unity 默认挑版本号最高的那个，这也是后面兼容问题的根源之一。

platforms管编译期的 API 契约。android.jar提供android.*的类声明，targetSdkVersion对应的就是这里某个android-XX目录。缺了对应 platform，Gradle 会报Failed to find target with hash string 'android-XX'。

提示：三块可以独立升级。排查时先确认是哪一块缺失，不要一上来就重装整个 SDK，那样只会把已经能用的部分一起弄坏。

2.3 把 26.1.1 接进 Unity 的路径规则

Unity 认 SDK 的方式有两处：编辑器里的 External Tools 面板，以及环境变量。老版本编辑器更依赖面板配置，命令行批处理则依赖环境变量，两边最好保持一致。

路径上有两条硬规则。第一，路径里不能有空格和中文，Program Files、桌面、新建文件夹这类都会让 Gradle 的 shell 调用断在引号处理上，报错信息通常指向某个.gradle脚本行号，跟真实原因完全对不上。第二，SDK 根目录指向的是包含platform-tools的那一层，不是tools，也不是build-tools。

我一般把 SDK 放在一个短路径下，比如D:/sdk/android，然后在系统环境里同时设两个变量：

# 26.1.1 时期的 sdkmanager 读的是 ANDROID_HOME export ANDROID_HOME=D:/sdk/android # 新版工具链读 ANDROID_SDK_ROOT，两个都设可以兼容前后代工具 export ANDROID_SDK_ROOT=D:/sdk/android export PATH=$ANDROID_HOME/tools/bin:$ANDROID_HOME/platform-tools:$PATH

设置完执行sdkmanager --version验证。能打印版本号说明 JVM 和路径都通了；如果报 Java 相关错误，先解决 JDK，别往下走。这一步看着琐碎，但它是后面所有命令的前提，跳过它只会在更靠后的环节以更模糊的形式翻车。

3. 从空目录到第一个 APK：sdkmanager 拉包与 Unity 三件套落地

目录结构清楚了，接下来把一套能出包的最小环境装出来。这一章的命令都可以直接抄，参数按自己工程改。

3.1 JDK 先就位：26.1.1 对 Java 版本的硬性要求

26.1.1 自带的sdkmanager编译目标较低，用高版本 JDK 跑会出现UnsupportedClassVersionError，报错里带class file version 55.0之类的字样。常见做法是给它配一个 JDK 8，与老 Unity 编辑器需要的版本保持一致，省得一套环境里塞两个 Java。

# 确认当前 java 版本，输出应为 1.8.x java -version # 临时指定 JDK 8 的家目录，Windows 下路径写法类似 export JAVA_HOME=/opt/jdk8 export PATH=$JAVA_HOME/bin:$PATH

JAVA_HOME指向 JDK 根目录，不是bin，也不是jre。这三者搞混是新手最常犯的错，表现是sdkmanager报找不到lib/tools.jar。如果机器上同时存在多个 JDK，用update-alternatives或直接改PATH顺序切换，别指望sdkmanager自己挑。

3.2 用 sdkmanager 拉取 platform-tools 与 build-tools

先看可用包列表，确认网络能通到仓库，再决定装哪个版本。

# 列出已安装与可安装的包，输出较长，可以重定向到文件再翻 sdkmanager --list > pkgs.txt # 安装设备工具、编译工具和目标平台，版本号按工程需要替换 sdkmanager "platform-tools" "build-tools;27.0.3" "platforms;android-27" # 补一个低版本 build-tools 备用，老编辑器有时只认年代接近的版本 sdkmanager "build-tools;26.0.2"

三条命令的意图不同。platform-tools与版本无关，装最新即可；build-tools是版本敏感项，示例给的 27.0.3 属于与 26.1.1 同一时期的版本，跟老 Unity 编辑器的调用方式匹配度更高；platforms;android-27对应targetSdkVersion 27，要和工程里的设置对齐，否则 Gradle 找不到android.jar。

装完检查build-tools目录下是否真的有aapt、zipalign、apksigner三个文件。某些精简版压缩包会把aapt2裁掉，只影响 AGP 3.0 以上的构建，用 Unity 内置构建链路时不致命，但导出 Gradle 工程后就会暴露。

3.3 license 接受与离线目录的落地校验

26.1.1 的sdkmanager在首次安装某个包时会要求接受许可，交互式环境容易过，脚本化环境直接卡死。批量接受：

# 自动对全部许可回答 y，适合 CI 或无人值守环境 yes | sdkmanager --licenses # 校验 licenses 目录是否生成了对应文件 ls $ANDROID_HOME/licenses

许可文件缺失的表现是后续安装命令反复提示Warning: License for package ... not accepted，然后静默跳过，你以为装好了，实际目录是空的。这种“假成功”最容易骗人，所以装完一定要ls一下目标目录，看文件在不在。

离线场景下，把这个装好的 SDK 目录整体打包复制到另一台机器，只要路径一致，可以直接用，不必重跑sdkmanager。路径不一致时改环境变量即可，但 Unity 面板里保存的绝对路径要同步改，否则编辑器会指回旧位置。

3.4 Unity 侧配置与第一个 APK 的产出

三条路径都配好之后，在编辑器里打开 External Tools，把 SDK、JDK、NDK 分别指过去。NDK 只有用 IL2CPP 后端时才必须，Mono 后端可以留空。

批处理出包用下面这个构建脚本，放在Assets/Editor下：

using UnityEditor; using UnityEngine; public class BuildScript { [MenuItem("Build/Android APK")] public static void BuildAndroid() { // 包名与版本号，必须与工程设置一致，否则覆盖安装会失败 PlayerSettings.applicationIdentifier = "com.demo.sample"; PlayerSettings.Android.bundleVersionCode = 1; PlayerSettings.bundleVersion = "1.0.0"; // SDK 区间，target 要对应已安装的 platforms 目录 PlayerSettings.Android.minSdkVersion = AndroidSdkVersions.AndroidApiLevel22; PlayerSettings.Android.targetSdkVersion = AndroidSdkVersions.AndroidApiLevel27; // 签名配置，keystore 路径相对于工程根目录 PlayerSettings.Android.useCustomKeystore = true; PlayerSettings.Android.keystoreName = "keystore/release.keystore"; PlayerSettings.Android.keystorePass = "你的口令"; PlayerSettings.Android.keyaliasName = "demo"; PlayerSettings.Android.keyaliasPass = "你的口令"; BuildPipeline.BuildPlayer( new[] { "Assets/Scenes/Main.unity" }, "Build/demo.apk", BuildTarget.Android, BuildOptions.None); } }

脚本里每个字段都对应构建链路的一个环节。applicationIdentifier决定最终 APK 的包名，改包名等于换一个应用，覆盖安装会失败。minSdkVersion和targetSdkVersion决定编译期用哪个android.jar，跟第 3.2 步装的 platform 必须对得上。useCustomKeystore为真时才会走自定义签名，否则用调试证书，产物无法上架也无法覆盖安装正式包。

keystoreName是相对工程根目录的路径，写绝对路径在切换构建机时会失效。口令明文写在脚本里不合适，实际项目里用环境变量读，这里为了可读性先展开。

命令行调用：

# 无界面批处理构建，日志单独落盘便于排查 Unity -quit -batchmode -projectPath /path/to/project \ -executeMethod BuildScript.BuildAndroid \ -logFile build.log

-quit保证构建完退出进程，-batchmode关掉图形界面，-executeMethod指定入口方法，方法必须是public static。构建失败时先看build.log里最后一段Error，Unity 的报错经常把真实原因藏在前面几十行的 Gradle 输出里。

4. 打包参数怎么定：build-tools 版本、targetSdk 与签名的匹配关系

环境通了以后，真正决定“能不能出、出了能不能装”的是参数组合。这一章把这几个互相牵制的参数拆开讲。

4.1 build-tools 版本与 aapt/aapt2 的兼容边界

build-tools 不是越新越好。它内部有两套资源编译器：老链路用aapt，AGP 3.0 之后默认aapt2。Unity 的内置构建在多数老版本里走aapt，导出 Gradle 工程后走aapt2，两者对资源文件的宽容度不一样。

版本选得太高，常见报错是Failed to run aapt或aapt: error: resource ... not found，指向的资源明明存在。原因通常是新版本 aapt 对AndroidManifest.xml里的属性校验更严，或者--no-version-vectors之类的参数被移除。

我的选择逻辑是这样：编辑器版本偏老，就选与它发布年代接近的 build-tools，26.0.2 和 27.0.3 是两个比较稳的落点；如果工程必须用 AndroidX 或较高 targetSdk，再往 28.0.3 走，同时接受导出 Gradle 工程来构建。多版本并存不冲突，Unity 会自动挑最高的，想强制用某个版本，就在导出工程后改build.gradle里的buildToolsVersion。

4.2 minSdk、targetSdk 与 AndroidManifest 合并

minSdkVersion决定应用能装在多老的设备上，targetSdkVersion决定运行时的行为兼容层。两者不是随便填的数字，填错会在两个阶段出问题：编译期 Gradle 找不到 platform，运行期系统按错误的兼容策略处理权限和后台限制。

导出的 Gradle 工程里，这三项最终会合并进AndroidManifest.xml的uses-sdk节点。如果第三方插件自带的 manifest 声明了更高的 minSdk，合并时会报：

uses-sdk:minSdkVersion 22 cannot be smaller than version 23 declared in library

解决方式有两种：把主工程的 minSdk 提到插件要求的下限，或者在AndroidManifest.xml里加tools:overrideLibrary强制覆盖。前者安全，后者只适合确认插件在低版本上确实能跑的情况。

注意：targetSdkVersion调高会改变运行时行为，比如存储权限、后台启动限制。老工程升级这一项要单独回归，别跟打包环境改造混在一次提交里。

4.3 签名参数与 keystore 的生成方式

签名是出包环节里最不能省的一步。调试证书打出来的包，包名相同也无法覆盖安装，用户升级会直接失败。

# 生成一个有效期较长的 release keystore keytool -genkeypair -v \ -keystore release.keystore \ -alias demo \ -keyalg RSA -keysize 2048 -validity 10000 \ -storepass 你的口令 -keypass 你的口令 \ -dname "CN=demo, OU=dev, O=demo, L=CN, ST=CN, C=CN"

-validity单位是天，10000 天大约 27 年，够用。-keyalg RSA -keysize 2048是当前通用的组合，低于 2048 位在新系统上会被拒。-alias是别名，后续 Unity 面板里的 keyalias 必须跟它一致，写错的表现是Keystore was tampered with, or password was incorrect，看着像口令错，实际是别名对不上。

keystore 文件和口令要单独备份。丢了之后同一个包名再也发不出可覆盖安装的更新，只能换包名重新上架，这个代价不小。

4.4 自定义 Gradle 模板与导出工程排查

Unity 允许覆盖默认的 Gradle 模板，位置在Assets/Plugins/Android/下，常见的是mainTemplate.gradle和gradleTemplate.properties。改模板能解决依赖冲突、仓库地址、编译选项这几类问题，但也会让构建脱离 Unity 的默认路径，出问题时排查面变大。

一个典型场景是引入的 SDK 依赖了较高版本的 support 库，与工程里已有的低版本冲突，报Duplicate class或Conflict with dependency。在mainTemplate.gradle的dependencies块里加exclude或统一版本号可以解决：

// 放在 mainTemplate.gradle 的 dependencies 块内 configurations.all { resolutionStrategy { // 强制统一某个库的版本，避免传递依赖拉出多个版本 force 'com.android.support:support-v4:27.1.1' } }

force是硬约束，会覆盖所有传递依赖的版本声明，用之前确认目标版本与工程实际调用兼容。更温和的方式是exclude group:，只排掉冲突的那一路。

导出工程后单独用 Gradle 构建，是定位问题的有效手段。Unity 的日志会把 Gradle 输出压缩，很多细节看不到；导出后跑gradlew assembleRelease --stacktrace，堆栈完整，能直接定位到某个依赖或某个资源文件。

5. 排查五类高频翻车：路径、JDK、命令缺失、安装失败与 aapt 报错

下面五条都是我在实际项目里反复遇到的，按“现象 → 原因 → 解决”记，遇到同类问题时可以直接对照。

5.1 SDK 路径含空格或中文，Gradle 直接中断

现象：构建到一半报Could not find method ...或者某个.gradle文件行号报语法错误，打开那个文件内容完全正常。

原因：Unity 调用 Gradle 时通过 shell 拼接命令，路径里的空格被当成分隔符，后面的片段被当成独立参数传给 Gradle，脚本解析自然出错。中文路径在部分编码环境下还会变成乱码。

解决：把 SDK、JDK、工程目录全部移到纯英文无空格路径下，比如D:/sdk/android、D:/work/demo。改完清一遍 Unity 的Library目录再构建，避免缓存的旧路径残留。

5.2 JDK 版本错配，sdkmanager 与 Gradle 各报各的

现象：sdkmanager --list报UnsupportedClassVersionError，或者 Unity 构建时报Could not determine java version from '11.0.x'。

原因：26.1.1 的sdkmanager与老版本 Gradle 都要求 JDK 8。机器上装了更高版本 JDK，JAVA_HOME指过去之后，两处都会因为字节码版本或 Java 版本解析规则变化而失败。

解决：单独安装一个 JDK 8，环境变量指向它。如果必须保留高版本 JDK 给其他工具用，就在启动 Unity 和sdkmanager的脚本里临时覆盖JAVA_HOME，不要改全局。

5.3 Unable to list target platforms：老编辑器找不到 android 命令

现象：Unity 打开工程时弹窗Unable to list target platforms. Please make sure the Android SDK path is correct，但 SDK 路径明明是对的，platform-tools也在。

原因：某些老版本编辑器启动时会调用android list targets枚举已安装平台，26.1.1 已经移除了android命令，调用直接失败，编辑器误判为 SDK 路径错误。

解决：优先升级编辑器到支持sdkmanager的版本；如果工程锁死不能升，就在tools/bin下补一个兼容脚本转发到sdkmanager，或者手工把已安装的 platform 信息写进编辑器读取的配置文件。前一种做法更干净，后一种只适合临时救急。

5.4 INSTALL_FAILED_ 系列安装失败

现象：adb install返回Failure [INSTALL_FAILED_...]，包传上去了但装不上。

原因与解决对照：

-d参数只影响安装行为，不改变包本身。签名不一致那条不要用-d硬顶，系统会继续拒绝，正确做法是卸载重装，或者统一签名。

5.5 build-tools 版本过高导致 aapt 参数不兼容

现象：构建日志里出现aapt: error:开头的一段，指向的资源文件在工程里确实存在，单独用aapt dump也能读。

原因：Unity 内置构建传给aapt的参数集是固定的，新版本 build-tools 移除了某些参数或改变了参数语义，调用方还在按老格式传，自然报错。

解决：把 build-tools 降到与编辑器年代接近的版本，或改成导出 Gradle 工程构建。判断方法很简单，看日志里aapt的完整命令行，把参数逐个对照该版本的aapt --help，缺哪个补哪个，通常改一次就能定位。

6. 出包后验证：用 aapt 与 apksigner 做一遍可复用的自检

包打出来不等于能交付。我习惯在给测试之前跑一遍脚本化自检，检查包名、版本、SDK 区间、签名和架构，这几项任何一项不对，装到设备上都会以另一种形式暴露，排查成本高得多。

先把签名和验证跑通：

# 用 build-tools 里的 apksigner 签名，注意路径按实际版本替换 BT=$ANDROID_HOME/build-tools/27.0.3 $BT/apksigner sign --ks release.keystore --ks-key-alias demo \ --out demo-signed.apk demo-unsigned.apk # 验证签名，输出里应包含 v1/v2 的验证结果 $BT/apksigner verify --verbose demo-signed.apk # 对齐处理，必须在签名之前做，顺序反了签名会失效 $BT/zipalign -v -p 4 demo-unsigned.apk demo-aligned.apk

--verbose会打印每个签名方案的校验结果，Verifies字样出现才说明通过。zipalign的-p表示按页对齐，四个字节的边界值固定写 4，这个参数从旧版本沿用至今。顺序上先对齐再签名，反过来会把对齐信息算进签名范围，验证直接失败。

再抽取包内元信息：

# 读出包名、版本、SDK 区间和 native 架构 $BT/aapt dump badging demo-signed.apk | head -n 5 # 单独确认 64 位库是否打进去了 unzip -l demo-signed.apk | grep "lib/arm64-v8a"

aapt dump badging的前几行包含package: name=... versionCode=...、sdkVersion、targetSdkVersion和native-code，正好覆盖上架前的硬性检查项。native-code里没有arm64-v8a而工程用了 IL2CPP，说明架构选项没勾全。

把这两段合成一个自检脚本，每次出包自动跑：

#!/usr/bin/env bash set -e APK=$1 BT=$ANDROID_HOME/build-tools/27.0.3 # 签名校验，失败直接退出 $BT/apksigner verify --verbose "$APK" | grep -q "Verifies" || { echo "签名校验失败"; exit 1; } # 关键字段抓取，人工核对 $BT/aapt dump badging "$APK" | grep -E "^(package|sdkVersion|targetSdkVersion|native-code)" echo "自检完成：$APK"

set -e让任何一步失败都终止，避免带着问题往下走。grep -q只关心命中与否，不打印中间过程，输出干净。脚本没有做版本号合法性判断，那部分依赖工程约定，硬编码进脚本反而容易过期。

还有一条经验值得单独说：同一台机器上并存多个 build-tools 版本时，脚本里的BT变量一定写死具体版本，不要用通配符匹配目录。ls build-tools | tail -1这种写法在装了新版本之后会悄悄换掉工具链，自检结果跟着变，问题出现时很难联想到是脚本自己漂移了。

从那以后我每次出包前都强制走一遍这个自检脚本，哪怕只是改了一行代码的小版本，也不跳过。签名和架构这两项出问题的概率不高，但一旦漏掉，返工要从构建环境重新查起。希望帮到你。

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