企业官网建设流程全解析

简介：这份名为 Android SDK（SDK Platforms）-android-34 的压缩包，是开发 Android 13 应用时不可或缺的平台组件包。Android 13 对应 API 级别 33，开发者借助该平台包可获得最新系统接口、系统服务以及框架层的完整定义，适合需要在本地搭建新版 SDK、离线编译与调试项目的 Android 工程师，可避免下载平台文件缓慢或缺失导致的构建失败问题。压缩包共收录一万零九百六十四个文件，以六千三百六十二个图片资源和四千四百九十五个界面配置为主，png 存放应用图标与界面素材，xml 描述界面布局和资源配置，同时包含接口描述、样式布局、说明文档、程序库与底层头文件，整体容量六十点七七兆字节。截至目前，已有一千五百二十二人学习下载，可作为 Android Studio 配置离线 SDK 的备选素材。解压后，开发者能从框架接口定义、资源分类目录、着色器与模板文件中，系统了解 Android 十三的平台结构，为多版本共存、持续集成或底层调试提供完整依赖。

1. android-34 平台包：你下载的不是一个 zip，而是编译器的“目标靶子”

如果你曾经在 Android Studio 的 SDK Manager 里盯着 “Android SDK (SDK Platforms)” 这一栏发愣，大概率是因为你只想要一个能跑的模拟器，结果却被一堆 API Level 搞晕了。Android SDK (SDK Platforms)-android-34.zip这个标题看起来像是一个下载文件的名称，实际上它描述的是 Android 34 对应的一套系统镜像与编译接口。简单说，android-34 平台包是 Android 14（API 34）的“编译目标”：当你用compileSdk 34编译项目时，Gradle 需要从这个平台包里读取android.jar，它定义了该版本公开的 API 方法与资源 ID。没有它，编译器会报android.jar not found或直接提示你安装缺失的平台。

这个 zip 适合两类人：一类是手动管理 SDK 目录、讨厌 Android Studio 自动下载的工程师；另一类是 CI 环境里需要离线安装 SDK 平台包的运维。你不需要下载整个 Android Studio，只需要把这个 zip 解压到指定目录，并让ANDROID_HOME指向它，命令行工具链就能正常工作。接下来我按“平台包内部结构 → 安装与配置 → 排错 → 验证”这条线，把这件事彻底讲明白。

2. SDK Platforms 与 android-34 的内部结构：先搞懂你解压了什么

2.1 为什么 API 34 需要单独的 platform 包

Android SDK 按“平台（Platforms）”划分，每个 API Level 对应一个独立的目录，例如platforms/android-34。这个目录并不包含模拟器镜像，也不包含构建工具，它只包含三样关键东西：android.jar（你编译时引用的系统类库）、data/（一些资源与权限定义）、以及source.properties（记录该平台版本信息的属性文件）。Gradle 构建时，compileSdkVersion指向哪个 API Level，就会去对应的 platform 目录找android.jar。如果你装了 API 33 却把compileSdk设成 34，构建会直接失败，因为编译器找不到目标接口。

有人会问，直接用 Android Studio 自动下载不是更省事吗？是的，但自动下载有前提：它把平台包放在 SDK 根目录的platforms/下，如果你在 IDE 里改了 SDK 位置或者使用自定义的本地 SDK，勾选界面会出现“无法勾选”或下载按钮置灰的情况。这时候手动下载 zip 解压反而更可控。另外，CI 环境用 Docker 镜像构建时，离线安装 zip 比每次执行sdkmanager去拉网络更稳定，因为网络波动或存储库变更都会导致任务失败。

2.2 android-34.zip 解压后的目录清单与作用

下载并解压android-34.zip后，你通常得到一个名为android-34的目录。我建议你把它放在 SDK 根目录的platforms/下，这样最终路径类似D:\Android\Sdk\platforms\android-34。下面是该目录的关键内容：

这里有一个常见的误区：把 platform 包和 build-tools 混为一谈。platforms/android-34只是“靶子”，真正把 Java 源码编译成 DEX 字节码的是build-tools/34.0.0中的d8或aapt2。如果你只装了 platform 包，依然无法打包 APK。所以实际项目里，你至少需要 platform、build-tools、platform-tools（包含 adb）三样。但对于纯依赖编译（比如写一个依赖 Android 类的 Java 库），只装 platform 就够了。

2.3 手动放置 platform 包时对目录权限的要求

如果你在 Windows 上手动把 zip 解压到C:\Program Files\Android\Sdk\platforms\目录，可能会遇到访问被拒绝或文件只读的问题。因为Program Files受系统保护，Android 构建进程写入临时文件时会失败。我一般会避免把 SDK 放在系统盘的系统目录下，而是选择C:\Android\Sdk或D:\Software\Sdk。这类路径没有 UAC 拦截，后续安装 system image、写platforms目录都顺畅很多。

