企业官网建设流程全解析

简介：android-sdk-platforms-34and35 是一份面向 Android 应用开发者的 SDK 平台资源，完整涵盖 API 级别 34 与 35 的开发工具、库和接口文档，适合需要适配新版系统、利用新特性或排查兼容性问题的开发者。压缩包共 2000 个文件，以 1974 个 XML 配置描述文件为主体，辅以 22 个 HTML 页面和 4 个 TXT 说明文档，整体大小约 121.6MB，便于离线查阅和本地构建环境配置。文件系统整理了 Android 34/35 平台的核心组件定义、API 参考、版本差异说明以及示例代码，资源中还涉及 SDK Manager、模拟器、AVD 管理器等配套工具的描述，帮助开发者快速定位类与方法的变化。目前已有 383 人学习下载，适合在平台升级或新项目初始化时作为基础参考资料，为处理新 API 迁移和保持应用兼容性提供支持。 前阵子换了台开发机，重新搭 Android 环境，SDK Manager 里一眼扫过去，platforms 目录下躺着两个平台包：Android 14（API 34）和 Android 15（API 35）。这种“android-sdk-platforms-34and35”的组合命名，在很多预配置镜像、CI 构建环境或者离线 SDK 包里很常见，但不少刚开始接触 Android 开发的同学看到 platforms 目录里一堆 android-xx 文件夹，并不知道它们到底是干嘛的，更不清楚 API 34、API 35 这些版本号是怎么影响编译和运行的。

这篇文章我就从 platforms-34and35 这个具体场景切入，把 Android SDK 平台包的作用、版本选择逻辑、安装配置流程，以及日常开发中跟这两个 API Level 强相关的坑一次性讲清楚。内容偏向实战，适合刚入门的开发者按步骤操作，也适合被 SDK 版本问题折磨过的老手查漏补缺。

1. platforms-34and35 到底是一堆什么文件

1.1 平台包的本质：给编译器看的“系统镜像”

Android SDK 的安装目录按功能拆成了好几块，很多人只认识 platform-tools（里面有 adb）和 build-tools（里面有 aapt2、zipalign），但真正决定“你这个 App 能调用到哪个版本的系统 API”的，是 platforms 目录下的 android-34、android-35 这些文件夹。每个文件夹对应一个 API Level，里面装着android.jar，也就是 Android 框架层的编译用接口库。

打个比方，android.jar就像一本“系统 API 字典”。编译器在编译你的代码时，会拿这本字典去核对Activity、NotificationManager、PackageInstaller这些类和方法是否存在、签名是否匹配。你写的代码里用了 API 35 才加入的NotificationManager新方法，那么compileSdk至少要指向 35，否则编译直接报“找不到符号”。

这就是为什么本地 SDK 里 platforms 目录会同时存在多个版本，因为不同项目用的 compileSdk 可能不一样。有的项目还锁在 API 33，有的已经升到 35，平台包之间互不干扰，各自目录下都是完整的编译接口。

1.2 Android 14 与 Android 15：API Level 和版本名的对应关系

很多新手会被版本号绕晕：Android 14 对应 API Level 34，Android 15 对应 API Level 35。命名上，谷歌从 Android 11 开始弱化了甜品名，直接叫 Android 14、Android 15，但 API Level 是另一套数字体系，从 1 一直递增到现在的 35、36。

实际开发中，你需要关心的不是手机系统怎么叫，而是compileSdk这个编译目标版本。应用商店和系统兼容性上，Google Play 对 targetSdkVersion 有硬性要求，新上架或更新 App 必须指向较新的 API Level，这也是为什么哪怕你的 App 最低支持 Android 8，编译时也要装 API 34 或 35 的平台包。

2. 为什么一个 SDK 里要同时保留 34 和 35

2.1 compileSdk、minSdk、targetSdk 三兄弟的职责划分

要理解为什么 platforms 目录里 34、35 会同时存在，必须搞清楚 Gradle 构建时三个参数的差异：

• compileSdk：告诉编译器用哪个 API Level 的android.jar来校验代码。这个值只影响编译，不影响运行。它必须大于等于你要用的所有 API。
• minSdk：App 能安装的最低系统版本。低版本系统上，高版本 API 需要通过版本判断或兼容库来规避。
• targetSdk：告诉系统你是按哪个版本的行为规范开发的。系统会对这个值做兼容处理，比如 Android 14 默认对 targetSdk 34+ 的 App 启用前台服务类型校验。

三者的典型关系是minSdk <= targetSdk <= compileSdk。比如一个项目 minSdk 是 26，targetSdk 是 34，compileSdk 是 35，那么编译时需要的是 android-35 这个平台包，而手机端运行时实际按 targetSdk 34 的规则来。

2.2 什么场景会触发 platforms 目录出现 34 和 35

