企业官网建设流程全解析

简介：android-sdk-26_1_1.zip是一份Android SDK Tools 26.1.1更新包，面向Android应用与Unity Android游戏开发者，用于替换旧版25.2.5及以下的不稳定工具，修复构建、调试与发布流程中的已知问题。压缩包共1826个文件，以jar工具库、gif/png/jpg图示、xml/properties配置、html文档及bat/exe可执行工具为主，整体148.9MB，目录覆盖模拟器、构建工具和开发者集成组件，便于按需检索与替换。已有2495人学习下载。内置完整tools目录与替换说明，包含apkanalyzer、android.bat等命令行工具，可帮助快速定位旧版问题；同时针对Unity Android构建链做了兼容性适配，升级后能获得更好的模拟器效率、新API支持与稳定性提升，适合需手动维护SDK环境的中高级开发者。

1. android-sdk-26_1_1.zip：一个可离线复用的 Android 8.0 构建环境

接手维护一个 targetSdkVersion 26 的老项目，机器又在隔离内网，装不上任何在线下载的 SDK 组件。团队前辈丢过来一个android-sdk-26_1_1.zip，说解压就能用。这个压缩包本质上是一个面向 API 26（Android 8.0）的完整 Android SDK 离线快照，里面通常包含platforms、build-tools、platform-tools等核心目录，解压后通过环境变量指过去，Gradle 就能在完全离线的状态下编译出 APK。它能解决的是三类人的问题：维护老项目的客户端开发、搭建内网 CI 的工程效率同学、以及任何被网络限制困扰却又要碰 Android 构建链路的从业者。这篇文章会从包结构分析、环境变量配置、最小工程编译讲到高频踩坑，全程用命令说话。

2. 先验证再解压：android-sdk-26_1_1.zip 的包结构与落地命令

拿到压缩包的第一反应不是解压，而是先搞清楚里面到底装了什么。SDK 压缩包和普通软件压缩包不一样，它的目录结构直接决定 Gradle 能不能认出来。如果你解压后看到的是android-sdk-26_1_1这层外壳目录，而里面才是platforms、build-tools，那环境变量就要指到外壳层，指错一层后面全是麻烦。

2.1 文件名里的版本信息：API 26 需要哪些核心组件

26_1_1的含义拆开看：26是 API Level，对应 Android 8.0；_1_1是这个离线包自己的修订序号，不代表官方 build-tools 版本。一个能完整承担编译任务的 SDK 包，至少需要同时具备四个角色。

platforms/android-26目录里放着android.jar，这是编译时引用系统 API 的基石。没有它，compileSdkVersion 26会直接报错找不到平台。build-tools目录放着aapt2、d8、zipalign等实际干活的工具。platform-tools提供adb，用于设备调试和连接。cmdline-tools提供sdkmanager，负责在在线环境下补充安装组件——但离线场景下它通常只是个验证器。

注意：文件名里的_1_1不要理解为 build-tools 的版本号。具体是什么工具链版本，解压后看build-tools子目录的文件夹名最准确。

2.2 解压四步：校验、建目录、解压、核对版本

先校验压缩包完整性，再解压。这一步很多人跳过，结果工具链跑起来各种玄学崩溃，最后发现是压缩包传输过程中损坏了。

# 1. 校验压缩包完整性，避免传输损坏导致解压后工具链崩溃 sha256sum android-sdk-26_1_1.zip # 2. 创建统一安装目录，路径中不要出现中文、空格或特殊符号 mkdir -p /opt/android-sdk # 3. 解压，保留 zip 内原始目录结构 unzip android-sdk-26_1_1.zip -d /opt/android-sdk # 4. 核对关键可执行文件版本，确认工具链确实可用 /opt/android-sdk/build-tools/*/aapt2 version /opt/android-sdk/platform-tools/adb version

第一步的sha256sum会输出一串哈希值。如果你手上没有原始哈希可对照，至少确认文件能正常解压、没有 CRC 警告，这能规避八成传输损坏问题。第三步用-d指定解压目录，好处是把所有 SDK 内容收敛到一个固定路径，后续环境变量只需要指这一个地方。第四步用了通配符*匹配build-tools下的具体版本目录，这样即使不同机器上版本号不同，脚本也不会写死。

2.3 核对组件缺失：目录自查顺序

解压完成后，用ls看一眼根目录结构，比什么排查都直接。

# 查看 SDK 根目录下的顶层目录，确认核心组件是否齐全 ls -la /opt/android-sdk # 精确查找 android.jar，它是 platform 是否完整的硬指标 find /opt/android-sdk -name android.jar -type f

正常情况下，你应该能在根目录下看到platforms、build-tools、platform-tools这几个名字。如果build-tools下面没有aapt2而只有老旧的aapt，说明这个离线包里的编译工具比较陈旧，后面遇到资源编译问题时要心里有数。find命令搜android.jar是为了确认platforms/android-26存在且路径没有多套一层。