3. 用 sdkmanager 和命令行把 android-34 平台装到指定位置

3.1 sdkmanager 的最小可用命令

如果你已经安装了 Android Studio 或单独的命令行工具，最常见的安装方式是在 SDK 根目录下执行：

# 在 SDK 根目录下执行，或把 sdkmanager 所在路径加入 PATH sdkmanager "platforms;android-34"

这个命令会从 Google 的仓库下载 android-34 平台包并自动安装到当前 SDK 的platforms目录下。注意引号内的分号是 Windows 风格的分隔符；在 Linux/macOS 下同样适用，因为 sdkmanager 统一使用分号。执行过程中会看到下载进度条，结束后可以用sdkmanager --list_installed验证。

如果你的网络环境无法直接访问 Google 仓库，或者公司内网需要走镜像，可以设置代理参数：

# 指定 HTTP 代理主机与端口 sdkmanager --proxy=http --proxy_host=proxy.example.com --proxy_port=8080 "platforms;android-34"

sdkmanager还支持--channel参数指定渠道，--channel=0表示稳定版，--channel=1包含预览版。对于 android-34 这种正式版平台，用默认的稳定渠道即可。设置代理后，建议同时给 Gradle 配置代理环境变量，否则下载依赖时依然卡住，但那是另一个话题了。

3.2 离线安装 zip：直接把 android-34.zip 放到本地仓库

如果你拿到了Android SDK (SDK Platforms)-android-34.zip这个文件，想离线安装，不需要跑任何安装器，只要解压并复制到正确位置即可。假设你的 SDK 根目录是D:\Software\Sdk，步骤如下：

# 1. 创建 platforms 目录（如果不存在） mkdir -p /d/Software/Sdk/platforms # 2. 解压 zip，得到一个名为 android-34 的目录 unzip android-34.zip -d /tmp/android-34-extract # 3. 移动到你 SDK 的 platforms 目录下 mv /tmp/android-34-extract/android-34 /d/Software/Sdk/platforms/android-34

在 Windows 上，第三条命令等价于用资源管理器剪切粘贴。关键点是：platforms目录下直接存放android-34文件夹，而不是把 zip 再嵌套一层。很多新手把 zip 解压后得到android-34，然后又包了一层同名文件夹，导致 Gradle 找不到android.jar。检查方法很简单，看platforms/android-34/android.jar是否存在。

3.3 使用 Gradle 自动下载时如何指定本地 platform 路径

如果你不想手动管理 SDK 目录，可以让 Gradle 自动下载 platform。在android模块的build.gradle中设置：

