简介：这份资源是面向 Linux 平台的 Android 命令行工具包，适合不想安装完整 Android Studio、又需要构建与调试 Android 应用的开发者，尤其适合在服务器、CI 环境或轻量开发机上使用。压缩包共 101 个文件，以 91 个 jar 库为核心，辅以 sdkmanager、avdmanager、apkanalyzer、lint、retrace、profgen、screenshot2 等可执行工具及说明文档，整体约 127.32MB，结构紧凑、开箱即用。借助其中的 sdkmanager，可按需下载其他 SDK 组件，完成环境搭建、应用分析、性能追踪与代码检查等任务。目前已有 225 人学习下载，内容覆盖命令行构建、模拟器管理、APK 分析与性能剖析等常见场景，能帮助读者在无图形界面的环境中高效完成 Android 开发与调试工作。
1. 命令行工具包：从commandlinetools-linux-9477386-latest.zip说起
如果你在 Linux 上做 Android 相关的构建、自动化打包或者 CI 流水线，大概率绕不开一个名字很长的压缩包：commandlinetools-linux-9477386-latest.zip。它不是一个普通工具，而是 Android 官方命令行工具集的 Linux 发行版，里面装着sdkmanager、avdmanager、adb、fastboot等核心可执行文件。很多团队在容器里跑构建时，图形化 IDE 根本装不上，这时候这个包就是唯一的入口。它解决的核心问题是：在没有 Android Studio 的环境里，依然能完整地安装 SDK、管理平台版本、接受许可协议、创建模拟器。适合谁？适合做后端构建服务、嵌入式 Linux 开发板调试、以及需要把 Android 构建塞进 Docker 镜像的工程师。标题里那串数字9477386是构建编号，latest表示这是该渠道的最新稳定版，但注意——它并不等于永远最新，后面我会讲怎么验证和替换。
2. 拆开压缩包：目录结构、核心命令与选型理由
2.1 解压后到底有什么：cmdline-tools的目录布局
拿到 zip 之后，第一件事不是急着配环境变量，而是先看清楚它的内部结构。用unzip -l列出内容，你会发现顶层只有一个cmdline-tools目录，里面又分bin、lib、source.properties等。bin下就是所有可执行脚本，lib下是它们依赖的 jar 包。source.properties记录了版本号，这个文件后面校验时会用到。
# 先看压缩包内容，不要直接解压到当前目录 unzip -l commandlinetools-linux-9477386-latest.zip | head -30 # 解压到一个临时目录，避免污染工作区 mkdir -p /opt/android-sdk/cmdline-tools unzip -q commandlinetools-linux-9477386-latest.zip -d /tmp/cmdline-tools-extract # 官方推荐把解压后的 cmdline-tools 再套一层 latest 目录 mv /tmp/cmdline-tools-extract/cmdline-tools /opt/android-sdk/cmdline-tools/latest逻辑说明：官方文档明确要求cmdline-tools下的目录名必须是latest，否则sdkmanager在计算 SDK 根路径时会出错。参数上，-d指定解压目标，-q静默模式适合脚本。如果你直接解压到/opt/android-sdk/cmdline-tools，会得到/opt/android-sdk/cmdline-tools/cmdline-tools/bin，多了一层，导致后续命令找不到路径。这个坑我见过至少三次，每次都是因为图省事。
2.2 三个必调参数：sdkmanager的安装与许可
解压完只是第一步，真正让工具链可用的是sdkmanager。它负责下载 platform、build-tools、platform-tools 等组件。但第一次运行前必须设置ANDROID_HOME或ANDROID_SDK_ROOT，并且要接受许可协议。很多人卡在Warning: Could not create settings或者Accept? (y/N)无法自动输入。
# 设置环境变量，建议写进 ~/.bashrc 或 Dockerfile export ANDROID_SDK_ROOT=/opt/android-sdk export PATH=$PATH:$ANDROID_SDK_ROOT/cmdline-tools/latest/bin # 查看当前已安装和可安装的包 sdkmanager --list # 非交互式接受所有许可，这是 CI 里最常用的写法 yes | sdkmanager --licenses # 安装指定版本的 platform 和 build-tools sdkmanager "platforms;android-34" "build-tools;34.0.0" "platform-tools"逻辑说明：yes |把无限个y管道给sdkmanager --licenses，避免交互阻塞。参数platforms;android-34里的分号是包名分隔符，不能写成斜杠。build-tools;34.0.0的版本号必须和你的 Gradle 插件匹配，否则会出现Installed Build Tools revision 34.0.0 is corrupted这种玄学报错。我一般会先跑sdkmanager --list | grep build-tools确认可用版本，再决定装哪个。
2.3 为什么不用系统包管理器：选型对比
有人会问：Ubuntu 的apt install android-sdk不行吗？行，但版本通常滞后两三年，而且缺少sdkmanager的完整功能。另一个选择是直接下载 Android Studio，但它的体积是几百 MB 起步，在 CI 容器里纯属浪费。commandlinetools-linux-9477386-latest.zip只有一百多 MB，解压后核心工具齐全，适合做最小化镜像。
| 方案 | 体积 | 版本可控性 | CI 友好度 | 典型场景 |
|---|---|---|---|---|
| 系统包管理器 | 小 | 差，滞后 | 一般 | 本地临时调试 |
| Android Studio | 大 | 好 | 差 | 图形化开发 |
| commandlinetools zip | 中 | 好，可指定构建号 | 好 | 容器构建、自动化 |
选型理由：如果你需要精确控制 SDK 版本，并且要在 Docker 里复现构建，这个 zip 是唯一靠谱的起点。注意9477386这个构建号对应的工具版本，在source.properties里能看到Pkg.Revision=11.0，不同构建号可能对应不同的小版本，升级时不要只看latest字样。
3. 在 Docker 与 CI 里跑通：从零到可复现构建
3.1 写一个最小 Dockerfile：把工具链固化进镜像
在本地手动解压只能算验证，真正落地要写进 Dockerfile。下面这个例子基于一个精简的 Linux 基础镜像，把commandlinetools-linux-9477386-latest.zip下载、解压、接受许可、安装指定组件，最后清理缓存。
FROM ubuntu:22.04 # 安装基础依赖，unzip 和 openjdk 是必须的 RUN apt-get update && apt-get install -y \ wget unzip openjdk-17-jdk-headless \ && rm -rf /var/lib/apt/lists/* # 下载并解压命令行工具，注意目录层级 ENV ANDROID_SDK_ROOT=/opt/android-sdk RUN mkdir -p $ANDROID_SDK_ROOT/cmdline-tools \ && wget -q https://example.invalid/commandlinetools-linux-9477386-latest.zip -O /tmp/tools.zip \ && unzip -q /tmp/tools.zip -d /tmp/tools \ && mv /tmp/tools/cmdline-tools $ANDROID_SDK_ROOT/cmdline-tools/latest \ && rm /tmp/tools.zip ENV PATH=$PATH:$ANDROID_SDK_ROOT/cmdline-tools/latest/bin # 接受许可并安装组件，这一步会下载几百 MB 数据 RUN yes | sdkmanager --licenses \ && sdkmanager "platform-tools" "platforms;android-34" "build-tools;34.0.0"逻辑说明：wget的 URL 我用了占位符，实际替换成你内网镜像或官方地址即可。openjdk-17-jdk-headless是sdkmanager运行所需，缺了会报No Java runtime present。yes | sdkmanager --licenses在 Docker 构建层里执行一次即可，后续层会复用。注意sdkmanager下载的组件默认放在$ANDROID_SDK_ROOT下，不要手动改路径。
3.2 在 CI 流水线里缓存 SDK：避免每次重下
CI 环境每次构建都重新下载 SDK 是灾难。以常见的流水线配置为例，可以把$ANDROID_SDK_ROOT下的platforms、build-tools、platform-tools目录做缓存。但cmdline-tools本身不建议缓存，因为它体积小且解压快，缓存反而容易因为构建号变化导致不一致。
# 伪代码示例，展示缓存键的设计思路 cache: key: android-sdk-${{ checksum "commandlinetools-linux-9477386-latest.zip" }} paths: - /opt/android-sdk/platforms - /opt/android-sdk/build-tools - /opt/android-sdk/platform-tools逻辑说明：缓存键用 zip 文件的校验和，这样当你升级构建号时，缓存自动失效。只缓存组件目录，不缓存cmdline-tools，避免latest目录被旧版本覆盖。参数上，checksum是流水线内置函数，不同平台写法不同，核心思想是让缓存和输入绑定。
3.3 验证安装结果：三条命令确认环境可用
装完之后不能假设一切正常，要跑三条命令验证。第一条sdkmanager --version看工具本身是否可执行；第二条sdkmanager --list_installed看组件是否真的装上了；第三条adb version看 platform-tools 是否在 PATH 里。
# 验证工具版本 sdkmanager --version # 列出已安装组件，确认没有 missing 标记 sdkmanager --list_installed # 验证 adb 可用 adb version逻辑说明：--list_installed的输出里，如果某个包后面跟着[missing]，说明目录存在但文件不完整，通常是下载中断导致。解决办法是删掉对应目录重新sdkmanager安装。adb version如果报command not found，检查platform-tools是否装到了$ANDROID_SDK_ROOT/platform-tools，以及 PATH 是否包含它。
4. 避坑与排查：五个血泪教训
4.1 现象：sdkmanager报Could not determine SDK root
原因：cmdline-tools的目录层级不对，或者ANDROID_SDK_ROOT指向了cmdline-tools内部而不是 SDK 根目录。解决：确保路径是$ANDROID_SDK_ROOT/cmdline-tools/latest/bin/sdkmanager，并且ANDROID_SDK_ROOT指向/opt/android-sdk这种根，而不是/opt/android-sdk/cmdline-tools。
4.2 现象：接受许可后仍然提示License not accepted
原因：yes | sdkmanager --licenses在某些 shell 里因为管道提前关闭而没写完所有许可文件。解决：改用sdkmanager --licenses < /dev/null或者循环写入y，也可以手动检查$ANDROID_SDK_ROOT/licenses目录下是否有android-sdk-license文件。
4.3 现象：build-tools安装成功但 Gradle 报corrupted
原因：下载的 build-tools 压缩包不完整，或者文件权限不对。解决：删除$ANDROID_SDK_ROOT/build-tools/34.0.0整个目录，重新执行sdkmanager "build-tools;34.0.0"。如果反复出现，检查磁盘空间和网络稳定性。
4.4 现象：adb能运行但找不到设备
原因：platform-tools装好了，但 udev 规则没配，或者当前用户不在plugdev组。解决：在 Linux 上添加 udev 规则文件，或者用sudo运行adb devices确认是权限问题。容器里跑adb需要把 USB 设备映射进去，这个属于容器配置范畴。
4.5 现象：升级构建号后旧脚本全部失败
原因：新构建号的cmdline-tools可能改变了内部 jar 包路径或命令参数。解决：不要直接覆盖latest目录，而是先备份旧目录，解压新版本到临时位置，对比source.properties和sdkmanager --help的输出，确认无破坏性变更后再替换。
5. 进阶技巧：用source.properties做版本锁与自动化校验
最后一章讲一个我常用的技巧：把commandlinetools-linux-9477386-latest.zip的版本号锁死，并在流水线里做校验。很多人直接依赖latest字样，但latest会变，今天下载的和下个月下载的可能不是同一个构建号。正确做法是记录source.properties里的Pkg.Revision和Pkg.Revision对应的构建号，在下载后立即校验。
# 解压后读取 source.properties 并校验 REVISION=$(grep 'Pkg.Revision' /opt/android-sdk/cmdline-tools/latest/source.properties | cut -d'=' -f2 | tr -d ' ') echo "Installed cmdline-tools revision: $REVISION" # 如果期望值是 11.0，不匹配就退出 if [ "$REVISION" != "11.0" ]; then echo "Revision mismatch, expected 11.0 but got $REVISION" exit 1 fi逻辑说明：grep提取Pkg.Revision行，cut按等号分割取第二段，tr -d ' '去掉空格。这个校验放在 Dockerfile 的RUN里，可以在构建阶段就发现版本漂移。参数上，11.0是9477386构建号对应的修订版本，你可以在解压后的source.properties里确认。如果官方发布了新构建号，这个值会变，你需要同步更新校验脚本。
另一个技巧是结合sdkmanager --list的输出做组件版本矩阵。比如你的项目需要platforms;android-34和build-tools;34.0.0，可以在脚本里先检查是否已安装，避免重复下载。
# 检查组件是否已安装，未安装则安装 if ! sdkmanager --list_installed | grep -q "platforms;android-34"; then sdkmanager "platforms;android-34" fi逻辑说明：--list_installed只列出已安装项，grep -q静默匹配，匹配不到就执行安装。这个模式适合在 CI 的缓存恢复步骤之后运行，能显著减少构建时间。注意grep的字符串要和sdkmanager输出的包名完全一致，包括分号。
我自己的习惯是：每次升级commandlinetools构建号时，先在一个临时容器里跑一遍完整的sdkmanager --licenses和组件安装，确认没有新的交互提示或路径变化，再更新到主流水线。这个习惯帮我省掉了至少两次因为构建号升级导致的流水线中断。希望帮到你。
本文还有配套的精品资源，点击获取