最直接的情况是，你同时打开过两个项目，一个项目用了compileSdk 34，另一个用了compileSdk 35。Android Studio 的 SDK Manager 会在你同步 Gradle 时自动下载缺失的平台包，两个项目跑一遍，platforms 目录下就会多出两个 android-xx 文件夹。

还有一种典型场景是团队内的项目版本升级过渡期。新项目直接上 API 35，老项目还锁在 API 34，为了保证本机构建环境不变来变去，就干脆把两个都装上。这也是“android-sdk-platforms-34and35”这种组合包在 CI 镜像、预配置环境里高频出现的原因——它要覆盖多项目的构建需求。

注意：别把 platforms 目录和 build-tools 目录搞混。build-tools 里是 aapt2、dx/d8 这些构建工具，它们也分版本，但和 API Level 不是一回事。升级 compileSdk 时，Gradle 会自动选择匹配的 build-tools 版本，一般不需要手动干预。

3. 本地 SDK 平台包的安装与配置实操

3.1 用 Android Studio 图形界面安装平台包

这一步最简单，但有几个细节值得说。打开 Android Studio，进入SDK Manager（macOS 在 Preferences 里，Windows 在 Settings 里），切到SDK Platforms标签页，勾选Android 14 (API 34)和Android 15 (API 35)，点击 Apply 就会自动下载。

如果网络环境不稳，下载经常中断，建议在设置里勾选Show Package Details，只装自己需要的组件，不要无脑全选。特别是 API 35 相关的Android SDK Platform 35是必须勾的，但下面的Sources for Android 35（源码包）和Google APIs镜像，没有特殊需求可以不装，能省不少体积和时间。

安装完成后，用 Android Studio 打开Project Structure（快捷键 Ctrl+Shift+Alt+S / Cmd+Shift+,），在Modules里检查Compile Sdk Version是不是指向了你需要的平台版本。如果这里显示的平台版本左边有警告图标，说明本地没装对应包，Studio 通常会弹出提示让你自动安装。

3.2 命令行安装：sdkmanager 的高效用法

图形界面装一次两次没问题，但你要是负责维护 CI 机器，或者手上项目多，命令行才是正路。SDK Manager 工具本体位于cmdline-tools/latest/bin/sdkmanager，先确保它存在，没有的话从官网下载 command line tools 解压到 SDK 目录下。

# 列出所有可用的平台包，过滤出 Android 14/15 相关 sdkmanager --list | grep "platforms;android-3[45]" # 安装指定的两个平台包 sdkmanager "platforms;android-34" "platforms;android-35"

在 Linux CI 机器上，sdkmanager 经常需要指定 Java 环境，一般配合JAVA_HOME环境变量使用。另外，sdkmanager 默认会把包装到ANDROID_SDK_ROOT指定的目录，如果没有设置这个环境变量，它可能找不到 SDK 路径而报错。

export ANDROID_SDK_ROOT=$HOME/Android/Sdk export PATH=$PATH:$ANDROID_SDK_ROOT/cmdline-tools/latest/bin

如果团队使用了 Gradle 的android.builder.sdkDownload机制，也可以直接在项目的local.properties里指定sdk.dir，指向这台机器上 SDK 的实际位置，避免 Gradle 去默认路径找不到。

3.3 Gradle 侧配置和平台包的配合

平台包装好了，还得保证 Gradle 配置能跟它对上。以常见配置为例：

android { compileSdk 35 defaultConfig { applicationId "com.example.demo" minSdk 26 targetSdk 35 versionCode 1 versionName "1.0" } }

这里的compileSdk 35对应本地 platform 的 android-35。如果你用 Kotlin DSL，写法是compileSdk = 35。

一个我踩过的坑：项目里同时存在多个 Module 时，每个 Module 都可能声明自己的compileSdk。主工程是 35，某个 library 模块还是 34，Gradle 同步时就会尝试下载 android-34。如果你的平台包里只有 35，构建很可能报 “Failed to find target with hash string 'android-34'”。解决办法是统一所有模块的 compileSdk，或者在根项目的gradle.properties里加上：

android.suppressUnsupportedCompileSdk=35

这个属性是告诉 Gradle 允许项目使用某个 compileSdk，避免因为 AGP 和 compileSdk 版本不匹配导致同步失败。但要注意，它只是压制警告，不能从根本上解决 AGP 版本过旧不支持新 compileSdk 的问题。

4. 配置过程中的高频问题与避坑记录

4.1 SDK Tools 里没有 HAXM：旧的模拟器加速器该扔了

在 SDK Manager 的 SDK Tools 标签页里，很多人会习惯性找Intel x86 Emulator Accelerator (HAXM)，发现列表里根本没有这个选项。这不是你装坏了，是 HAXM 已经被谷歌废弃了。Android Emulator 现在默认用 Hypervisor Framework（macOS）和 Windows Hypervisor Platform（Windows）来做硬件加速，不再需要单独装 HAXM。