下面这个表是自查时的参照系：

3. 接入构建链路：环境变量、sdkmanager 离线用法与三件套验证

SDK 解压到位之后，下一步是让构建工具找到它。Android 构建链路对环境变量的依赖非常强，而且新旧工具读取的变量名还不完全一致，这是新手最容易翻车的地方，也是最值得花几分钟把它彻底搞懂的地方。

3.1 环境变量配置：ANDROID_HOME、ANDROID_SDK_ROOT、PATH 三者关系

老一代构建工具认ANDROID_HOME，新一代工具链则优先读ANDROID_SDK_ROOT。为了不让某个工具因为找不到变量而摆烂，常见的做法是把两个变量都指向同一个 SDK 根目录，再在PATH里把关键命令目录加进去。

# 写入 ~/.bashrc，让环境变量对每个新终端会话都生效 export ANDROID_HOME=/opt/android-sdk export ANDROID_SDK_ROOT=/opt/android-sdk # PATH 只追加 cmdline-tools 和 platform-tools，不要追加 build-tools export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools # 刷新当前会话 source ~/.bashrc

ANDROID_HOME和ANDROID_SDK_ROOT同时设置，是兼容性最好的做法。PATH里不追加build-tools是有意的：build-tools下有多个版本目录，直接加进PATH可能出现版本冲突，正确的做法是让 Gradle 自己去解析。source ~/.bashrc之后，可以用echo $ANDROID_HOME确认变量已经写到当前会话里。

3.2 sdkmanager 的离线用法：验证组件而不是盲目下载

sdkmanager在离线环境下的能力很有限，但可以用它来做一件事：验证当前 SDK 包的组件清单。它读的是cmdline-tools的配置，如果包内没有cmdline-tools目录，这一步会失败，这本身就是一条重要线索。

# 查看离线环境下 sdkmanager 识别到的已安装组件 sdkmanager --sdk_root=/opt/android-sdk --list_installed # 如果发现缺少指定组件，尝试安装（离线环境下需要本地仓库已就绪） sdkmanager --sdk_root=/opt/android-sdk "platforms;android-26"

--sdk_root参数的作用是强制指定 SDK 位置，避免 sdkmanager 去默认路径找。--list_installed输出的是这个 SDK 包实际包含的组件，而不是网上有哪些组件，适合做离线环境的事实核对。第二个安装命令不要在离线机器上指望它能联网拉包，它的意义在于：如果你的内网维护了本地组件仓库，sdkmanager 可以从那里补装缺失的部分。

3.3 三件套验证：aapt、adb、d8 逐个试

配置完环境变量，用三个命令快速确认整条链路没有断点。这三个命令分别对应资源编译、设备通信、dex 转换三条关键路径。

# aapt 验证 platform 是否完整：能正常输出 badging 说明 android.jar 可读 $ANDROID_HOME/build-tools/*/aapt dump badging $ANDROID_HOME/platforms/android-26/android.jar # adb 验证 platform-tools 可用：能输出版本号说明调试链路在线 $ANDROID_HOME/platform-tools/adb version # d8 验证 dex 工具链存在：检查文件是否存在而不是执行它 ls -la $ANDROID_HOME/build-tools/*/d8

第一条命令的dump badging会尝试读取android.jar内的清单信息，如果 SDK 包里的platforms/android-26是完好的，它会输出包名、版本等元信息。第二条adb version是验证platform-tools最简单可靠的方式。第三条用ls而不是直接执行d8，是因为d8需要完整参数才能跑通，单纯检查文件存在性已经足够判断工具链是否完整。

4. 用这套 SDK 编译出第一个 APK：最小工程与命令行编译

环境变量配好之后，真正的考验是能不能编译出一个安装包。这一步会把前面所有配置串起来，任何一环出了问题都会在这里暴露。我们从零开始搭建一个最小工程，不走 IDE 向导，这样你能看清每一步到底发生了什么。

4.1 最小工程目录、local.properties 与 build.gradle

Android Gradle 工程的目录结构是约定俗成的，手工创建并不复杂。关键在于local.properties文件，它用于告诉 Gradle 本地 SDK 的具体位置，避免 Gradle 试图从网络去自动下载。

# 创建最小工程目录结构 mkdir -p demo26/app/src/main/java/com/example/demo26 mkdir -p demo26/app/src/main/res/values

# local.properties：放在工程根目录，sdk.dir 必须指向 SDK 解压根目录 sdk.dir=/opt/android-sdk

local.properties是 Gradle 读取 SDK 路径的最后一层保障。即使环境变量没配对，只要这个文件里的路径正确，Gradle 也能正常工作；反之，环境变量全对但local.properties指向错误路径，构建照样失败。app/build.gradle里需要指定compileSdkVersion 26，这是整个离线包存在的意义所在。

