简介这份资源是面向 Linux 平台开发者的 Android 命令行工具包适合不想安装完整 Android Studio、却需要构建与调试 Android 应用的中高级开发者及 CI 环境维护人员。压缩包共 104 个文件约 141.94MB以 93 个 jar 库文件为核心辅以 sdkmanager、avdmanager、apkanalyzer、lint、retrace、profgen、screenshot2、resourceshrinker 等可执行脚本与说明文档覆盖 SDK 包管理、虚拟设备创建、APK 分析、代码检查与混淆还原等环节。借助其中的 sdkmanager可在无图形界面的服务器上按需拉取 platform、build-tools 等 SDK 组件配合 avdmanager 创建管理模拟器用 apkanalyzer 与 lint 完成包体分析与静态检查适合自动化构建、持续集成及轻量级开发场景。目前已有 152 人学习下载可作为搭建纯命令行 Android 开发环境的实用工具集。1. 命令行工具包那个 10406996 版本号背后到底藏着什么如果你在 CI 流水线里见过commandlinetools-linux-10406996-latest.zip这个文件名大概率是在配置 Android 构建环境时被它卡过一次。这个压缩包是 Android SDK 的命令行工具集版本号 10406996 对应的是某一版 cmdline-tools解压后你会得到sdkmanager、avdmanager、apkanalyzer等一批没有图形界面的工具。它解决的核心问题是在没有 Android Studio 的 Linux 服务器、容器或远程开发机上依然能完整地安装 SDK 组件、接受许可协议、创建模拟器并构建 APK。适合谁适合需要把 Android 构建塞进 Docker 镜像、Jenkins/GitLab CI 流水线或者单纯想在轻量云主机上跑gradlew assembleRelease的后端和移动端工程师。这个包本身不神秘但目录结构、环境变量和许可协议这三件事每年都要让一批人翻车。2. 解压之后先别急着配环境变量目录结构与 sdkmanager 的真实调用链拿到commandlinetools-linux-10406996-latest.zip之后最常见的错误操作是直接unzip到某个目录然后把bin加进PATH接着运行sdkmanager --list发现报错说找不到sdkmanager或者提示Warning: Could not create settings。这不是包坏了而是 cmdline-tools 对目录层级有硬性要求。它期望自己被放在$ANDROID_HOME/cmdline-tools/version/下面而不是直接铺在$ANDROID_HOME根目录。如果你把解压出来的cmdline-tools文件夹直接当成 SDK 根sdkmanager在解析相对路径时会找不到licenses和platforms的预期位置后续安装组件就会写到一个奇怪的地方去。2.1 正确的解压与目录布局我一般会在 Linux 上这样操作假设目标 SDK 根目录是/opt/android-sdk# 创建 SDK 根目录和 cmdline-tools 的版本目录 mkdir -p /opt/android-sdk/cmdline-tools/latest # 解压到临时目录避免直接铺开 unzip commandlinetools-linux-10406996-latest.zip -d /tmp/cmdline-tools-tmp # 把解压出来的 cmdline-tools 内容移动到 latest 下 # 注意压缩包内层通常还有一个 cmdline-tools 文件夹 mv /tmp/cmdline-tools-tmp/cmdline-tools/* /opt/android-sdk/cmdline-tools/latest/ # 清理临时目录 rm -rf /tmp/cmdline-tools-tmp这段逻辑的关键在于latest这个目录名。cmdline-tools 允许你用latest作为版本别名也可以换成10406996这样的具体版本号。用latest的好处是环境变量里写一次就不用改坏处是当你想同时保留多个版本做对比时会冲突。移动完成后/opt/android-sdk/cmdline-tools/latest/bin/sdkmanager应该存在且可执行。如果mv之后发现bin目录不见了说明压缩包内层结构和我描述的不一样先用unzip -l看一眼列表再决定移动哪一层。2.2 环境变量与 sdkmanager 的首次运行目录摆对之后环境变量只需要两个ANDROID_HOME指向 SDK 根PATH里加上 cmdline-tools 的bin。export ANDROID_HOME/opt/android-sdk export PATH$ANDROID_HOME/cmdline-tools/latest/bin:$PATH # 验证 sdkmanager 能否正常启动 sdkmanager --version如果这一步输出了版本号类似10.0这样的字符串说明调用链通了。如果报Error: Could not determine SDK root九成是ANDROID_HOME没设对或者你把 cmdline-tools 放到了$ANDROID_HOME/tools这种旧版布局里。旧版tools目录和新版cmdline-tools是两套东西不要混用。sdkmanager --version能跑通之后先别急着--list因为首次运行会尝试创建~/.android目录并写缓存在某些容器环境里如果HOME没设置或者不可写会直接抛异常。容器里我习惯显式指定-Duser.home或者确保HOME/root且可写。2.3 用 sdkmanager 安装 platform 与 build-tools 的参数拆解sdkmanager的安装命令看起来简单但参数顺序和包名格式经常让人写错。下面这条命令安装 Android 平台 34 和对应的构建工具# 安装 platform 和 build-tools--sdk_root 显式指定根目录 sdkmanager --sdk_root$ANDROID_HOME \ platforms;android-34 \ build-tools;34.0.0 \ platform-tools # 接受所有许可协议避免交互式确认卡住 CI yes | sdkmanager --sdk_root$ANDROID_HOME --licenses--sdk_root这个参数在目录布局正确时可以省略但在 CI 脚本里我强烈建议显式写上因为一旦ANDROID_HOME被其他步骤覆盖sdkmanager可能会把组件装到默认的~/Android/Sdk去导致 Gradle 找不到。包名里的分号是必须的platforms;android-34不能写成platforms/android-34。--licenses那一步会逐条列出协议yes |管道把所有确认都喂进去这是 CI 里最省事的做法。注意yes在某些精简版 Linux 镜像里可能不存在那就用printf y\n%.0s {1..50} | sdkmanager --licenses代替。3. 在 CI 与容器里跑通构建从 zip 到 APK 的最小闭环把 cmdline-tools 装好只是第一步真正的目标是让./gradlew assembleDebug在无图形界面的 Linux 上跑通。这里面的坑集中在许可协议、JDK 版本匹配和 Gradle 的 SDK 定位逻辑上。很多人以为sdkmanager装完组件就万事大吉结果 Gradle 一跑就报SDK location not found或者Failed to install the following Android SDK packages as some licences have not been accepted。这一章把最小闭环拆开每一步都给出可复制的命令和失败时的排查方向。3.1 许可协议到底写到了哪里sdkmanager --licenses执行后会在$ANDROID_HOME/licenses/下生成若干文本文件文件名是哈希值内容是一串十六进制。Gradle 在构建时会检查这个目录如果对应的许可文件缺失就会拒绝使用已安装的组件。常见现象是你明明在本地接受过许可但 Docker 镜像里重新装了一遍 SDKlicenses目录是空的CI 就挂了。# 检查 licenses 目录是否生成了文件 ls -la $ANDROID_HOME/licenses/ # 如果没有手动触发一次并确认写入 yes | sdkmanager --sdk_root$ANDROID_HOME --licenses ls -la $ANDROID_HOME/licenses/如果licenses目录始终为空检查sdkmanager是否真的把 SDK 根识别成了$ANDROID_HOME。可以在命令后加--verbose看它实际使用的路径。另一个容易忽略的点是--licenses必须在安装了至少一个需要许可的组件之后运行才有意义空 SDK 上跑它可能什么都不写。我一般会先装platform-tools再跑--licenses顺序反了会浪费一轮时间。3.2 Dockerfile 里把 commandlinetools 固化进镜像下面是一个精简的 Dockerfile 片段展示如何把commandlinetools-linux-10406996-latest.zip和 JDK 一起打进镜像并预装常用组件。假设 zip 文件已经放在构建上下文里。FROM ubuntu:22.04 # 安装基础依赖unzip 和 openjdk-17 是必须的 RUN apt-get update apt-get install -y \ unzip wget openjdk-17-jdk-headless \ rm -rf /var/lib/apt/lists/* ENV ANDROID_HOME/opt/android-sdk ENV PATH$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$PATH # 复制并解压 cmdline-tools注意目录层级 COPY commandlinetools-linux-10406996-latest.zip /tmp/ RUN mkdir -p $ANDROID_HOME/cmdline-tools/latest \ unzip /tmp/commandlinetools-linux-10406996-latest.zip -d /tmp/cmdline-tools-tmp \ mv /tmp/cmdline-tools-tmp/cmdline-tools/* $ANDROID_HOME/cmdline-tools/latest/ \ rm -rf /tmp/cmdline-tools-tmp /tmp/commandlinetools-linux-10406996-latest.zip # 安装组件并接受许可yes 管道确保非交互 RUN yes | sdkmanager --sdk_root$ANDROID_HOME \ platform-tools \ platforms;android-34 \ build-tools;34.0.0 \ yes | sdkmanager --sdk_root$ANDROID_HOME --licenses这个 Dockerfile 的逻辑说明openjdk-17-jdk-headless是当前 AGP 8.x 推荐的 JDK 版本用 11 会在 Gradle 配置阶段报Unsupported class file major version。PATH里把platform-tools也加进去是为了让adb在容器里可直接调用虽然纯构建不一定需要。yes |管道在RUN指令里是安全的因为sdkmanager读取标准输入管道关闭后命令正常退出。参数上--sdk_root在 Docker 构建阶段显式指定避免HOME未设置导致的路径漂移。如果构建时卡在sdkmanager下载组件检查容器是否有外网访问或者是否配置了内网镜像源。3.3 Gradle 如何找到这个 SDKGradle 定位 SDK 的顺序是local.properties里的sdk.dir 环境变量ANDROID_HOMEANDROID_SDK_ROOT。在 CI 里我一般只依赖ANDROID_HOME不写local.properties因为那个文件通常被.gitignore排除写了也提交不上去。但如果你在本地开发机上同时有多个 SDK 版本local.properties可以强制指定。# 在项目根目录生成 local.properties仅本地调试用 echo sdk.dir$ANDROID_HOME local.properties # CI 里更推荐直接导出环境变量 export ANDROID_HOME/opt/android-sdk ./gradlew assembleDebug --no-daemon--no-daemon在 CI 里是个好习惯避免 Gradle 守护进程在容器退出后残留。如果assembleDebug报SDK location not found先echo $ANDROID_HOME确认变量在当前 shell 里可见再检查$ANDROID_HOME/platforms/android-34是否存在。有时候sdkmanager装完了但目录名是android-34而不是android-34-ext1之类的变体Gradle 的compileSdk写的是哪个就要对应哪个。4. 避坑与排查版本号、许可和路径的三重陷阱这一章记录的是我在不同 Linux 发行版和容器环境里反复遇到的五类问题。每一条都按「现象 → 原因 → 解决」写方便你直接对照排查。这些坑不涉及任何特定公司的内部系统都是 cmdline-tools 本身的行为特性。4.1 现象sdkmanager 报 “Could not create settings” 并退出原因sdkmanager启动时会尝试在~/.android下写一个 settings 文件如果HOME环境变量未设置、指向不存在的目录或者该目录没有写权限就会直接失败。容器里以非 root 用户运行、或者HOME被设成/nonexistent时最常见。解决显式设置HOME到一个可写目录或者在启动命令前加-Duser.home。例如export HOME/tmp sdkmanager --list。如果是在 Dockerfile 里确保RUN指令执行时HOME有值Ubuntu 基础镜像默认HOME/root一般没问题但 Alpine 镜像需要额外注意。4.2 现象安装组件时提示 “Warning: Failed to find package” 但包名看起来没错原因包名拼写错误或者该版本在当前的仓库源里不存在。sdkmanager --list输出的包名是权威来源但输出很长容易看漏。另一个原因是--sdk_root指向了一个已经有旧版tools目录的路径sdkmanager在解析可用包列表时被旧目录干扰。解决先跑sdkmanager --list | grep platforms;android-34确认包名精确匹配。如果列表里没有说明该版本尚未发布或已被移除换一个相邻版本。如果列表里有但安装仍失败检查$ANDROID_HOME下是否有残留的tools目录有的话先移走再试。4.3 现象CI 里yes | sdkmanager --licenses卡住不退出原因yes命令在某些精简镜像里不存在管道左侧为空sdkmanager等待标准输入永远等不到数据。另一种可能是sdkmanager在等待一个需要输入y或n之外的确认比如输入路径。解决用printf替代yes或者直接检查镜像里是否有yes。更稳妥的做法是用--licenses配合--verbose先看它到底在等什么。如果只是许可确认printf y\n%.0s {1..100} | sdkmanager --licenses可以覆盖足够多的确认次数。4.4 现象Gradle 构建报 “Failed to install the following Android SDK packages as some licences have not been accepted”原因licenses目录下的许可文件与当前安装的组件不匹配。常见于先接受了旧版组件的许可后来升级了build-tools版本新版本对应的许可哈希没有生成。解决重新运行yes | sdkmanager --sdk_root$ANDROID_HOME --licenses确保所有已安装组件的许可都被覆盖。如果仍然报错删除$ANDROID_HOME/licenses目录后重新接受一次让sdkmanager重新生成全部许可文件。4.5 现象解压后sdkmanager可执行但运行报 “No such file or directory”原因压缩包里的sdkmanager是一个 shell 脚本它依赖同目录下的lib文件夹里的 jar 包。如果你只复制了bin目录而没有复制lib脚本找不到依赖。另一种可能是脚本的 shebang 指向了一个不存在的解释器路径。解决确保cmdline-tools/latest/下同时有bin、lib、source.properties等完整内容。用file sdkmanager看它是什么类型的文件用head -1 sdkmanager看 shebang 行。如果 shebang 是#!/usr/bin/env bash而镜像里没有 bash换成sh或安装 bash。5. 进阶技巧用 sdkmanager 做版本锁定与离线缓存当你把commandlinetools-linux-10406996-latest.zip用在多台机器或频繁重建的 CI 环境里每次从网络拉取组件会拖慢流水线而且上游仓库的组件版本可能悄悄变化导致今天能构建的代码明天就挂。这一章讲两个具体技巧用sdkmanager导出已安装包列表做版本锁定以及把 SDK 目录做成离线缓存层。最后用一个我自己的习惯收住。5.1 导出与恢复已安装包列表sdkmanager --list_installed可以列出当前 SDK 里所有已安装的包格式是包名 | 版本 | 描述。把这个输出保存下来在另一台机器上就可以按列表精确安装避免版本漂移。# 导出已安装包列表只取包名和版本列 sdkmanager --sdk_root$ANDROID_HOME --list_installed | \ awk -F| /^ [a-z]/ {gsub(/ /,,$1); gsub(/ /,,$2); print $1$2} \ sdk-packages.txt # 在另一台机器上按列表安装 while IFS read -r pkg ver; do sdkmanager --sdk_root$ANDROID_HOME ${pkg};${ver} done sdk-packages.txt这段脚本的逻辑说明awk用|分割匹配以两个空格开头的行--list_installed的输出格式去掉包名和版本列的空格拼成包名版本的形式。恢复时用while read逐行读取IFS按等号拆分。参数上--list_installed不需要额外参数但输出里包含表头和分隔线awk的正则过滤掉了它们。如果包名里本身包含等号极少见这个脚本会出错但 Android SDK 包名目前只用分号和短横线所以安全。5.2 把 SDK 目录做成 Docker 缓存层在 Dockerfile 里把 SDK 安装步骤放在项目代码复制之前这样只要commandlinetools-linux-10406996-latest.zip和包列表不变Docker 就会复用缓存层跳过整个 SDK 下载过程。# 先复制 cmdline-tools 和包列表 COPY commandlinetools-linux-10406996-latest.zip sdk-packages.txt /tmp/ # 安装 SDK这一层会被缓存 RUN mkdir -p $ANDROID_HOME/cmdline-tools/latest \ unzip /tmp/commandlinetools-linux-10406996-latest.zip -d /tmp/cmdline-tools-tmp \ mv /tmp/cmdline-tools-tmp/cmdline-tools/* $ANDROID_HOME/cmdline-tools/latest/ \ while IFS read -r pkg ver; do \ sdkmanager --sdk_root$ANDROID_HOME ${pkg};${ver}; \ done /tmp/sdk-packages.txt \ yes | sdkmanager --sdk_root$ANDROID_HOME --licenses # 再复制项目代码代码变动不会触发 SDK 层重建 COPY . /app WORKDIR /app RUN ./gradlew assembleDebug --no-daemon这个写法的关键点是COPY的顺序sdk-packages.txt和 zip 文件先复制项目代码后复制。Docker 的层缓存机制会检查每条指令的输入文件是否变化只要包列表和 zip 不变RUN那层就直接命中缓存。参数上--no-daemon在容器构建里避免守护进程残留--sdk_root保持显式指定。如果构建时发现缓存没命中用docker build --no-cache对比一次确认是哪个文件的时间戳变了。5.3 一个我自己的习惯我习惯在每次更新sdk-packages.txt之后先在本地用sdkmanager --list_installed核对一遍确认没有多出意料之外的包。因为sdkmanager在安装某个包时可能会自动拉取它依赖的platform-tools或emulator这些隐式依赖如果不记录到列表里换一台机器恢复时就会缺东西。另一个习惯是永远不在 CI 脚本里写sdkmanager --update因为--update会把所有组件升到最新而最新版本和你的build-tools版本可能不兼容。锁定版本手动升级比自动更新省心得多。希望帮到你。本文还有配套的精品资源点击获取