简介：这份资源是面向 Linux 平台的 Android 命令行工具包，适合不想安装完整 Android Studio、又需要构建与调试 Android 应用的开发者，尤其是习惯命令行工作流的中高级用户。压缩包共 101 个文件，以 91 个 jar 库为核心，辅以 sdkmanager、avdmanager、apkanalyzer、lint、retrace、profgen、screenshot2 等可执行脚本及说明文档，整体约 127.32MB。借助其中的 sdkmanager，可按需下载其他 SDK 包，完成环境搭建、应用分析、性能追踪与代码检查等任务。内容预览显示包内还包含 kotlin 编译器、r8、proto、bcprov、guava 等依赖库，覆盖编译、混淆、加密与工具链支撑。目前已有 225 人学习下载，适合希望精简开发环境、以脚本方式管理 Android SDK 的读者参考使用。
1. 为什么我劝你先别装 Android Studio：一份 9477386 版命令行工具的拆包实录
如果你只是想在 Linux 服务器上编译一个 APK、跑一遍 lint、或者给 CI 流水线补上sdkmanager，那装一整套 Android Studio 纯属给自己找麻烦——它拖着 IDE、模拟器、Gradle 插件和一堆图形依赖，在无桌面环境的机器上光装依赖就能耗掉半小时。我这次拆的是commandlinetools-linux-9477386-latest.zip，这是 Android 官方命令行工具的一个发行包，解压后核心就是cmdline-tools目录，里面躺着sdkmanager、avdmanager、apkanalyzer这些命令行入口。它解决的就是「不装 IDE 也能管理 SDK、分析 APK、创建 AVD」这件事，适合在 Linux 上做自动化构建、容器镜像、以及资源受限环境里干活的从业者。包里还带了一批 jar：r8.jar负责代码压缩混淆，kotlin-compiler-mvn.jar和kotlin-reflect-1.7.10.jar撑起 Kotlin 编译，intellij-core-mvn.jar、guava-30.1-jre.jar、bcprov-jdk15on-1.67.jar是底层依赖，tools.lint-checks.jar管静态检查，proto.jar处理协议数据。下面我按「拿到包怎么落地 → 参数怎么配 → 哪里会翻车」的顺序，把这份工具拆开讲透。
2. 解包与目录布局：9477386 里到底装了什么
2.1 先看清压缩包的结构再动手
拿到commandlinetools-linux-9477386-latest.zip之后，别急着unzip到当前目录就完事。这个包解压出来是一个顶层目录cmdline-tools，如果你直接解压到$HOME，会得到一个$HOME/cmdline-tools，而sdkmanager对目录层级是有要求的——它期望自己位于<sdk-root>/cmdline-tools/<version>/bin/下面。常见做法是先建一个 SDK 根目录，再把解压结果放进去并重命名版本目录。
# 建一个统一的 SDK 根目录，后续所有 SDK 包都装在这里 mkdir -p "$HOME/android-sdk/cmdline-tools" # 解压到临时目录，避免污染当前工作目录 unzip commandlinetools-linux-9477386-latest.zip -d /tmp/cmdline-tools-extract # 把解压出来的 cmdline-tools 移动到 SDK 根目录下，并命名为 latest mv /tmp/cmdline-tools-extract/cmdline-tools "$HOME/android-sdk/cmdline-tools/latest" # 确认关键可执行文件在位 ls "$HOME/android-sdk/cmdline-tools/latest/bin"这段操作的核心逻辑是：sdkmanager通过相对路径向上寻找 SDK 根目录，如果目录层级不对，它会报Could not determine SDK root或者把包装到意想不到的位置。参数上，latest这个目录名不是强制的，但用latest可以让你后续升级命令行工具时直接替换整个目录，而不用改环境变量。ls那一步是验证sdkmanager、avdmanager、apkanalyzer三个脚本是否都在。
2.2 环境变量怎么设才不打架
目录放好之后，需要把bin加进PATH，同时设ANDROID_HOME或ANDROID_SDK_ROOT。这两个变量历史上并存过，新版本工具更认ANDROID_HOME，但ANDROID_SDK_ROOT在部分老脚本里还在用。稳妥做法是两个都设，指向同一个 SDK 根目录。
# 写入当前用户的 shell 配置，按你实际用的 shell 选一个 cat >> "$HOME/.bashrc" <<'EOF' export ANDROID_HOME="$HOME/android-sdk" export ANDROID_SDK_ROOT="$HOME/android-sdk" export PATH="$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$PATH" EOF # 让配置立即生效 source "$HOME/.bashrc" # 验证 sdkmanager 能否正常启动并打印版本 sdkmanager --version这里PATH的顺序有讲究：cmdline-tools/latest/bin放在前面，保证你调用的是这份 9477386 里的sdkmanager，而不是系统里可能残留的旧版本。platform-tools是后面装adb时才会出现的目录，提前加进去不影响，等 SDK 包装好后就能直接用。sdkmanager --version如果输出了版本号，说明 Java 运行时也没问题——这个工具依赖 JRE，通常要求 Java 8 或 11 以上，具体看发行说明。
2.3 包里那些 jar 各自管什么
解压后lib目录下有一堆 jar，很多人直接忽略，但出问题时它们就是线索。下面这张表是我对照实际报错整理出来的对应关系。
| jar 文件 | 作用 | 出问题时的典型现象 |
|---|---|---|
r8.jar | 代码压缩、混淆、脱糖 | 构建 release 包时报R8相关缺失 |
kotlin-compiler-mvn.jar | Kotlin 编译入口 | Kotlin 源码编译失败，提示找不到编译器 |
kotlin-reflect-1.7.10.jar | Kotlin 反射支持 | 运行期反射调用抛NoClassDefFoundError |
intellij-core-mvn.jar | lint 与 IDE 共用核心 | lint 任务启动即崩 |
tools.lint-checks.jar | 静态检查规则集 | lint 不报任何问题或规则加载失败 |
guava-30.1-jre.jar | 基础工具库 | 各类NoSuchMethodError |
bcprov-jdk15on-1.67.jar | 加密算法提供者 | 签名校验相关异常 |
proto.jar | 协议缓冲区支持 | 解析 AVD 或设备配置时出错 |
这张表的价值在于：当你在 CI 里看到某个ClassNotFoundException，先别怀疑自己的代码，对照一下是不是lib目录被裁剪过。有些精简镜像会删掉「看起来没用」的 jar，结果apkanalyzer一跑就挂。
3. 用 sdkmanager 把 SDK 包拉齐：参数与镜像配置
3.1 先接受许可，再谈安装
sdkmanager第一次用的时候，如果不接受许可，装任何包都会卡在交互式确认上。在 CI 环境里没有标准输入，这一步会直接失败。标准做法是先把许可批量接受掉。
# 批量接受所有许可，--sdk_root 显式指定根目录避免歧义 yes | sdkmanager --sdk_root="$ANDROID_HOME" --licenses # 查看当前已安装和可安装的包列表 sdkmanager --sdk_root="$ANDROID_HOME" --listyes |是把y不断喂给交互提示，--licenses触发许可流程。--sdk_root这个参数我建议每次都显式带上，因为当你的cmdline-tools目录层级有偏差时，工具可能推断出错误的根目录，导致包装到了别处。--list会输出已安装和可用包，输出很长，可以配合grep过滤，比如sdkmanager --list | grep platforms。
3.2 装哪些包取决于你要干什么
不是所有人都需要全套 SDK。下面按场景列一下最小集合。
# 场景一：只想用 apkanalyzer 分析已有 APK sdkmanager --sdk_root="$ANDROID_HOME" "platform-tools" # 场景二：要编译一个指定 API 级别的项目 sdkmanager --sdk_root="$ANDROID_HOME" \ "platform-tools" \ "platforms;android-34" \ "build-tools;34.0.0" # 场景三：还要跑模拟器做自动化测试 sdkmanager --sdk_root="$ANDROID_HOME" \ "platform-tools" \ "platforms;android-34" \ "build-tools;34.0.0" \ "emulator" \ "system-images;android-34;google_apis;x86_64"参数里的分号是包路径分隔符，不能写成点或斜杠。platforms;android-34对应 API 34 的平台 jar，build-tools;34.0.0提供aapt2、d8等构建工具。如果你不确定某个包的确切名称，用sdkmanager --list | grep 关键词去查，别凭记忆拼，拼错了会报Warning: Failed to find package。
3.3 镜像源配置：下载慢和超时的解法
默认情况下sdkmanager会去官方地址拉包，网络不稳的时候经常超时。可以在$ANDROID_HOME下建一个配置文件，把下载源指向可用的镜像。
# 在 SDK 根目录创建镜像配置，注意文件名和字段名 cat > "$ANDROID_HOME/.knownPackages" <<'EOF' EOF # 更常用的是通过环境变量或代理配置，这里演示在 sdkmanager 启动脚本里追加 JVM 参数 # 编辑 cmdline-tools/latest/bin/sdkmanager，找到 DEFAULT_JVM_OPTS 行 # 追加 -Dhttp.proxyHost 等参数（按你所在网络环境填写）需要说明的是，镜像配置这块各家环境差异很大，我不建议照抄某个固定地址。更稳的思路是：先确认你的网络能访问官方源，如果只是慢，用--verbose看卡在哪个包；如果是特定域名不通，再考虑在启动脚本的DEFAULT_JVM_OPTS里加 JVM 级别的网络参数。改完脚本记得备份原文件，升级命令行工具时会被覆盖。
提示：
sdkmanager的下载缓存默认在$HOME/.android/cache，如果反复失败，可以先清掉这个目录再重试，避免半截文件干扰。
4. apkanalyzer 与 avdmanager：不装 IDE 也能干的活
4.1 apkanalyzer 的常用子命令
apkanalyzer是这份工具里被低估的一个，它能直接对一个 APK 做体积分析、权限清单、dex 方法数统计，不用打开 IDE。
# 查看 APK 的总体积构成，按文件类型分组 apkanalyzer apk file-size app-release.apk # 查看下载大小估算（考虑压缩后） apkanalyzer apk download-size app-release.apk # 列出 APK 里声明的权限 apkanalyzer manifest permissions app-release.apk # 统计 dex 方法数，排查 64K 限制 apkanalyzer dex references app-release.apk # 查看 manifest 里的版本信息 apkanalyzer manifest version-name app-release.apk这些子命令的输出都是纯文本，非常适合塞进 CI 脚本做阈值判断。比如你可以用apkanalyzer apk file-size的输出和上一次构建对比，超过阈值就让流水线告警。参数上，APK 路径支持相对和绝对路径，但如果你在脚本里用，建议统一用绝对路径，避免工作目录变化导致找不到文件。
4.2 avdmanager 创建与管理 AVD
avdmanager用来在命令行创建 Android 虚拟设备，配合emulator就能在无头环境跑起来。
# 先确认可用的系统镜像已经装好 sdkmanager --list | grep "system-images" # 创建一个 AVD，指定名称、镜像和设备类型 avdmanager create avd \ --name test-avd \ --package "system-images;android-34;google_apis;x86_64" \ --device "pixel_6" \ --force # 列出已有 AVD avdmanager list avd # 删除不再需要的 AVD avdmanager delete avd --name test-avd--package必须和sdkmanager里装的镜像路径完全一致，否则会报找不到包。--device可以省略，省略时用默认设备配置。--force在覆盖同名 AVD 时有用，但生产脚本里慎用，容易误删。创建好的 AVD 配置在$HOME/.android/avd/下，如果这个目录权限不对，avdmanager会静默失败或者报权限错误。
4.3 无头启动模拟器做冒烟测试
创建完 AVD 后，可以用emulator以无头模式启动，跑一轮安装和启动测试。
# 无头启动，-no-window 不显示界面，-no-audio 省资源 emulator -avd test-avd -no-window -no-audio -no-boot-anim & # 等待设备上线，adb 在 platform-tools 里 adb wait-for-device # 确认启动完成 adb shell getprop sys.boot_completed # 安装并启动被测应用 adb install -r app-debug.apk adb shell am start -n com.example.app/.MainActivity-no-window是无头环境的关键，-no-audio避免音频设备缺失导致的报错，-no-boot-anim加快启动。adb wait-for-device只是等设备连接，不代表系统启动完成，所以还要查sys.boot_completed是否为1。这套流程在 CI 里很常见，但要注意模拟器对内存和 CPU 有要求，资源不够时会卡在启动阶段。
5. 避坑排查：那些让我重装过三次的坑
5.1 坑一：sdkmanager 报 Could not determine SDK root
现象是执行sdkmanager --list直接抛Could not determine SDK root，或者提示找不到cmdline-tools。原因几乎都是目录层级不对——sdkmanager期望自己在<sdk-root>/cmdline-tools/<version>/bin/下，如果你解压后直接是<sdk-root>/cmdline-tools/bin/，它就推断不出根目录。解决办法是按 2.1 里的步骤，把解压结果放进cmdline-tools/latest/这样的版本目录里，或者每次调用都显式加--sdk_root。
5.2 坑二：许可没接受导致 CI 静默失败
现象是本地手动跑没问题，一上 CI 就卡住或者报Failed to install。原因是 CI 环境没有交互式终端，sdkmanager遇到未接受的许可时无法弹出确认。解决办法是在流水线里先跑yes | sdkmanager --licenses，并且把这一步放在安装任何包之前。注意yes |在某些 shell 里会提前退出，可以用yes | sdkmanager --licenses || true兜底。
5.3 坑三：Java 版本不匹配导致工具启动即崩
现象是sdkmanager一执行就报UnsupportedClassVersionError或者直接无输出退出。原因是这份 9477386 里的 class 文件是用特定 Java 版本编译的，JRE 太老或太新都可能出问题。解决办法是先java -version确认版本，常见做法是用 Java 11 或 17。如果系统里有多个 Java，用JAVA_HOME显式指定，别依赖PATH里的默认值。
5.4 坑四：apkanalyzer 报缺少 lint-checks 或 guava
现象是apkanalyzer执行到某个子命令时报NoClassDefFoundError，指向tools.lint-checks.jar或guava-30.1-jre.jar。原因是有人为了减小镜像体积，把lib目录下的 jar 删了一部分。解决办法是恢复完整的lib目录，或者至少保留第 2.3 节表格里列出的那些 jar。如果你确实需要精简，先跑一遍所有要用的子命令，确认哪些 jar 被实际加载了再删。
5.5 坑五：AVD 创建成功但模拟器起不来
现象是avdmanager create avd返回成功，但emulator -avd启动时报Cannot find AVD或者卡在黑屏。原因通常是$HOME/.android/avd/权限不对，或者ANDROID_AVD_HOME指向了别处。解决办法是检查这个目录的属主和权限，确保当前用户可读写；如果设过ANDROID_AVD_HOME，确认它和avdmanager实际写入的路径一致。另外，system-images的架构要和宿主机匹配，x86_64 镜像在 ARM 机器上跑不起来。
6. 把命令行工具塞进 CI 镜像：一个可复用的 Dockerfile 片段
最后一章落到具体技巧上。我平时会把这份命令行工具固化进构建镜像，避免每次流水线都重新下载。下面是一个精简但可用的 Dockerfile 片段，基于常见的 Linux 基础镜像。
FROM ubuntu:22.04 # 装 Java 和基础工具，unzip 必须有 RUN apt-get update && apt-get install -y \ openjdk-17-jre-headless \ unzip \ wget \ && rm -rf /var/lib/apt/lists/* # 设定 SDK 根目录 ENV ANDROID_HOME=/opt/android-sdk ENV ANDROID_SDK_ROOT=/opt/android-sdk ENV PATH=${ANDROID_HOME}/cmdline-tools/latest/bin:${ANDROID_HOME}/platform-tools:${PATH} # 把命令行工具复制进来并摆正目录层级 COPY commandlinetools-linux-9477386-latest.zip /tmp/tools.zip RUN mkdir -p ${ANDROID_HOME}/cmdline-tools \ && unzip /tmp/tools.zip -d /tmp/tools-extract \ && mv /tmp/tools-extract/cmdline-tools ${ANDROID_HOME}/cmdline-tools/latest \ && rm -rf /tmp/tools.zip /tmp/tools-extract # 接受许可并安装最小包集合 RUN yes | sdkmanager --sdk_root=${ANDROID_HOME} --licenses \ && sdkmanager --sdk_root=${ANDROID_HOME} \ "platform-tools" \ "platforms;android-34" \ "build-tools;34.0.0" # 验证工具可用 RUN sdkmanager --version && apkanalyzer --version这个片段里有几个参数值得说。openjdk-17-jre-headless是 headless 版本，不带图形库，体积小，适合 CI。COPY那一步假设 zip 和 Dockerfile 在同一构建上下文里，如果你从网络拉，换成wget并校验哈希。yes | sdkmanager --licenses放在RUN里，利用 Docker 层缓存，只要前面的指令不变，许可这一步不会重复执行。最后的apkanalyzer --version是冒烟验证，如果lib目录缺 jar，这一步就会失败，把问题拦在镜像构建阶段，而不是等到跑流水线时才暴露。
验证方法上，我一般会再跑一条apkanalyzer apk file-size对一个已知 APK 做实际分析，确认不是只有--version能跑。如果这一步通过，说明r8.jar、guava、lint-checks这些依赖都加载正常。
从那以后我每次做 CI 镜像，都会在构建阶段强制走一遍sdkmanager --version加apkanalyzer实际分析，不再只看docker build成功就放心。希望帮到你。
本文还有配套的精品资源，点击获取