// demo26/app/build.gradle 的关键配置 android { // compileSdkVersion 的 26 必须和压缩包里的 platform 版本一致 compileSdkVersion 26 // buildToolsVersion 不写时 AGP 会自动匹配本地已安装的版本； // 如果自动匹配失败，再按 build-tools 目录名显式指定 defaultConfig { applicationId "com.example.demo26" minSdkVersion 21 targetSdkVersion 26 } }

compileSdkVersion 26告诉编译器使用 API 26 的系统库来编译代码，targetSdkVersion 26声明应用运行时的目标系统行为。这两个值如果和离线包里的platforms/android-26对不上，后面编译会直接报平台缺失错误。注意buildToolsVersion不是必须写的，AGP 会自动挑选本地已装的合适版本，手动指定反而可能在换机器后因为版本名不一致而报错。

4.2 命令行编译：gradlew assembleDebug --offline

工程目录准备好后，用 Gradle Wrapper 执行编译。--offline参数是离线编译的关键，它禁止 Gradle 访问网络仓库，强制使用本地缓存。

# 进入工程根目录，执行 Debug 包编译，全程离线 cd demo26 ./gradlew assembleDebug --offline

assembleDebug会依次执行资源编译、Java 编译、dex 转换、APK 打包等多个任务。--offline打开后，Gradle 如果在本地缓存里找不到某个依赖，会直接报错而不是尝试联网，这样反而更容易暴露问题。首次执行时会比较慢，因为 Gradle 需要初始化 daemon 进程并解压依赖缓存，这是正常现象。

编译成功后，APK 会输出到app/build/outputs/apk/debug/app-debug.apk。安装到设备上可以直接用adb install：

# 连接设备后安装 APK，验证整条链路真正可用 $ANDROID_HOME/platform-tools/adb install -r app/build/outputs/apk/debug/app-debug.apk

-r参数表示覆盖安装同包名应用，适合反复调试的场景。

4.3 编译不过时先看这三个阶段：aapt2、javac、D8

离线构建报错时，不要盯着红色日志从头看，先定位错误发生在哪个阶段。整个构建过程从高到低可以拆成三个阶段，每个阶段报错的特征和排查方向完全不同。

aapt2是第一阶段，负责处理res目录下的资源和AndroidManifest.xml。报错信息里通常会出现资源文件路径，比如res/values/strings.xml或 layout 文件相关问题，常见原因是 XML 格式错误、引用不存在的资源 ID。javac是第二阶段，负责把 Java 源码编译成 class 文件。这里报错就是纯粹的代码语法或类型问题，日志会直接指出MainActivity.java的哪一行出错。D8是第三阶段，负责把 class 文件转换成 dex 格式。这里报错通常和方法数超限、重复类、库冲突有关。

定位到你当前所处的阶段，再去翻对应代码，效率比从头读日志高很多。这也是熟手和新人拉开差距的地方——新人看报错，熟手看阶段。

5. 离线 SDK 的五个高频坑：翻车现象、原因与处理

离线 SDK 和在线 SDK 用起来最大的区别就是没有后悔药：在线环境缺什么组件可以随时下载补装，离线环境缺了只能手动搬。下面这五个坑是我在多个内网环境里反复见过的，每条都是真实翻车记录，按「现象 → 原因 → 解决」说明白。

5.1 sdkmanager 报错找不到 SDK 根目录

现象：执行sdkmanager --list_installed时，终端提示找不到 SDK 或cmdline-tools目录为空。

原因：压缩包解压后出现两层目录嵌套，SDK 实际路径是/opt/android-sdk/android-sdk-26_1_1而不是/opt/android-sdk。sdkmanager 读取的是ANDROID_HOME指到的路径，如果该路径下没有cmdline-tools，它当然找不到。

解决：用find /opt/android-sdk -name sdkmanager定位实际位置，然后把环境变量和local.properties指向这一层。如果希望统一路径，就把嵌套层里的内容全部上移一层：

# 将嵌套目录内容上移，使 platforms、build-tools 直接位于 SDK 根目录 mv /opt/android-sdk/android-sdk-26_1_1/* /opt/android-sdk/ rmdir /opt/android-sdk/android-sdk-26_1_1

5.2 aapt2 段错误或日志乱码

现象：资源编译阶段aapt2崩溃，终端输出片段有乱码，或者直接提示段错误。

原因：build-tools版本和当前操作系统的 glibc 版本不兼容。越老旧的build-tools在越新的 Linux 发行版上越容易出这类问题；另外也常见于压缩包传输损坏导致二进制文件不完整。

