企业官网建设流程全解析

简介：面向 Android 应用开发者的 android-33 平台资源包，对应 Android 13（API 33）版本，适合需要在该系统版本下编译、调试与兼容性测试的初中级开发者。解压后可将平台目录放入 SDK 的 platforms 文件夹，供 Android Studio 等 IDE 直接选用，从而保证应用与 Android 33 的接口和特性保持一致。压缩包共约 2000 个文件，以 xml 配置与资源定义文件为主，辅以 html 文档页面和少量 txt 说明，整体约 60.84MB，体积轻量、便于归档与离线部署。资源涵盖平台系统库、API 文档等核心内容，可配合 Platform Tools、Build Tools 与模拟器使用，帮助读者快速补齐缺失的平台版本、减少在线下载等待，并为版本适配与接口查阅提供参考。已有 857 人学习下载，可作为 Android 多版本开发环境的常备组件。

1. 从一台新机器说起：android-33 到底该装哪一版

上周给一台刚重装系统的开发机配 Android 构建环境，Gradle 一跑就报Failed to find target with hash string 'android-33'。这台机器之前装过 Android Studio，SDK Manager 里看着平台目录也在，可sdkmanager --list里就是找不到platforms;android-33。折腾半小时才定位到：装的是个精简版命令行工具，platform-tools有了，但platforms和build-tools一个没落，ANDROID_HOME还指到了一个残留的旧目录。这类问题在换机、CI 容器、多人共用构建机上极其常见——Android SDK 不是装一个包就完事，它是一组按 API 级别拆开的组件，android-33只是其中一块拼图。

这篇记录的是我实际走通的一套 android-33 环境搭建流程：从命令行工具选版本、配环境变量、用sdkmanager精确拉取platforms;android-33和配套build-tools，到许可证接受、目录校验和构建验证。适合刚接手 Android 项目、需要在无 GUI 环境或新机器上把编译链跑起来的人；也适合已经装过 Studio 但被“平台找不到”“许可证未接受”卡住的熟手，对照着看版本和路径取舍。

2. 装前把版本和目录定死：android-33 的组件清单

2.1 先分清 SDK 里到底有哪几块

很多人把“装 Android SDK”理解成装一个整体，实际它由若干独立组件构成，各自有版本号，互不绑定。跟 android-33 直接相关的核心组件是这几块：

关键认知是：platforms;android-33只提供编译用的接口桩，不包含构建工具，也不包含 adb。只装它，Gradle 依然会在build-tools缺失时报错。我一般会把platforms、build-tools、platform-tools三件套一起装齐，再按需补模拟器。

2.2 版本怎么选：33 与 33.0.x 不是一回事

android-33是平台版本，对应 Android 13；build-tools是另一条版本线，常见的有 33.0.0、33.0.1、33.0.2 等。两者数字接近纯属命名习惯，不能互相替代。选 build-tools 的原则是：不低于项目build.gradle里声明的buildToolsVersion，没有显式声明时用 AGP 推荐的默认值。稳妥做法是装build-tools;33.0.2这类较新的补丁版，避免老版本 aapt2 在处理新资源格式时翻车。

cmdline-tools也有版本差异。老包叫tools，新版拆成cmdline-tools;latest、cmdline-tools;11.0等。新项目一律用cmdline-tools;latest，它的sdkmanager支持--sdk_root参数，能把 SDK 装到任意目录，这对多项目隔离很有用。老tools包已停止更新，不建议新装。

2.3 目录规划：装之前先想好放哪

SDK 目录一旦定下，后续所有环境变量、IDE 配置、CI 脚本都指向它，中途搬家成本很高。我一般遵循两条：路径不含空格和中文；单独一个盘或目录，不塞进项目仓库里。常见布局是~/Android/Sdk（Linux/macOS）或D:\Android\Sdk（Windows）。如果机器上已有旧 SDK，先确认它是不是完整目录，别直接复用——残留的半套 SDK 比全新目录更容易出玄学问题。

提示：ANDROID_HOME和ANDROID_SDK_ROOT两个变量历史上并存，新版本工具优先读ANDROID_HOME。两个都设成同一路径最省心，避免不同工具读到不同值。

3. 命令行工具落地：下载、解压与 sdkmanager 初始化

3.1 拿到 cmdline-tools 并摆对目录结构

命令行工具是一个 zip 包，解压后目录名带版本号，但sdkmanager要求它位于<SDK_ROOT>/cmdline-tools/latest/下，否则会报 “Could not determine SDK root”。这是新手最容易卡住的一步，解压完直接跑必然失败。正确做法是解压后重命名并移动：

