Android SDK platforms-34and35 安装配置与避坑指南

简介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 14API 34和 Android 15API 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 15API Level 和版本名的对应关系很多新手会被版本号绕晕Android 14 对应 API Level 34Android 15 对应 API Level 35。命名上谷歌从 Android 11 开始弱化了甜品名直接叫 Android 14、Android 15但 API Level 是另一套数字体系从 1 一直递增到现在的 35、36。Android 版本API Level平台包目录名主要变化Android 1333android-33通知权限细化、照片选择器Android 1434android-34前台服务类型要求、16KB 页面适配预告Android 1535android-3516KB 页面强约束、部分权限默认限制实际开发中你需要关心的不是手机系统怎么叫而是compileSdk这个编译目标版本。应用商店和系统兼容性上Google Play 对 targetSdkVersion 有硬性要求新上架或更新 App 必须指向较新的 API Level这也是为什么哪怕你的 App 最低支持 Android 8编译时也要装 API 34 或 35 的平台包。2. 为什么一个 SDK 里要同时保留 34 和 352.1 compileSdk、minSdk、targetSdk 三兄弟的职责划分要理解为什么 platforms 目录里 34、35 会同时存在必须搞清楚 Gradle 构建时三个参数的差异compileSdk告诉编译器用哪个 API Level 的android.jar来校验代码。这个值只影响编译不影响运行。它必须大于等于你要用的所有 API。minSdkApp 能安装的最低系统版本。低版本系统上高版本 API 需要通过版本判断或兼容库来规避。targetSdk告诉系统你是按哪个版本的行为规范开发的。系统会对这个值做兼容处理比如 Android 14 默认对 targetSdk 34 的 App 启用前台服务类型校验。三者的典型关系是minSdk targetSdk compileSdk。比如一个项目 minSdk 是 26targetSdk 是 34compileSdk 是 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 ManagermacOS 在 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快捷键 CtrlShiftAltS / CmdShift,在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 模块还是 34Gradle 同步时就会尝试下载 android-34。如果你的平台包里只有 35构建很可能报 “Failed to find target with hash string android-34”。解决办法是统一所有模块的 compileSdk或者在根项目的gradle.properties里加上android.suppressUnsupportedCompileSdk35这个属性是告诉 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 FrameworkmacOS和 Windows Hypervisor PlatformWindows来做硬件加速不再需要单独装 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 平台包一样会打包失败。我的处理顺序是固定的先看项目的 AGP 版本去官网对照支持矩阵确认当前 AGP 是否支持目标 compileSdk。然后看跨端工具HBuilderX、Flutter 等要求的 SDK 版本范围通常工具发行说明里会写。最后才决定 platforms 目录下装哪个 API Level而不是先装了再说。举个例子某项目 AGP 是 7.4.2它最高稳定支持 compileSdk 34如果你强行把 compileSdk 改成 35Gradle 会提示 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 界面里点来点去直观得多。本文还有配套的精品资源点击获取