如果你在启动模拟器时遇到 “HAXM is not installed” 之类的历史遗留提示，直接去 SDK 目录下把extras/intel/Hardware_Accelerated_Execution_Manager文件夹删掉，然后在 Android Studio 里开启系统自带的虚拟化支持，重启模拟器即可。Windows 用户需要在“启用或关闭 Windows 功能”里勾选Windows Hypervisor Platform，别和 WSL2 的 Hyper-V 混了，两者可以共存，但模拟器必须使用同一个底层虚拟化方案。

4.2 “An error occurred while preparing SDK package” 与 16 KB 页面大小

这个报错在更新 API 35 平台包时出现的概率很高。表面上看是安装中断或者磁盘权限问题，但有个容易被忽略的原因：API 35 开始，谷歌强制要求 App 和系统库适配 16 KB 内存页面大小，如果项目里的原生库还是按 4 KB 页面编译的，有些构建检查就会失败，甚至影响 SDK 包本身的安装流程。

处理思路分两步。第一步，确认磁盘空间和读写权限，这个最常见：

# macOS/Linux 查磁盘空间 df -h /path/to/Android/Sdk

第二步，如果空间和权限都没问题，考虑是不是 Gradle 检测到项目使用旧版原生库导致准备阶段异常。此时检查build.gradle里是否有jniLibs相关配置，把useLegacyPackaging等参数统一到较新规范。对大多数纯 Java/Kotlin 项目来说，这个报错还是以网络或权限为主，重试一两次、换个网络环境基本能解决。

4.3 一堆版本不匹配：AGP、HBuilderX、第三方 SDK 的对齐思路

热词里提到“uniapp本地打包sdk版本与hbuilderx版本”不匹配，这类问题本质上是版本矩阵问题。Android 生态的版本耦合特别紧密：AGP 版本决定能支持的 compileSdk 上限，较老的 AGP 遇到 API 35 可能直接报 “We recommend using a newer Android Gradle plugin”。HBuilderX 这类跨端工具自带的 SDK 同样有版本约束，本地打包时如果用了比工具更新（或更旧）的 Android SDK 平台包，一样会打包失败。

我的处理顺序是固定的：

1. 先看项目的 AGP 版本，去官网对照支持矩阵，确认当前 AGP 是否支持目标 compileSdk。
2. 然后看跨端工具（HBuilderX、Flutter 等）要求的 SDK 版本范围，通常工具发行说明里会写。
3. 最后才决定 platforms 目录下装哪个 API Level，而不是先装了再说。

举个例子，某项目 AGP 是 7.4.2，它最高稳定支持 compileSdk 34，如果你强行把 compileSdk 改成 35，Gradle 会提示 AGP 版本过旧，此时要么升级 AGP，要么把 compileSdk 降回 34。多数情况下先升 AGP 是更合理的路径，因为第三方的targetSdk和compileSdk很可能也已经跟进到 35。

提示：如果是在公司内网或半离线环境，sdkmanager 下载反复失败，推荐直接找一个包含 platform 包在内的完整离线 SDK 压缩包。注意压缩包里的platforms目录是放到 SDK 根目录下的platforms文件夹里，不要解压到别处。解压后执行一次sdkmanager --licenses接受许可协议，再重新同步 Gradle。

4.4 平台包明明装了，Gradle 还是说 Missing SDK

这个问题也很经典。local.properties里的sdk.dir指向了错误路径，或者环境变量ANDROID_HOME/ANDROID_SDK_ROOT比local.properties的优先级还高。Gradle 的规则是：local.properties优先于环境变量，但如果你压根没写local.properties，它才会去找环境变量。

排查方法是打开终端，手动切到项目根目录后执行：

# macOS/Linux echo $ANDROID_HOME echo $ANDROID_SDK_ROOT # 查看 local.properties cat local.properties

确认这些路径都指向同一个 SDK 根目录，尤其注意不能指到platforms或cmdline-tools这一层。我见过有人把ANDROID_HOME指到…/platforms底下，结果 Gradle 找platform-tools时直接报错，平台包装得再全也没用。

5. 一点实操体会

开发环境这个东西，永远是“一次配好，长期受益”。把 android-34 和 android-35 两个平台包同时留在本地，看起来很占空间，其实每个包也就一两百 MB，换来的是切换项目时的省心。特别是现在很多开源库、第三方 SDK 已经逐步把targetSdk和compileSdk推到 35，你手头如果还只有老的平台包，拉新项目的第一件事就会卡住。与其每次被 Gradle 提示打乱节奏，不如一次性把 34 和 35 都备好，再把 AGP 版本提到最新稳定版。

最后补一个自己的小习惯：每次升级环境后，我会在 SDK 目录下跑一遍sdkmanager --list_installed，看看到底装了哪些包。这个命令输出很干净，接口版本、build-tools 版本、platform-tools 版本一目了然，比在 Studio 界面里点来点去直观得多。

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