# 假设 SDK 根目录定为 ~/Android/Sdk mkdir -p ~/Android/Sdk/cmdline-tools cd ~/Android/Sdk/cmdline-tools # 解压下载的 commandlinetools 包（文件名以实际为准） unzip ~/Downloads/commandlinetools-linux-*.zip # 解压出来通常是 cmdline-tools/ 目录，把它改名为 latest mv cmdline-tools latest # 确认结构：latest/bin/sdkmanager 应存在 ls latest/bin/sdkmanager

这段的关键在最后一步的目录层级。sdkmanager启动时会向上查找cmdline-tools的父目录作为 SDK 根，如果层级不对，它要么报找不到根目录，要么把 SDK 根误判成cmdline-tools本身，导致后续安装的组件散落在错误位置。移动完成后，latest/bin/下应该有sdkmanager、avdmanager、sdkmanager.bat（Windows）等文件。

3.2 配环境变量：三个路径一次写对

环境变量要覆盖三件事：SDK 根目录、命令行工具的可执行路径、platform-tools 的可执行路径。以 bash 为例写进~/.bashrc或~/.zshrc：

# SDK 根目录，两个变量都设，兼容不同工具 export ANDROID_HOME="$HOME/Android/Sdk" export ANDROID_SDK_ROOT="$ANDROID_HOME" # sdkmanager / avdmanager 入口 export PATH="$ANDROID_HOME/cmdline-tools/latest/bin:$PATH" # adb / fastboot 入口 export PATH="$ANDROID_HOME/platform-tools:$PATH"

ANDROID_HOME是主变量，ANDROID_SDK_ROOT作为兼容别名指向同一路径，避免某些老脚本只认后者。PATH 里把cmdline-tools/latest/bin放在前面，是为了让系统优先命中新版sdkmanager，而不是某个残留的旧入口。改完执行source ~/.bashrc，再用which sdkmanager确认解析到的路径在latest/bin下。

Windows 下对应在“系统属性 → 环境变量”里新建ANDROID_HOME，并在Path中追加%ANDROID_HOME%\cmdline-tools\latest\bin和%ANDROID_HOME%\platform-tools。改完要重开终端，旧终端不会自动刷新。

3.3 用 sdkmanager 精确安装 android-33 组件

环境变量生效后，先看当前已装和可装列表，确认platforms;android-33在候选里：

# 列出已安装组件 sdkmanager --list_installed # 搜索 android-33 相关条目 sdkmanager --list | grep "android-33"

确认存在后，一条命令装齐三件套。--sdk_root显式指定根目录，避免工具自行推断出错：

sdkmanager --sdk_root="$ANDROID_HOME" \ "platforms;android-33" \ "build-tools;33.0.2" \ "platform-tools"

参数说明：--sdk_root指定安装目标，多 SDK 共存时必带；三个包名用分号分隔平台与版本，引号防止 shell 把分号当命令分隔符。build-tools;33.0.2可按项目实际需要换成 33.0.0 或 33.0.1，但建议不低于 AGP 默认值。安装过程会下载数百 MB，网络不稳时容易中断，中断后重跑同一条命令即可续装，已完成的组件会跳过。

3.4 接受许可证：不然后续构建直接失败

组件装完不等于能用，sdkmanager安装的部分组件附带许可证，未接受时 Gradle 构建会报 “license not accepted”。批量接受：

# 自动接受所有许可证 yes | sdkmanager --sdk_root="$ANDROID_HOME" --licenses

yes持续输出y喂给交互提示，--licenses进入许可证审阅模式。执行完会列出已接受的许可证清单。这一步在 CI 容器里尤其重要，很多构建镜像就是漏了它，导致本地能编、流水线报错。接受记录写在<SDK_ROOT>/licenses/下，迁移 SDK 目录时把这个目录一起带走，能省一次重复接受。

4. 避坑与排查：android-33 装不上、找不到的典型现场

4.1 报 “Failed to find target with hash string 'android-33'”

现象：Gradle 同步或构建时报找不到 android-33 目标，但sdkmanager --list_installed里明明有platforms;android-33。

原因：多数是ANDROID_HOME指向了另一个 SDK 目录，或者项目local.properties里的sdk.dir写死了一个旧路径，覆盖了环境变量。Gradle 读sdk.dir的优先级高于环境变量。

解决：检查项目根目录local.properties的sdk.dir，确认它和ANDROID_HOME一致；不一致就改掉或删掉该行让它回退到环境变量。再执行./gradlew --stop清掉守护进程后重试，守护进程会缓存旧路径。

4.2 sdkmanager 报 “Could not determine SDK root”

