简介本资源为 Android SDK 的 android-33 平台包对应 Android 13API 33版本面向 Android 应用开发者、移动端学习者及需要适配新系统特性的工程人员。将其解压后放入 SDK 的 platforms 目录即可在 Android Studio 等 IDE 中选择该版本进行编译、调试与测试解决目标版本缺失或接口不兼容的问题。压缩包共约 2000 个文件以 xml 资源定义与配置清单为主辅以 html 说明文档和少量 txt 文本整体约 60.84MB结构完整便于直接集成到本地 SDK 环境。目前已有 852 人学习下载。借助该平台包开发者可获取 Android 33 的系统库与 API 文档结合 Platform Tools、Build Tools 等组件完成应用构建与设备调试确保编译产物与 Android 13 特性和接口保持兼容提升开发与适配效率。1. android sdk android-33为什么你的构建突然找不到平台了如果你最近在 CI 上看到Failed to find target with hash string android-33或者本地sdkmanager里明明装了 API 33 却仍然报platform not found那你不是一个人。android sdk android-33这个组合背后其实是一整套 Android 构建链的版本对齐问题编译 SDK 版本、构建工具版本、Gradle 插件版本、JDK 版本四者只要有一个错位构建就会以各种看似无关的报错翻车。它解决的核心诉求很具体——让项目在 API 33Android 13这个编译目标上稳定跑通而不是每次升级都靠玄学重装 SDK。适合谁适合正在维护多模块 Android 工程、需要把compileSdk从 31/32 抬到 33 的开发者也适合刚接手一个老项目、被环境问题卡住半天的新手。下面我按“先搞清目录和版本关系再动手装、配、排错”的顺序讲透。2. android-33 到底装了什么目录结构、组件与版本对齐很多人以为装了platforms;android-33就完事了其实 API 33 在 SDK 目录里对应的是好几个独立组件缺一个都可能让构建在某个阶段挂掉。先把“装了什么、放在哪、谁依赖谁”理清楚后面所有命令才有依据。2.1 SDK 根目录下与 android-33 相关的四个位置一个标准的 Android SDK 根目录ANDROID_HOME或ANDROID_SDK_ROOT指向它里和 API 33 直接相关的是这几块目录内容谁在用platforms/android-33/android.jar、framework.aidl、data/资源编译期提供 android.* 类build-tools/33.x.y/aapt2、d8、zipalign、apksigner打包、资源编译、签名platform-tools/adb、fastboot安装调试与 API 版本弱相关cmdline-tools/latest/bin/sdkmanager、avdmanager安装和管理上面这些关键点platforms/android-33只提供编译用的android.jar它不包含aapt2 和 d8。构建时 Gradle 会去build-tools里找这些工具所以只装 platform 不装 build-tools一样会失败。常见做法是让 build-tools 版本不低于 platform 版本对应的推荐值API 33 一般配 33.0.x 或 34.0.x 都能用。2.2 compileSdk、targetSdk、minSdk 三者的区别这是最容易混的一组参数配错了不会立刻报错但会在运行期或上架审核时出问题compileSdk编译时用哪个android.jar。设成 33 就意味着你能调用 API 33 的新类和方法。它只影响编译不影响运行。targetSdk告诉系统“我针对哪个版本做了适配”。系统会据此决定是否启用兼容行为比如通知权限、后台限制。它影响运行期行为。minSdk最低支持的设备版本。低于它的设备装不上。把compileSdk抬到 33 而targetSdk还停在 31是允许的但你就享受不到新版本的适配收益反过来targetSdk高于compileSdk则会直接编译报错。我一般建议三者一起评估别只改一个。2.3 Gradle 插件与 JDK 的版本门槛API 33 对应的 Android Gradle PluginAGP通常要求 7.x 起步而 AGP 7.x 又要求 JDK 11 及以上。如果你还在用 JDK 8 跑 AGP 7会看到类似Unsupported class file major version的报错这个报错和 SDK 一点关系都没有但很多人会误以为是 android-33 没装好。一个可用的组合参考不是唯一解但稳组件建议版本AGP7.4.xGradle7.5JDK11 或 17build-tools33.0.xcompileSdk33提示版本组合没有绝对标准以你项目里gradle-wrapper.properties和build.gradle实际声明为准先对齐再谈装 SDK。3. 用命令行把 android-33 装干净sdkmanager 实操图形化 SDK Manager 在 CI 上不可用而且它经常“显示已安装但实际文件不全”。命令行安装更可控也方便写进流水线脚本。下面这套流程我在多个环境里复现过。3.1 确认 sdkmanager 位置并列出可用包先确认你的cmdline-tools装好了并且sdkmanager能跑起来# 指向你的 SDK 根目录按实际路径改 export ANDROID_HOME$HOME/Android/Sdk export PATH$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$PATH # 确认 sdkmanager 可用 sdkmanager --version # 列出所有与 android-33 相关的可安装包 sdkmanager --list | grep android-33逻辑说明--list会输出已安装和可用的包grep过滤出 API 33 相关项。你会看到platforms;android-33、build-tools;33.0.x等条目。如果sdkmanager --version直接报错说明cmdline-tools没装或路径不对先解决这个再往下走。参数说明ANDROID_HOME是 SDK 根目录cmdline-tools/latest/bin是 sdkmanager 所在目录。有些旧环境用的是ANDROID_SDK_ROOT两者都设上更保险。3.2 安装 platform 与 build-tools确认包名后直接安装--sdk_root显式指定根目录避免装到默认位置# 安装 API 33 平台和对应构建工具 sdkmanager --sdk_root$ANDROID_HOME \ platforms;android-33 \ build-tools;33.0.2 \ platform-tools # 接受所有许可CI 上必须做否则会卡在 license 交互 yes | sdkmanager --sdk_root$ANDROID_HOME --licenses逻辑说明第一条命令把 platform、build-tools、platform-tools 一次装齐。第二条用yes自动接受许可协议这是 CI 环境里最常见的卡点——本地手动点过同意CI 上却是全新环境不自动接受就会一直等待输入直到超时。参数说明--sdk_root指定安装根目录包名必须和--list输出完全一致写错会报package not found。build-tools的具体小版本按--list里实际存在的填不要凭记忆写。3.3 验证安装结果装完别急着构建先验证文件真的到位# 检查 platform 是否完整 ls $ANDROID_HOME/platforms/android-33/android.jar # 检查 build-tools 里的关键工具 ls $ANDROID_HOME/build-tools/33.0.2/aapt2 ls $ANDROID_HOME/build-tools/33.0.2/d8 # 用 sdkmanager 再确认一次安装状态 sdkmanager --sdk_root$ANDROID_HOME --list_installed | grep android-33逻辑说明android.jar存在说明 platform 装好了aapt2和d8存在说明 build-tools 完整。最后一条从 sdkmanager 视角确认状态。三步都过SDK 层面基本没问题剩下的报错就该往 Gradle 和 JDK 方向查了。4. 在 Gradle 里正确声明 android-33配置与常见错配SDK 装好了不代表构建就能过Gradle 侧的声明才是决定“用哪个版本编译”的地方。这一章把配置写法和错配排查讲清楚。4.1 build.gradle 里的最小配置模块级build.gradle里和 API 33 相关的核心就几行android { namespace com.example.demo compileSdk 33 defaultConfig { applicationId com.example.demo minSdk 24 targetSdk 33 versionCode 1 versionName 1.0 } buildToolsVersion 33.0.2 // 可选不写则用 AGP 默认 }逻辑说明compileSdk 33告诉 AGP 用platforms/android-33/android.jar编译。targetSdk 33声明适配目标。buildToolsVersion不写时 AGP 会选一个它认为合适的版本但显式写死能避免不同机器上选到不同版本导致行为不一致。参数说明minSdk按你的用户覆盖情况定和 API 33 无强绑定。namespace是 AGP 7 之后替代package属性的写法老项目迁移时要注意。4.2 用 local.properties 或环境变量指定 SDK 路径Gradle 需要知道 SDK 在哪。两种常见方式# local.properties不要提交到版本库 sdk.dir/Users/yourname/Android/Sdk或者靠环境变量ANDROID_HOME。CI 上一般用环境变量本地用local.properties。两者同时存在时local.properties优先级更高。如果路径写错报错通常是SDK location not found和 android-33 本身无关但很容易被误判。4.3 多模块项目里的版本统一多模块工程最容易出现“主模块 compileSdk 33、子模块还是 31”的情况导致子模块编译时找不到新 API。常见做法是在根build.gradle里用ext或 version catalog 统一管理// 根 build.gradle ext { compileSdkVersion 33 buildToolsVersion 33.0.2 minSdkVersion 24 targetSdkVersion 33 }子模块引用rootProject.ext.compileSdkVersion。这样改一处全生效避免漏改。参数说明ext是 Groovy 的动态属性Kotlin DSL 项目里改用extra或 version catalog思路一致。5. 避坑与排查android-33 构建失败的 5 个高频现场这一章是我踩过的坑里出现频率最高的五类每条按“现象 → 原因 → 解决”写照着对号入座能省不少时间。5.1 现象Failed to find target with hash string android-33原因platforms/android-33没装或者装到了另一个 SDK 根目录而 Gradle 指向的是空的那个。多版本 SDK 共存时特别常见。解决先sdkmanager --list_installed | grep android-33确认装在哪再核对local.properties的sdk.dir和ANDROID_HOME是否指向同一个根目录。不一致就统一然后重新同步 Gradle。5.2 现象AAPT2 报错或资源编译失败原因build-tools版本和 AGP 不匹配或者aapt2文件缺失/损坏。有时是下载中断导致文件不完整。解决删掉build-tools/33.0.2整个目录重装命令是sdkmanager --uninstall build-tools;33.0.2再重新 install。同时确认 AGP 版本和 build-tools 大致对应别用太老的 AGP 配太新的 build-tools。5.3 现象Unsupported class file major version 61原因这是 JDK 版本问题不是 SDK 问题。major version 61 对应 JDK 17说明 Gradle 用的 JDK 和 AGP 期望的不一致。解决检查JAVA_HOME和 IDE 里 Gradle JDK 设置统一到 AGP 支持的版本AGP 7.x 用 JDK 11 或 17。改完清一次 Gradle 缓存再构建。5.4 现象本地能构建CI 上一直卡在 license原因CI 是全新环境SDK 许可未接受sdkmanager在等待交互输入。解决在 CI 脚本里加yes | sdkmanager --licenses并且确保这一步在安装组件之前或之后都执行一次。有些镜像预装了 SDK 但没接受许可同样会卡。5.5 现象targetSdk 33 后通知、权限行为变了原因targetSdk抬到 33 会启用 Android 13 的新行为最典型的是通知需要运行时权限POST_NOTIFICATIONS。解决在AndroidManifest.xml声明权限并在运行时请求。这不是构建错误而是行为变更容易被当成 bug。升级targetSdk前先过一遍官方行为变更清单逐条确认。注意排查顺序建议固定为“SDK 文件是否齐全 → 路径是否一致 → Gradle/JDK 版本 → 行为变更”从底层往上查比一上来就改代码高效得多。6. 让 android-33 构建可复现锁定版本与验证脚本前面讲的都是“怎么装、怎么配、怎么排错”但真正让团队少踩坑的是把这套东西固化成可复现的脚本和版本锁定。这一章落到具体技巧上。6.1 用版本目录锁定所有相关版本Gradle 的 version cataloglibs.versions.toml能把 SDK 相关版本集中管理[versions] agp 7.4.2 compileSdk 33 buildTools 33.0.2 minSdk 24 targetSdk 33模块里引用libs.versions.compileSdk.get().toInteger()。好处是版本只在一处定义升级时改一行所有模块同步。参数说明toInteger()是因为 TOML 里读出来是字符串而compileSdk需要整数。6.2 写一个环境自检脚本在 CI 的构建前加一段自检把问题挡在构建之前#!/usr/bin/env bash set -euo pipefail SDK_ROOT${ANDROID_HOME:?ANDROID_HOME not set} # 1. 检查 platform if [ ! -f $SDK_ROOT/platforms/android-33/android.jar ]; then echo 缺少 platforms;android-33开始安装 sdkmanager --sdk_root$SDK_ROOT platforms;android-33 fi # 2. 检查 build-tools if [ ! -f $SDK_ROOT/build-tools/33.0.2/aapt2 ]; then echo 缺少 build-tools;33.0.2开始安装 sdkmanager --sdk_root$SDK_ROOT build-tools;33.0.2 fi # 3. 接受许可 yes | sdkmanager --sdk_root$SDK_ROOT --licenses /dev/null echo android-33 环境自检通过逻辑说明脚本先检查关键文件是否存在缺了才装避免每次全量重装浪费时间。set -euo pipefail保证任何一步失败就退出不会带着半成品继续构建。参数说明${ANDROID_HOME:?...}在变量未设置时直接报错退出比默默用空路径安全。6.3 验证构建真的用了 android-33构建通过不代表用的是 33。想确认可以看构建输出里的compileSdkVersion或者用一条命令反查# 查看 APK 的 targetSdkVersion $ANDROID_HOME/build-tools/33.0.2/aapt2 dump badging app/build/outputs/apk/debug/app-debug.apk \ | grep -E sdkVersion|targetSdkVersion逻辑说明aapt2 dump badging会输出 APK 的清单信息sdkVersion是 minSdktargetSdkVersion是目标版本。确认这两个值符合预期才算真正验证了配置生效。参数说明APK 路径按实际产物改release 包同理。我自己的习惯是每次升级compileSdk或targetSdk先跑一遍自检脚本再构建最后用aapt2 dump badging确认产物三步都过才提交。这套流程帮我挡掉过好几次“本地能跑、CI 挂掉”的尴尬。希望帮到你。本文还有配套的精品资源点击获取 Android SDK android-33 构建失败排查与版本对齐指南
简介本资源为 Android SDK 的 android-33 平台包对应 Android 13API 33版本面向 Android 应用开发者、移动端学习者及需要适配新系统特性的工程人员。将其解压后放入 SDK 的 platforms 目录即可在 Android Studio 等 IDE 中选择该版本进行编译、调试与测试解决目标版本缺失或接口不兼容的问题。压缩包共约 2000 个文件以 xml 资源定义与配置清单为主辅以 html 说明文档和少量 txt 文本整体约 60.84MB结构完整便于直接集成到本地 SDK 环境。目前已有 852 人学习下载。借助该平台包开发者可获取 Android 33 的系统库与 API 文档结合 Platform Tools、Build Tools 等组件完成应用构建与设备调试确保编译产物与 Android 13 特性和接口保持兼容提升开发与适配效率。1. android sdk android-33为什么你的构建突然找不到平台了如果你最近在 CI 上看到Failed to find target with hash string android-33或者本地sdkmanager里明明装了 API 33 却仍然报platform not found那你不是一个人。android sdk android-33这个组合背后其实是一整套 Android 构建链的版本对齐问题编译 SDK 版本、构建工具版本、Gradle 插件版本、JDK 版本四者只要有一个错位构建就会以各种看似无关的报错翻车。它解决的核心诉求很具体——让项目在 API 33Android 13这个编译目标上稳定跑通而不是每次升级都靠玄学重装 SDK。适合谁适合正在维护多模块 Android 工程、需要把compileSdk从 31/32 抬到 33 的开发者也适合刚接手一个老项目、被环境问题卡住半天的新手。下面我按“先搞清目录和版本关系再动手装、配、排错”的顺序讲透。2. android-33 到底装了什么目录结构、组件与版本对齐很多人以为装了platforms;android-33就完事了其实 API 33 在 SDK 目录里对应的是好几个独立组件缺一个都可能让构建在某个阶段挂掉。先把“装了什么、放在哪、谁依赖谁”理清楚后面所有命令才有依据。2.1 SDK 根目录下与 android-33 相关的四个位置一个标准的 Android SDK 根目录ANDROID_HOME或ANDROID_SDK_ROOT指向它里和 API 33 直接相关的是这几块目录内容谁在用platforms/android-33/android.jar、framework.aidl、data/资源编译期提供 android.* 类build-tools/33.x.y/aapt2、d8、zipalign、apksigner打包、资源编译、签名platform-tools/adb、fastboot安装调试与 API 版本弱相关cmdline-tools/latest/bin/sdkmanager、avdmanager安装和管理上面这些关键点platforms/android-33只提供编译用的android.jar它不包含aapt2 和 d8。构建时 Gradle 会去build-tools里找这些工具所以只装 platform 不装 build-tools一样会失败。常见做法是让 build-tools 版本不低于 platform 版本对应的推荐值API 33 一般配 33.0.x 或 34.0.x 都能用。2.2 compileSdk、targetSdk、minSdk 三者的区别这是最容易混的一组参数配错了不会立刻报错但会在运行期或上架审核时出问题compileSdk编译时用哪个android.jar。设成 33 就意味着你能调用 API 33 的新类和方法。它只影响编译不影响运行。targetSdk告诉系统“我针对哪个版本做了适配”。系统会据此决定是否启用兼容行为比如通知权限、后台限制。它影响运行期行为。minSdk最低支持的设备版本。低于它的设备装不上。把compileSdk抬到 33 而targetSdk还停在 31是允许的但你就享受不到新版本的适配收益反过来targetSdk高于compileSdk则会直接编译报错。我一般建议三者一起评估别只改一个。2.3 Gradle 插件与 JDK 的版本门槛API 33 对应的 Android Gradle PluginAGP通常要求 7.x 起步而 AGP 7.x 又要求 JDK 11 及以上。如果你还在用 JDK 8 跑 AGP 7会看到类似Unsupported class file major version的报错这个报错和 SDK 一点关系都没有但很多人会误以为是 android-33 没装好。一个可用的组合参考不是唯一解但稳组件建议版本AGP7.4.xGradle7.5JDK11 或 17build-tools33.0.xcompileSdk33提示版本组合没有绝对标准以你项目里gradle-wrapper.properties和build.gradle实际声明为准先对齐再谈装 SDK。3. 用命令行把 android-33 装干净sdkmanager 实操图形化 SDK Manager 在 CI 上不可用而且它经常“显示已安装但实际文件不全”。命令行安装更可控也方便写进流水线脚本。下面这套流程我在多个环境里复现过。3.1 确认 sdkmanager 位置并列出可用包先确认你的cmdline-tools装好了并且sdkmanager能跑起来# 指向你的 SDK 根目录按实际路径改 export ANDROID_HOME$HOME/Android/Sdk export PATH$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$PATH # 确认 sdkmanager 可用 sdkmanager --version # 列出所有与 android-33 相关的可安装包 sdkmanager --list | grep android-33逻辑说明--list会输出已安装和可用的包grep过滤出 API 33 相关项。你会看到platforms;android-33、build-tools;33.0.x等条目。如果sdkmanager --version直接报错说明cmdline-tools没装或路径不对先解决这个再往下走。参数说明ANDROID_HOME是 SDK 根目录cmdline-tools/latest/bin是 sdkmanager 所在目录。有些旧环境用的是ANDROID_SDK_ROOT两者都设上更保险。3.2 安装 platform 与 build-tools确认包名后直接安装--sdk_root显式指定根目录避免装到默认位置# 安装 API 33 平台和对应构建工具 sdkmanager --sdk_root$ANDROID_HOME \ platforms;android-33 \ build-tools;33.0.2 \ platform-tools # 接受所有许可CI 上必须做否则会卡在 license 交互 yes | sdkmanager --sdk_root$ANDROID_HOME --licenses逻辑说明第一条命令把 platform、build-tools、platform-tools 一次装齐。第二条用yes自动接受许可协议这是 CI 环境里最常见的卡点——本地手动点过同意CI 上却是全新环境不自动接受就会一直等待输入直到超时。参数说明--sdk_root指定安装根目录包名必须和--list输出完全一致写错会报package not found。build-tools的具体小版本按--list里实际存在的填不要凭记忆写。3.3 验证安装结果装完别急着构建先验证文件真的到位# 检查 platform 是否完整 ls $ANDROID_HOME/platforms/android-33/android.jar # 检查 build-tools 里的关键工具 ls $ANDROID_HOME/build-tools/33.0.2/aapt2 ls $ANDROID_HOME/build-tools/33.0.2/d8 # 用 sdkmanager 再确认一次安装状态 sdkmanager --sdk_root$ANDROID_HOME --list_installed | grep android-33逻辑说明android.jar存在说明 platform 装好了aapt2和d8存在说明 build-tools 完整。最后一条从 sdkmanager 视角确认状态。三步都过SDK 层面基本没问题剩下的报错就该往 Gradle 和 JDK 方向查了。4. 在 Gradle 里正确声明 android-33配置与常见错配SDK 装好了不代表构建就能过Gradle 侧的声明才是决定“用哪个版本编译”的地方。这一章把配置写法和错配排查讲清楚。4.1 build.gradle 里的最小配置模块级build.gradle里和 API 33 相关的核心就几行android { namespace com.example.demo compileSdk 33 defaultConfig { applicationId com.example.demo minSdk 24 targetSdk 33 versionCode 1 versionName 1.0 } buildToolsVersion 33.0.2 // 可选不写则用 AGP 默认 }逻辑说明compileSdk 33告诉 AGP 用platforms/android-33/android.jar编译。targetSdk 33声明适配目标。buildToolsVersion不写时 AGP 会选一个它认为合适的版本但显式写死能避免不同机器上选到不同版本导致行为不一致。参数说明minSdk按你的用户覆盖情况定和 API 33 无强绑定。namespace是 AGP 7 之后替代package属性的写法老项目迁移时要注意。4.2 用 local.properties 或环境变量指定 SDK 路径Gradle 需要知道 SDK 在哪。两种常见方式# local.properties不要提交到版本库 sdk.dir/Users/yourname/Android/Sdk或者靠环境变量ANDROID_HOME。CI 上一般用环境变量本地用local.properties。两者同时存在时local.properties优先级更高。如果路径写错报错通常是SDK location not found和 android-33 本身无关但很容易被误判。4.3 多模块项目里的版本统一多模块工程最容易出现“主模块 compileSdk 33、子模块还是 31”的情况导致子模块编译时找不到新 API。常见做法是在根build.gradle里用ext或 version catalog 统一管理// 根 build.gradle ext { compileSdkVersion 33 buildToolsVersion 33.0.2 minSdkVersion 24 targetSdkVersion 33 }子模块引用rootProject.ext.compileSdkVersion。这样改一处全生效避免漏改。参数说明ext是 Groovy 的动态属性Kotlin DSL 项目里改用extra或 version catalog思路一致。5. 避坑与排查android-33 构建失败的 5 个高频现场这一章是我踩过的坑里出现频率最高的五类每条按“现象 → 原因 → 解决”写照着对号入座能省不少时间。5.1 现象Failed to find target with hash string android-33原因platforms/android-33没装或者装到了另一个 SDK 根目录而 Gradle 指向的是空的那个。多版本 SDK 共存时特别常见。解决先sdkmanager --list_installed | grep android-33确认装在哪再核对local.properties的sdk.dir和ANDROID_HOME是否指向同一个根目录。不一致就统一然后重新同步 Gradle。5.2 现象AAPT2 报错或资源编译失败原因build-tools版本和 AGP 不匹配或者aapt2文件缺失/损坏。有时是下载中断导致文件不完整。解决删掉build-tools/33.0.2整个目录重装命令是sdkmanager --uninstall build-tools;33.0.2再重新 install。同时确认 AGP 版本和 build-tools 大致对应别用太老的 AGP 配太新的 build-tools。5.3 现象Unsupported class file major version 61原因这是 JDK 版本问题不是 SDK 问题。major version 61 对应 JDK 17说明 Gradle 用的 JDK 和 AGP 期望的不一致。解决检查JAVA_HOME和 IDE 里 Gradle JDK 设置统一到 AGP 支持的版本AGP 7.x 用 JDK 11 或 17。改完清一次 Gradle 缓存再构建。5.4 现象本地能构建CI 上一直卡在 license原因CI 是全新环境SDK 许可未接受sdkmanager在等待交互输入。解决在 CI 脚本里加yes | sdkmanager --licenses并且确保这一步在安装组件之前或之后都执行一次。有些镜像预装了 SDK 但没接受许可同样会卡。5.5 现象targetSdk 33 后通知、权限行为变了原因targetSdk抬到 33 会启用 Android 13 的新行为最典型的是通知需要运行时权限POST_NOTIFICATIONS。解决在AndroidManifest.xml声明权限并在运行时请求。这不是构建错误而是行为变更容易被当成 bug。升级targetSdk前先过一遍官方行为变更清单逐条确认。注意排查顺序建议固定为“SDK 文件是否齐全 → 路径是否一致 → Gradle/JDK 版本 → 行为变更”从底层往上查比一上来就改代码高效得多。6. 让 android-33 构建可复现锁定版本与验证脚本前面讲的都是“怎么装、怎么配、怎么排错”但真正让团队少踩坑的是把这套东西固化成可复现的脚本和版本锁定。这一章落到具体技巧上。6.1 用版本目录锁定所有相关版本Gradle 的 version cataloglibs.versions.toml能把 SDK 相关版本集中管理[versions] agp 7.4.2 compileSdk 33 buildTools 33.0.2 minSdk 24 targetSdk 33模块里引用libs.versions.compileSdk.get().toInteger()。好处是版本只在一处定义升级时改一行所有模块同步。参数说明toInteger()是因为 TOML 里读出来是字符串而compileSdk需要整数。6.2 写一个环境自检脚本在 CI 的构建前加一段自检把问题挡在构建之前#!/usr/bin/env bash set -euo pipefail SDK_ROOT${ANDROID_HOME:?ANDROID_HOME not set} # 1. 检查 platform if [ ! -f $SDK_ROOT/platforms/android-33/android.jar ]; then echo 缺少 platforms;android-33开始安装 sdkmanager --sdk_root$SDK_ROOT platforms;android-33 fi # 2. 检查 build-tools if [ ! -f $SDK_ROOT/build-tools/33.0.2/aapt2 ]; then echo 缺少 build-tools;33.0.2开始安装 sdkmanager --sdk_root$SDK_ROOT build-tools;33.0.2 fi # 3. 接受许可 yes | sdkmanager --sdk_root$SDK_ROOT --licenses /dev/null echo android-33 环境自检通过逻辑说明脚本先检查关键文件是否存在缺了才装避免每次全量重装浪费时间。set -euo pipefail保证任何一步失败就退出不会带着半成品继续构建。参数说明${ANDROID_HOME:?...}在变量未设置时直接报错退出比默默用空路径安全。6.3 验证构建真的用了 android-33构建通过不代表用的是 33。想确认可以看构建输出里的compileSdkVersion或者用一条命令反查# 查看 APK 的 targetSdkVersion $ANDROID_HOME/build-tools/33.0.2/aapt2 dump badging app/build/outputs/apk/debug/app-debug.apk \ | grep -E sdkVersion|targetSdkVersion逻辑说明aapt2 dump badging会输出 APK 的清单信息sdkVersion是 minSdktargetSdkVersion是目标版本。确认这两个值符合预期才算真正验证了配置生效。参数说明APK 路径按实际产物改release 包同理。我自己的习惯是每次升级compileSdk或targetSdk先跑一遍自检脚本再构建最后用aapt2 dump badging确认产物三步都过才提交。这套流程帮我挡掉过好几次“本地能跑、CI 挂掉”的尴尬。希望帮到你。本文还有配套的精品资源点击获取