解决：先确认aapt2能独立运行——执行aapt2 version。如果连版本号都输出不了，说明二进制本身有问题，换一个build-tools目录重新拷贝进来。如果aapt2 version正常但编译崩溃，检查系统是否缺少 32 位兼容库。这是离线环境特有的坑，在线环境直接换版本重装就行，离线时你只能手动补。

5.3 D8 报 invoke-custom 错误，lambda 表达式编不过

现象：代码里用了 Java 8 的 lambda 表达式，D8阶段报错，提示invoke-custom相关的内容。

原因：老版本build-tools自带的 D8 编译器对 Java 8 语法支持不完整，需要显式开启 desugar 字节码脱糖处理。

解决：在app/build.gradle里补齐compileOptions配置，强制 AGP 启用 Java 8 语法支持：

// 开启 Java 8 支持，让 lambda 表达式能够正确脱糖编译 compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 }

这段配置在 API 26 的老项目里经常被遗漏，因为很多老工程模板默认用的是 Java 6 兼容模式。加上之后 lambda 就能被正确转换。如果加了还报错，检查build-tools版本是否过于陈旧，考虑升级到更新一版的build-tools目录。

5.4 Gradle 离线编译提示无法解析依赖

现象：执行./gradlew assembleDebug --offline时，报错信息是Could not resolve all artifacts for configuration。

原因：--offline模式下 Gradle 只能从本地缓存读取依赖，如果你的工程用了某个库但本地缓存里没有，它不会试图联网而是直接失败。

解决：在能联网的机器上先把工程完整编译一遍，让 Gradle 把所有依赖下载到本地缓存，然后把整个 Gradle 缓存目录（通常位于用户主目录下的.gradle/caches）拷贝到内网机器。这样离线环境就能解析到全部依赖。注意缓存目录路径要保持一致，否则 Gradle 认不出。

5.5 解压后没有 platforms/android-26，编译报平台缺失

现象：compileSdkVersion 26配置无误，但 Gradle 报错说找不到platforms;android-26这个组件。

原因：压缩包名虽然带26，但内部实际可能只打包了build-tools和platform-tools，忘了放platforms/android-26目录。命名与内容不一致，这是第三方打包的离线 SDK 常见的问题。

解决：用find /opt/android-sdk -name android.jar确认android.jar是否存在。如果没有，需要从其他机器上把platforms/android-26整个目录拷贝进来：

# 从其他环境复制 platform 目录到当前 SDK 根目录 cp -r /mnt/usb/archive/platforms/android-26 /opt/android-sdk/platforms/

拷贝完成后重新执行aapt dump badging /opt/android-sdk/platforms/android-26/android.jar验证完整性。

6. 一个 check_sdk.sh 把环境检查变成团队默认动作

每次接到新机器、新离线包，与其手工敲命令逐项验证，不如把验证逻辑写成一个冒烟脚本，放进工程仓库或 CI 流程里。这个脚本把前面所有关键检查点收敛成一次执行，几分钟内就能断定环境是否可用。

#!/usr/bin/env bash # 离线 Android SDK 冒烟检查脚本：全部输出 [OK] 才代表环境可用 set -euo pipefail SDK_ROOT="${ANDROID_SDK_ROOT:-/opt/android-sdk}" fail_count=0 check() { local name="$1" local path="$2" if [ -e "$path" ]; then echo "[OK] $name -> $path" else echo "[FAIL] $name -> $path" fail_count=$((fail_count + 1)) fi } check "platform android-26" "$SDK_ROOT/platforms/android-26/android.jar" check "build-tools aapt2" "$SDK_ROOT"/build-tools/*/aapt2 check "platform-tools adb" "$SDK_ROOT/platform-tools/adb" check "cmdline-tools sdkmanager" "$SDK_ROOT"/cmdline-tools/latest/bin/sdkmanager if [ "$fail_count" -eq 0 ]; then "$SDK_ROOT"/build-tools/*/aapt2 version >/dev/null 2>&1 && echo "[OK] aapt2 可运行" "$SDK_ROOT"/platform-tools/adb version >/dev/null 2>&1 && echo "[OK] adb 可运行" echo "SDK 环境验证通过" else echo "SDK 环境不完整，共 $fail_count 个失败项，按上方 [FAIL] 条目补齐" exit 1 fi

脚本逻辑很简单：先检查四个关键路径是否存在，再实际执行两个关键工具验证可运行性。set -euo pipefail保证脚本在遇到未定义变量或命令失败时立刻退出，不会带着错误继续跑下去。fail_count用来汇总失败项，最后统一报告，比逐个检查更直观。

把这个脚本放到项目根目录，命名为check_sdk.sh，新同学入职第一件事就是跑它。我自己的习惯是每拿到一个新的离线 SDK 压缩包就先复制这个脚本进去，跑一遍再决定要不要给团队分发。曾经因为忽略一个platforms目录缺失，害得同事排查了整整一下午，后来这个脚本就成了团队默认动作。希望帮到你。

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