离线 Android SDK Tools 26.1.1 配置 Unity3D 打包 APK 实战

简介AndroidSDKTools26.1.1.rar 面向使用 Unity 2018/2019 打包 Android APK 的开发者提供一套稳定、兼容且配置相对简洁的 SDK Tools 版本适合需要快速搭建 Android 打包、真机调试与性能优化环境的中初级移动开发人员也可作为旧项目维护时核对 SDK 版本依赖的参考。压缩包共 1828 个文件大小约 146.29MB内含 jar 库、gif/png/jpg 界面素材、css/html/properties/xml 配置与文档、exe 可执行程序、bat 脚本以及 SDK Manager、Adb、Zipalign、monitor、apkanalyzer 等组件目录结构较完整便于按工具用途定位所需文件。目前已有 2833 人学习下载说明该版本在 Unity 旧工程打包与版本回退场景中仍有较高参考价值对首次配置 Android 打包环境的开发者较为友好。读者可据此在 Unity 的 Player Settings 中指定 SDK/NDK 路径借助 SDK Manager 补齐 Android 平台与构建工具通过 Adb 将 APK 安装到真机进行调试再用 Zipalign 完成对齐优化并结合包内说明排查版本不匹配、打包失败等常见问题从而更顺畅地完成 APK 构建与验证。1. 一份离线 Android SDK Tools 26.1.1解决的是 Unity3D 打包 apk 前那半天环境配置新机器、内网机器、临时借来的笔记本代码拉下来一按 BuildUnity 立刻给你一句 “Unable to locate Android SDK”或者更绕的CommandInvokationFailure: Failed to re-package resources。真正卡住的往往不是业务逻辑而是 Android SDK Tools 这套构建链缺失sdkmanager没有、build-tools缺版本、JDK 装成了 17。这份 AndroidSDKTools26.1.1.rar 就是一套解压即用的离线 SDK 工具集配合 Unity3D 打包 apk 的老版本工程尤其实用。它适合三类人接私活要在客户机器上十分钟内复现构建环境的人、维护 2017~2019 年老工程的人、以及构建机不能连外网的团队。下面按“包里是什么 → 怎么装 → Unity 怎么接 → 错误如何出现和解决 → 出包怎么验”的顺序拆。2. 解包先认目录26.1.1 的四个文件夹各管哪一段构建链2.1 解压后各目录的职责边界解压完先别急着配环境变量先看清楚根目录下有什么。26.1.1 这一代还是“独立 SDK Tools”的布局tools/、platform-tools/、build-tools/、platforms/四块各司其职混淆其中任何一层后面 Unity 里填路径就必然出错。目录关键内容在打包链路里的作用能否单独替换tools/binsdkmanager、avdmanager安装/查询 SDK 组件是整个包的入口不建议老版本 Unity 只认这个布局platform-toolsadb、fastboot设备通信、安装调试、抓 logcat可以独立升级影响不大build-tools/版本号aapt、aapt2、d8、apksigner、zipalign资源打包、dex 转换、签名、对齐Unity 真正调用的一层可以多版本可共存platforms/android-XXandroid.jar编译期 API 类库与 targetSdk 强绑定可以按需增删licenses许可文件缺了会反复要求接受协议由sdkmanager --licenses生成build-tools是整条链上最容易出问题的一层。同一个 SDK 根下允许存在28.0.3、29.0.3等多个版本Unity 会按工程里的 targetSdk 和自身内置的映射表去挑一个挑不到就报错而不是自动降级。所以要么把工程实际需要的那个版本装上要么在 Gradle 模板里显式指定。2.2 为什么老 Unity 认 26.1.1换成新版命令行工具反而水土不服现在官方主推的是 command-line tools目录结构变成了cmdline-tools/latest/bin/sdkmanager的位置、包描述文件格式都变了。2019 之前的 Unity 在探测 SDK 时是按tools/是否存在、tools/bin/sdkmanager是否可执行来判断的路径一变它就觉得你填的目录“不是 SDK”。26.1.1 是最后一批带完整tools/目录的独立 SDK Tools 包正好落在老 Unity 的识别逻辑里。另一个隐性差异是 Java 版本。26.1.1 的sdkmanager是老写法依赖 JAXB 这类在 JDK 9 之后被移出标准库的模块用 JDK 11 或 17 启动会直接抛异常而新版命令行工具反过来要求 JDK 11 以上。这就形成了一个很尴尬的局面老 Unity 自带 JDK 8只跑得动 26.1.1新工具链要 JDK 11老 Unity 又跑不动。所以我一般会把 JDK 8 和这套 26.1.1 捆在一起当作老工程的固定组合。2.3 版本搭配Unity、JDK、build-tools 怎么对齐没有官方强绑定表下面是按实际工程跑通率整理的常见搭配遇到报错时优先怀疑这几项不匹配而不是去改代码。Unity 版本JDKbuild-toolsplatforms构建系统5.6 ~ 2017.x825.0.3 / 26.0.2android-23 ~ 25Internal 为主2018.x828.0.3android-26 ~ 28Internal 或 Gradle2019.1 ~ 2019.2828.0.3 / 29.0.2android-28Gradle 5.x2019.3 ~ 2019.48部分支持 1129.0.3android-29Gradle 5.6.4 / 6.x提示targetSdk 填 30 以上而platforms里只装到 android-28是最常见的“编译期找不到符号”来源。要么把platforms;android-30装上要么把 targetSdk 降到已装版本。2.4 路径规划三个不能碰的红线SDK 根目录路径必须满足不含空格、不含中文、不含括号等特殊字符。C:\Program Files\Android\sdk这种看着规整的路径会在 Gradle 拼命令行时被空格截断报出一堆莫名其妙的“找不到文件”。桌面、下载目录、网盘同步目录同样不行同步进程锁文件会导致aapt读写失败。推荐落位Windows 用D:\Android\sdkLinux/macOS 用~/android-sdk。另外 Windows 上还要留意路径总长度工程路径 SDK 路径 中间产物路径超过 260 字符时构建会在拷贝资源阶段随机失败这种问题排查起来非常费劲。3. 解压到命令行跑通sdkmanager 补 platforms 与 build-tools 的完整步骤3.1 解压并确认目录层级rar 包常见的问题是解压后多套一层同名目录导致tools/不在根下。先解压再确认不要跳过这一步直接配环境变量。# Linux / macOS解压到统一目录路径不含空格 mkdir -p $HOME/android-sdk 7z x AndroidSDKTools26.1.1.rar -o$HOME/android-sdk -y # 关键校验tools 必须直接位于根目录下 ls $HOME/android-sdk # 期望输出包含tools platform-tools build-tools platforms licenses# Windows PowerShell同样先建目录再解压 New-Item -ItemType Directory -Force -Path D:\Android\sdk | Out-Null C:\Program Files\7-Zip\7z.exe x .\AndroidSDKTools26.1.1.rar -oD:\Android\sdk -y Get-ChildItem D:\Android\sdk -Name如果输出里多了一层AndroidSDKTools26.1.1把里面所有内容上移一层或者直接把环境变量指向那一层。判断标准只有一个根/tools/bin/sdkmanagerWindows 上是sdkmanager.bat必须存在且可执行。3.2 环境变量ANDROID_HOME 与 ANDROID_SDK_ROOT 都设上26.1.1 这一代文档里用的是ANDROID_HOME后来统一成ANDROID_SDK_ROOT但很多老脚本、老 CI 配置还在读前者。两个都设最省事值指向同一个目录不要一个指向根、一个指向platforms。# 追加到 ~/.bashrc 或 ~/.zshrc export ANDROID_HOME$HOME/android-sdk export ANDROID_SDK_ROOT$ANDROID_HOME export JAVA_HOME/usr/lib/jvm/jdk1.8.0 # 必须 JDK 8 export PATH$JAVA_HOME/bin:$ANDROID_HOME/tools/bin:$ANDROID_HOME/platform-tools:$PATH# Windows写入用户级环境变量避免污染系统变量 [Environment]::SetEnvironmentVariable(ANDROID_HOME,D:\Android\sdk,User) [Environment]::SetEnvironmentVariable(ANDROID_SDK_ROOT,D:\Android\sdk,User) [Environment]::SetEnvironmentVariable(JAVA_HOME,D:\Java\jdk1.8.0_202,User) $env:Path ;D:\Android\sdk\tools\bin;D:\Android\sdk\platform-toolsPATH里把JAVA_HOME/bin放在最前面是为了压过系统里可能存在的另一个 JDK。改完开新终端用java -version确认输出是1.8.0_xxx这一步没确认就去跑sdkmanager八成会撞上后面 5.1 节那个异常。3.3 用 sdkmanager 补齐组件并接受许可26.1.1 的sdkmanager已经从自身位置往上推断 SDK 根但推断逻辑在解压路径不规范时会算错把包装到别的地方去。所以每次都显式带--sdk_root不依赖推断。# 1) 先看当前已装了什么 sdkmanager --sdk_root$ANDROID_HOME --list # 2) 装构建必需的三件套版本按工程实际需要改 sdkmanager --sdk_root$ANDROID_HOME \ platform-tools \ platforms;android-28 \ build-tools;28.0.3 # 3) 接受许可交互式逐条输入 y sdkmanager --sdk_root$ANDROID_HOME --licenses参数含义逐个说清--sdk_root指定安装目标根目录包名必须用分号分隔的完整形态写成android-28是无效的build-tools;28.0.3里的版本号必须真实存在写错会返回一长串可用版本列表而不是直接报错。许可证那一步会在licenses/下生成对应文件缺了它 Gradle 构建时会报 “You have not accepted the license agreements”。注意完全离线的机器上手工把platforms/android-28目录拷进去是不够的包里还缺package.xmlsdkmanager --list看不到它Unity 也可能当作不存在。要么在有网机器上装好整个目录再整体拷贝要么走内网镜像源。3.4 三个自检命令缺一不可装完别直接开 Unity先在命令行把三件事验掉。这三条命令分别对应“设备通不通”“资源打包工具在不在”“签名工具在不在”后面 Unity 报的错基本都能归到这三类。# 设备侧能列出 adb 版本即正常 adb version # 资源打包输出 Android Asset Packaging Tool 版本信息 $ANDROID_HOME/build-tools/28.0.3/aapt v # 签名工具输出 apksigner 版本号 $ANDROID_HOME/build-tools/28.0.3/apksigner --versionWindows 上路径分隔用反斜杠可执行文件带.exe例如D:\Android\sdk\build-tools\28.0.3\aapt.exe v。如果aapt报“不是内部或外部命令”说明 build-tools 没装成功或版本号写错回到 3.3 重来不要试图在 Unity 里改配置绕过——Unity 最终调用的就是这几个可执行文件命令行不通编辑器里一样不通。4. Unity 侧接线SDK 路径、签名、Gradle 模板三处钉死4.1 External Tools 里填三个路径别填错层级打开 PreferencesWindows 是 Edit Preferences External Tools重点是 Android 那一段。老版本 Unity 默认勾选 “Android SDK Tools Installed with Unity”勾着的时候路径输入框是灰的必须先取消勾选才能填自己的路径——这一步很多人卡住以为输入框坏了。填法Android SDK Tools 填 SDK根目录D:\Android\sdk不是tools也不是platformsJDK 填 JDK 8 的根目录里面要有bin/javaNDK 只在用 IL2CPP 时需要走 Mono 后端可以留空。填完关掉面板重新打开看路径有没有被自动改写——被改写通常意味着 Unity 认为这个目录不合法。4.2 Player Settings包名、API 区间与 ABI 三件套Player Settings Other Settings 里几个字段直接决定能不能出包。Package Name 至少两段每段以字母开头形如com.studio.demo用纯数字段或含中文会被构建期直接拒绝。Minimum API Level 按最低支持机型定一般 22 或 23Target API Level 必须 ≤ 已装platforms的最高版本号。Scripting Backend 与 ABI 是强关联的Mono 后端只支持 ARMv7 和 x86勾 ARM64 不生效要出 64 位包必须切 IL2CPP并在 Target Architectures 里同时勾 ARMv7 和 ARM64。如果你的工程里带了只有arm64-v8a的第三方 so而 ABI 只勾了 ARMv7装到手机上就是秒退日志里是UnsatisfiedLinkError。4.3 keystore 生成与签名配置正式包必须用自己的 keystoreUnity 默认用~/.android/debug.keystore签这玩意换台机器就变会导致同包名无法覆盖安装。生成命令如下# 生成 release keystore有效期按 10000 天算 keytool -genkeypair -v \ -keystore $HOME/keys/release.keystore \ -alias releasekey \ -keyalg RSA \ -keysize 2048 \ -validity 10000 \ -storetype JKS参数逐个解释-keysize 2048是当前通用下限-validity 10000约 27 年应用市场普遍要求有效期覆盖到 2033 年以后-storetype JKS是关键一笔JDK 9 之后 keytool 默认生成 PKCS12 格式而老版本 Unity 的 keystore 读取逻辑只认 JKS不指定就会在签名阶段报 “Failed to read key”。生成后填进 Publishing Settings 的 Custom Keystorealias 和两个密码照填。注意keystore 文件和应用包名是绑定的丢了就再也无法给已上架的同包名应用做升级。我一般会在工程里放一份keystore/目录不进版本库另外单独冷备两份。4.4 自定义 Gradle 模板解决离线依赖一旦工程引入第三方 aar就必须从 Internal 切到 Gradle 构建。勾选 Publishing Settings 里的 Custom Main Gradle Template 后会在Assets/Plugins/Android/mainTemplate.gradle生成模板文件依赖段按下面的方式写// Assets/Plugins/Android/mainTemplate.gradle dependencies { implementation fileTree(dir: libs, include: [*.jar]) // 本地 aar 走 flatDir不依赖远端仓库 implementation(name: pay-sdk-1.0.0, ext: aar) // 不要在这里直接写 implementation com.xxx:1.0.0 // 构建机连不上仓库时整条构建会在依赖解析阶段直接失败 } android { defaultConfig { minSdkVersion 23 targetSdkVersion 28 } }逻辑说明Unity 生成 Gradle 工程时会把这段原样带过去远端仓库拉不到就整条构建中断把 aar 预置到Assets/Plugins/Android/libs/并配 flatDir是内网机器最稳的做法。minSdkVersion写在这里可以覆盖 Unity 从 Player Settings 推导出的值用于解决与第三方 aar 的清单合并冲突。改完模板要重新构建一次确认gradle日志里没有Could not resolve字样。4.5 Internal 与 Gradle 两条路怎么选Build Settings 里的 Build System 有两个选项。Internal 不走 Gradle出包快适合纯代码工程和频繁调试但它不支持自定义 Gradle 模板、不支持 aar 依赖、不支持 AAB 输出。Gradle 走完整流程慢但可控。判断标准很简单工程里有没有Assets/Plugins/Android下的 aar 或需要改 Gradle 配置——有就选 Gradle没有就 Internal别为了“看起来规范”硬上 Gradle徒增构建时间。5. 五处高频问题从 sdkmanager 直接抛异常到装完秒退5.1 sdkmanager 一启动就抛 NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema现象命令行敲sdkmanager --list还没输出任何包列表就先抛一长串 Java 异常末尾是XmlSchema。原因当前JAVA_HOME指向 JDK 9 及以上JAXB 模块被移出标准库而 26.1.1 的sdkmanager是老写法。解决把JAVA_HOME切到 JDK 8java -version确认输出1.8.0_xxx再重试。不要试图往 JVM 参数里加--add-modules打补丁Unity 那边同样会因为这个 JDK 出问题。5.2 Unity 里一直报 Unable to locate Android SDK现象Preferences 里路径填了输入框也没变红但一构建就报找不到 SDK。原因通常有三种填到了tools或platforms子目录路径里带空格或中文机器上装了多个 SDKUnity 从环境变量读到的是另一个。解决路径填根目录确认根下有tools/和platforms/临时清掉多余的ANDROID_SDK_ROOT确认 “Installed with Unity” 已取消勾选。改完重启编辑器再试。5.3 CommandInvokationFailure: Failed to re-package resources现象构建走到资源打包阶段失败日志里出现aapt字样或 “Unable to find explicit activity class”。原因build-tools对应版本没装或者 targetSdk 高于已装platforms的版本。解决按 3.3 把build-tools和platforms;android-XX补齐确认build-tools/版本目录里确实有aapt如果工程里有多个插件各自指定了不同 build-tools 版本统一到同一个。5.4 安装成功但一打开就闪退日志里是 UnsatisfiedLinkError现象APK 装得上点图标黑屏或秒退logcat 显示java.lang.UnsatisfiedLinkError: dlopen failed。原因第三方 so 只提供了arm64-v8a而 Target Architectures 只勾了 ARMv7或者用了 Mono 后端却指望它出 64 位。解决切 IL2CPP同时勾 ARMv7 与 ARM64用unzip -l app.apk | grep lib/看看包里到底带了哪些 ABI 目录缺哪个补哪个。5.5 INSTALL_FAILED_UPDATE_INCOMPATIBLE现象覆盖安装时被系统拒绝提示签名不一致。原因手机上已装的旧包是用 debug keystore 或另一个 release keystore 签的换机器后~/.android/debug.keystore会重新生成签名自然不同。解决先卸载旧包再装或者把 keystore 固定到工程外统一目录Unity 里明确指定 Custom Keystore别让编辑器偷偷用 debug 签名。6. 出包之后别急着发用 aapt 与 apksigner 把 APK 验一遍构建成功不等于包是对的。包名写错、versionCode 没涨、只出了 v1 签名、ABI 少一个目录这些问题在编辑器里全都看不出来装到测试机才暴露。我习惯在出包之后跑三条命令三十秒内把该看的看完。6.1 用 aapt 读出包名、版本与 ABI 清单BT$ANDROID_HOME/build-tools/28.0.3 $BT/aapt dump badging app-release.apk | head -n 8输出第一行形如package: namecom.studio.demo versionCode12 versionName1.2.0往下是sdkVersion、targetSdkVersion、native-code: arm64-v8a armeabi-v7a。要核对三件事包名和上架的一致、versionCode 比上一版大、native-code里有你需要的所有 ABI。少一个 ABI对应机型就会闪退而这条信息只有 aapt 能直接读出来。6.2 签名与对齐校验# 签名方案校验同时打印证书指纹 $BT/apksigner verify --verbose --print-certs app-release.apk # 4 字节对齐校验无输出即通过 $BT/zipalign -c -v 4 app-release.apkapksigner verify会逐条列出v1 scheme (JAR signing): true、v2 scheme (APK Signature Scheme v2): true。targetSdk 到 30 以上时只有 v1 签名的包在部分设备上会被拒绝安装这时需要在 Gradle 模板里打开 v2 签名。zipalign不通过虽然不影响安装但会拖慢资源加载而且某些渠道的加固流程会直接拒绝未对齐的包。6.3 把三条校验固化进出包脚本#!/usr/bin/env bash set -euo pipefail APK$1 BT${ANDROID_HOME}/build-tools/28.0.3 $BT/aapt dump badging $APK | grep -E ^package:|^native-code: || true $BT/apksigner verify --verbose $APK $BT/zipalign -c -v 4 $APK /dev/null echo zipalign okset -euo pipefail保证任何一步失败立刻退出不会带着有问题的包继续往下走。这套脚本我一般挂在打包流程最后参数就是产出的 APK 路径三个检查项对应签名、对齐、ABI 三类最隐蔽的问题。说个真实教训早年给一个老工程补版本随手用了编辑器默认签名测试机覆盖安装全部失败回头翻 keystore 已经找不到了只能让所有测试机卸载重装。从那以后我每次新建 Unity 工程第一件事就是把 keystore 和 JDK 版本写进 README第二件事是把sdkmanager --list的输出存一份。这套 26.1.1 的工具包我一般留在工具盘里新机器解压、配两条环境变量、跑三条sdkmanager命令构建链就齐了比现场下一个几百兆的安装器快得多。希望帮到你。本文还有配套的精品资源点击获取