现象：直接运行sdkmanager提示无法确定 SDK 根目录。

原因：cmdline-tools的目录层级不对，常见是解压后没重命名为latest，或者被放到了<SDK_ROOT>/cmdline-tools/cmdline-tools/这种多套一层的位置。

解决：按 3.1 的结构整理成<SDK_ROOT>/cmdline-tools/latest/bin/sdkmanager。整理后如果还报错，用--sdk_root显式传根目录再试，能快速判断是层级问题还是变量问题。

4.3 构建时报 build-tools 版本不匹配

现象：platforms;android-33装好了，构建仍报 aapt2 或 d8 相关错误，提示 build-tools 版本缺失。

原因：只装了平台没装构建工具，或项目声明的buildToolsVersion与已装版本不一致。

解决：sdkmanager --list_installed | grep build-tools看实际装了哪些，缺哪个补哪个。项目里显式写了buildToolsVersion的，要么装对应版本，要么删掉该声明让 AGP 用默认值。我一般倾向后者，减少版本钉死带来的维护负担。

4.4 许可证未接受导致 CI 失败

现象：本地构建正常，流水线报 “You have not accepted the license agreements”。

原因：CI 镜像里的 SDK 是预置的，许可证目录缺失或未接受。

解决：在流水线里加一步yes | sdkmanager --licenses，或把本地<SDK_ROOT>/licenses/目录随镜像一起打包。后者更快，但要注意许可证内容随组件更新可能变化，定期重建镜像更稳。

4.5 多版本 SDK 共存时工具读错目录

现象：机器上装了多个 SDK（比如 Studio 自带一个、手动装一个），命令行工具和 IDE 行为不一致。

原因：ANDROID_HOME、local.properties、IDE 内部配置三处各指一个目录。

解决：统一到一处。IDE 里在 SDK 设置中指向同一个根目录，项目local.properties与环境变量保持一致。排查时用sdkmanager --list_installed和 IDE 的 SDK 面板对照，哪边组件少就是哪边指错了。

5. 装完怎么验证：从 sdkmanager 到一次真实构建

5.1 三层验证，逐层确认

装完不要直接开 IDE，按三层顺序验证，出问题能立刻定位到哪一层。

第一层，组件层。确认 android-33 和 build-tools 真实落盘：

# 已安装列表里应出现这三项 sdkmanager --list_installed | grep -E "platforms;android-33|build-tools;33|platform-tools" # 直接看目录，android.jar 存在才算装好 ls "$ANDROID_HOME/platforms/android-33/android.jar" ls "$ANDROID_HOME/build-tools/33.0.2/aapt2"

android.jar是平台的核心产物，它存在基本说明平台装完整了；aapt2存在说明构建工具到位。两个文件都缺，说明安装命令没真正执行成功，回看 3.3 的输出。

第二层，工具层。确认 adb 和 sdkmanager 都能正常响应：

adb version sdkmanager --version

adb version能打印版本号，说明 platform-tools 的 PATH 配对了；sdkmanager --version正常输出，说明命令行工具层级和变量都没问题。这两个命令任一报“command not found”，回 3.2 检查 PATH。

第三层，构建层。拿一个最小项目跑一次真实编译，这是最终判据：

# 在项目根目录执行，只编译不安装 ./gradlew :app:assembleDebug --stacktrace

assembleDebug会完整走一遍资源处理、编译、打包，任何组件缺失都会在这一步暴露。加--stacktrace是为了出错时能看到完整调用链，定位是哪个任务、哪个工具报的错。构建成功后在app/build/outputs/apk/debug/下能看到 apk 文件，说明 android-33 这条链彻底通了。

5.2 一个容易忽略的收尾检查

构建通过后，我还会做一件事：把sdkmanager --list_installed的完整输出存一份到项目文档或机器备注里。原因是 SDK 组件会随 AGP 升级悄悄变化，半年后回来排查“当时到底装了什么”，这份快照就是黑匣子。尤其是多人共用构建机，谁装了什么、装在哪，靠记忆迟早翻车。

另外，如果项目后续要升到更高 API 级别，platforms和build-tools是增量安装，不需要卸载 android-33，多版本可以共存。真正需要清理的是那些长期不用、体积又大的 system-image，用sdkmanager --uninstall "system-images;..."单独移除即可，别整个目录删，容易误伤。

从那以后我每次配新机器，都强制按“组件清单 → 目录结构 → 环境变量 → 许可证 → 三层验证”走一遍，不再凭记忆跳步。这套流程看着啰嗦，但比事后对着Failed to find target猜半天要省时间得多。希望帮到你。

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