android { compileSdk 34 // 其余配置 }

Gradle 会根据compileSdk自动寻找已安装的 platform；如果没找到，Android Gradle Plugin 会尝试通过 SDK Manager 自动下载，前提是local.properties或环境变量ANDROID_HOME正确指向 SDK 根目录。这里有个隐藏的坑：Android Gradle Plugin 只能下载它自带的 SDK 组件版本列表里的东西，如果你指定compileSdk 35但你的 AGP 版本过老，它可能会提示 “Failed to find target with hash string 'android-35'”。这时建议在local.properties里写入：

sdk.dir=D\:\\Software\\Sdk

注意 Windows 路径中反斜杠要转义或用正斜杠。这种写法比设置全局环境变量更精确，因为不同项目可能使用不同 SDK 位置。

4. 必调的 3 个参数与常见故障处理

4.1ANDROID_HOME与ANDROID_SDK_ROOT到底设哪个

网上很多帖子叫你同时设置ANDROID_HOME和ANDROID_SDK_ROOT，实际上 Android 构建工具链对两个变量都有支持，但不同工具读的优先级不同。ANDROID_HOME是旧版工具（如adb、emulator）常用的变量，而新版 Android Gradle Plugin 更倾向于读取local.properties中的sdk.dir。如果命令行工具找不到 SDK，常见报错信息是：

ERROR: ANDROID_HOME = D:\Software\Sdk but Android SDK not found at this location.

这个报错很迷惑，因为你明明把 SDK 放在了那个路径。原因通常是ANDROID_HOME指向的目录不包含platform-tools或platforms子目录，或者路径中的空格、大小写导致解析失败。你可以先验证目录结构：

ls $ANDROID_HOME # 预期输出：build-tools platforms platform-tools system-images

如果没有platform-tools，说明你的 SDK 根目录并不完整，需要先安装 platform-tools 而不是 platform 包。另外，在 Linux/macOS 上，ANDROID_HOME必须指向你自己有读写权限的路径，如果你把它指向/usr/local/android-sdk，且当前用户没有写权限，sdkmanager 会报 Permission denied。

4.2 Android Studio 中 SDK 无法勾选的解决方法

许多人在 Android Studio 的 SDK Manager 里看到 “Android SDK (SDK Platforms)” 列表里 android-34 是灰色或勾选不了，即使点了 “Apply” 也没有反应。这种情况多半是 IDE 的 SDK 目录写保护，或者你已经手动在platforms目录下放了一个不完整的android-34文件夹。Android Studio 检测到该目录存在但缺少source.properties，就会视为无效安装，拒绝让你勾选。

处理方法是先删除无效的platforms/android-34目录，再重新通过 SDK Manager 安装，或者确认解压的 zip 中有source.properties。你也可以在 Android Studio 中点击 “Edit” 修改 SDK 位置，重新指定一个空目录，让 IDE 完整重建。此外，Windows 上如果 SDM 还出现“无法勾选”，可以尝试以管理员身份运行 Android Studio，因为某些系统目录权限会阻止 SDK 写入。

4.3 更改模拟器下载的 SDK 安装位置

很多用户会问：Android Studio 模拟器下载的 system image 默认放在 SDK 的system-images目录下，怎么更改位置？其实 system image 也是 SDK 组件的一部分，修改它的下载位置就等于修改整个 SDK 目录。如果你希望把大小动辄 1GB 以上的镜像放到其他盘，做法是：

1. 在 Android Studio 的File > Settings > Appearance & Behavior > System Settings > Android SDK中，修改 “Android SDK location” 为一个新路径。
2. 把旧 SDK 目录下的platforms、build-tools、platform-tools、system-images等子目录迁移到新路径。
3. 更新项目级local.properties中的sdk.dir，或在环境变量中修改ANDROID_HOME。

迁移时不要用剪切整个 SDK 文件夹的方式，因为 Windows 的文件句柄占用可能导致残留。我一般用robocopy（Windows）或rsync（macOS/Linux）同步，完成后删除旧目录。注意模拟器的 AVD 配置（.avd文件）默认存放在C:\Users\你的用户名\.android\avd，与 SDK 位置无关，所以更改 SDK 位置不会影响已有模拟器，只是它们指向 system image 的路径会失效，需要重新选择镜像或复制镜像到新位置。

4.4 命令行报错 “SDK not found” 的排查清单

如果你在 CI 容器中运行，完全可以省略环境变量，直接在local.properties写死路径，因为构建机器上只有一个项目。

5. 验证 android-34 是否生效的三种做法

5.1 用sdkmanager检查已安装平台

安装完成后，第一件是检查 sdkmanager 是否识别这个平台包：

sdkmanager --list_installed | grep "platforms;android-34" # 输出：platforms;android-34 | 2 | 14.0 | Android SDK Platform 34

如果没有任何输出，检查你是否把平台包放在正确的位置，或者是否与其他 SDK 目录冲突。sdkmanager会读取当前 SDK 根目录下的.knownPackages或通过目录扫描识别，手动解压的包也能被识别，只要source.properties存在。

5.2 用aapt查看平台的 Android 版本信息

build-tools/34.0.0/aapt工具可以 dump 一个 APK 的信息，也可以验证android.jar是否存在。但更直接的方式是读取source.properties：

cat $ANDROID_HOME/platforms/android-34/source.properties # 输出类似： # Platform.Version=14 # AndroidVersion.ApiLevel=34 # Pkg.Revision=2

看到ApiLevel=34就说明安装正确。如果你用compileSdk 34编译项目，Gradle 会在构建日志中打印 “Using Android SDK: <SDK路径>” 和 “compileSdkVersion 34”，也可以作为佐证。

5.3 在 Gradle 构建中确认编译通过

最彻底的验证是运行一次./gradlew assembleDebug。如果没有报 “Unable to resolve dependency” 或 “Failed to find target android-34”，说明 platform 包与构建工具匹配上了。但要注意一个细节：如果你安装了 platform 34，却使用旧版 build-tools（比如 30.0.3），aapt2可能无法处理 API 34 的资源属性，导致编译失败。建议同时安装build-tools;34.0.0，并在build.gradle中显式指定：

android { buildToolsVersion "34.0.0" compileSdk 34 }

如果你用命令行构建而不想打开 Android Studio，推荐把$ANDROID_HOME/build-tools/34.0.0加入PATH，这样aapt2、zipalign等工具可直接使用。至此，一个从 zip 到可编译 SDK 的完整闭环就打通了。

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