简介Android 命令行工具commandlinetools-linux-13114758-latest.zip面向 Linux 开发者适合不想安装完整 Android Studio、又希望通过脚本自动化管理 SDK 组件的场景。压缩包共 108 个文件大小约 157.13MB其中 95 个 jar 文件提供核心运行支撑sdkmanager、avdmanager、apkanalyzer、lint、d8/r8、screenshot2、profgen 等可执行工具分别负责包管理、虚拟设备管理、APK 分析、代码检查与构建编译。目前已有 282 人学习下载适合熟悉命令行操作的中高级 Android 开发者。借助这套工具链开发者可通过 sdkmanager 灵活拉取 NDK、模拟器等平台组件并将其接入自动化构建与持续集成流程替代传统 IDE 中的图形界面操作readme、properties 等辅助文件也便于快速完成环境配置与问题排查。工具包内包含 cmdline-tools 目录集中放置了命令行操作所需的可执行文件与运行库整体结构紧凑既保留了 Linux 命令行的工作习惯又降低了维护多版本 SDK 时的重复劳动适合需要批量部署和可重复构建的团队或个人使用。1. 命令行工具包解压之后才是真正开始拿到commandlinetools-linux-13114758-latest.zip这个文件名时容易产生一个错觉解压完就有一个能用的 Android 构建环境。实际解压后只有一个cmdline-tools目录里面是bin和lib敲sdkmanager大概率会报“command not found”因为环境变量没配、目录没摆对、JDK 版本也可能不对。这个 zip 是 Android SDK 的“安装器”不是 SDK 本身它负责把platform-tools、build-tools、platforms;android-XX、system-images等组件拉取到本地。对一线工程师来说这个包的价值体现在无人值守的 CI 环境、容器构建镜像、以及不想装完整 Android Studio 的 Linux 开发机上。命令行工具包里的sdkmanager可以做静默安装和版本锁定avdmanager能创建模拟器镜像apkanalyzer能直接读取 APK 的 manifest 和资源信息。全文围绕这个工具包在 Linux 上的落地把目录结构、环境变量、常用组件、隐藏参数和实际坑位一次说清。2. 理解 commandlinetools 的目录结构与版本识别2.1 zip 里到底有什么一个自举的包管理器解压commandlinetools-linux-13114758-latest.zip后得到的是cmdline-tools/ ├── bin/ │ ├── avdmanager │ ├── lint │ ├── profgen │ ├── retrace │ ├── screenshot2 │ └── sdkmanager └── lib/ ├── dalvik-dx.jar ├── dvlib.jar ├── layoutlib.jar ├── repository.xml └── sdk-common.jarbin下的工具本质是 shell 脚本真正的逻辑在lib里的 Java 代码中。最核心的依赖是本地 JDK脚本开头会通过JAVA_HOME或PATH查找java找不到就直接退出。repository.xml这个文件容易忽略它缓存了 SDK 组件的元数据版本号、依赖关系、下载地址sdkmanager检查更新和解析依赖时都需要它。如果这个文件损坏常见的表现是sdkmanager --list卡住或报 XML 解析错误删除后重跑命令会自动重建。2.2 为什么必须放到 cmdline-tools/latest 目录commandlinetools包自 2022 年起引入了“latest”目录约定。下载后默认结构是cmdline-tools/如果直接配置 PATHsdkmanager 会提示目录层级不正确。标准做法是把它移到 SDK 根目录下的cmdline-tools/latestexport ANDROID_HOME$HOME/android-sdk mkdir -p $ANDROID_HOME/cmdline-tools unzip commandlinetools-linux-13114758-latest.zip -d /tmp/cmdline-tools mv /tmp/cmdline-tools/cmdline-tools $ANDROID_HOME/cmdline-tools/latest移动后再用find $ANDROID_HOME -name sdkmanager确认路径。sdkmanager依赖ANDROID_HOME环境变量定位 SDK 根目录然后从cmdline-tools/latest/lib加载运行库。目录层级不对会触发一个很隐蔽的错误——命令能执行但下载的组件被写到了错误位置。2.3 版本号 13114758 能告诉我们什么13114758不是传统语义化版本号而是 Google 内部构建系统的构建序列号每个 cmdline-tools 发布版本都对应唯一的构建号。它对应的发布渠道stable/beta/canary可以从repository.xml里的tool节点确认也可以直接跑$ANDROID_HOME/cmdline-tools/latest/bin/sdkmanager --version输出会是类似13.0.0这样的版本。这个信息在 CI 里很重要因为团队经常会问“当前用的 SDK 工具到底是不是稳定版”。构建号还能辅助判断和 Android Studio 的兼容性——Studio 自带的 cmdline-tools 版本如果低于项目期望值Gradle 会警告。提示实际下载时文件名可能写成commandlinetools-linux-13114758_latest.zip下划线分隔解压内容一致不影响后续操作。3. 用 sdkmanager 在 Linux 上安装 Android SDK 组件3.1 最小可用安装三条命令跑通sdkmanager 是命令行工具包里的安装主力职责是下载、安装、卸载和列出 SDK 组件。最小安装流程如下export ANDROID_HOME$HOME/android-sdk export PATH$PATH:$ANDROID_HOME/cmdline-tools/latest/bin # 接收所有 license yes | sdkmanager --licenses # 安装最基础的组件 sdkmanager --install platform-tools platforms;android-34 build-tools;34.0.0第一条命令里的yes管道用于自动应答 license 协议否则会交互式卡在y/N提示。第二条命令的包名有固定格式platform-tools没有版本号永远跟随最新platforms和build-tools必须用分号分隔并带上 API Level 或构建工具版本。安装完成后建议验证目录ls $ANDROID_HOME/platforms/android-34/android.jar ls $ANDROID_HOME/build-tools/34.0.0/aapt2 ls $ANDROID_HOME/platform-tools/adb这能确认android.jar编译用、aapt2资源打包和adb调试都真实存在而不只是 sdkmanager 认为安装成功。3.2 组件选型一套可持续维护的包名清单实际项目里常用的 SDK 组件远不止三个。下表是调试时高频使用的包名和用途sdkmanager 包名安装内容典型用途platform-toolsadb、fastboot、e2fsdroid 等设备连接、刷机build-tools;34.0.0aapt2、aidl、zipalign、apksigner构建、签名、对齐platforms;android-34android.jar、build.prop编译时引用 APIsystem-images;android-34;google_apis;x86_64完整系统镜像创建模拟器ndk;26.1.10909125NDK 工具链编译 C/C 代码cmake;3.22.1CMake 与 ninja驱动 NDK 构建emulator模拟器二进制运行 AVD日常开发机的标准组合是 platform-tools platforms build-tools加上对应 API Level 的 system image。只有 NDK 需求才装最后一个。注意包名里的版本号精确到补丁级build-tools;34这种写法是无效的必须写出完整版本。半年前踩过这个坑CI 日志里报Failed to find package build-tools;34当时查了半天才发现少写了.0.0。3.3 无人值守安装怎么做到完全静默在 CI 或容器构建环境里交互式输入是灾难。sdkmanager 支持完全静默模式sdkmanager --install platforms;android-34 build-tools;34.0.0 --channel0 --sdk_root$ANDROID_HOME echo y | sdkmanager --licenses --sdk_root$ANDROID_HOME--channel0表示只从稳定版渠道安装这个参数在团队统一版本时很关键。--sdk_root显式指定根目录避免环境变量传递不一致时把组件装错地方。锁版本的做法是把包名写死在构建脚本里并且用 checksum 校验下载echo 9a00694c86f94e28d42b5b6f9a0c3a9b | sdkmanager --install platforms;android-34 --sdk_root$ANDROID_HOME如果安装过程中 license 接收失败日志会出现Failed to install packages的提示通常是因为 license 文件目录权限不对。先执行chmod -R uw $ANDROID_HOME/licenses再重试即可。3.4 官方源之外的问题定位思路sdkmanager 默认从 Google 官方仓库下载网络不佳时表现为“解析元数据超时”或“download interrupted: Connection reset”。排查时抓两个位置一是lib/repository.xml的更新时间二是 sdkmanager 的日志输出。常用诊断命令sdkmanager --list --verbose 21 | tail -50 sdkmanager --list_installed--list_installed能列出当前已装的组件用来对比 CI 和本地环境差异。--verbose能显示 HTTP 请求细节包括实际的下载 URL方便确认是否走了代理。如果检查发现本地与 CI 组件列表不一致对齐版本后一般能解决“本地编得过、CI 编不过”的问题。4. 用 avdmanager 和 apkanalyzer 完成模拟器与 APK 分析4.1 创建模拟器系统镜像与设备定义的匹配逻辑avdmanager 是创建和管理 Android 虚拟设备AVD的命令行入口。大致流程是写system image的包名让 sdkmanager 装好镜像然后 avdmanager 创建 AVD 实例。sdkmanager --install system-images;android-34;google_apis;x86_64 avdmanager create avd -n ci_test -k system-images;android-34;google_apis;x86_64 -d pixel_5 --force-d pixel_5指定设备定义控制屏幕分辨率、内存参数和可用按键。--force在 AVD 名已存在时覆盖而不提示。创建好后用avdmanager list avd确认 AVD 出现在列表。模拟器实际启动由emulator组件提供而 cmdline-tools 包里并没有带emulator需要单独安装。很多新手会在这时去编辑config.ini来调 memory但标准做法是先查设备定义avdmanager list device | grep -A 10 pixel_54.2 命令行里跑模拟器的两个关键技巧模拟器的-no-window和-no-audio参数是 CI 环境里最常见的组合$ANDROID_HOME/emulator/emulator -avd ci_test -no-window -no-audio -no-boot-anim -gpu swiftshader_indirect启动后要轮询等待系统完全起来常见做法是循环检测sys.boot_completedadb wait-for-device until adb shell getprop sys.boot_completed 2/dev/null | grep -q 1; do sleep 5 doneswiftshader_indirect用软件渲染 GPU避免物理 GPU 带来的兼容性问题。-no-boot-anim能减少启动时间约 1015 秒。执行完测试后建议立刻关闭模拟器adb emu kill4.3 apkanalyzer不写代码直接读 APKapkanalyzer 读取 APK 的 manifest、资源和 dex 信息的能力在排查“包名写没写对”“versionCode 对不对”这类问题时特别有用。基础命令是apkanalyzer manifest print app-release.apk这个命令会输出完整 AndroidManifest.xml包括权限列表、四大组件和应用 ID。只看某个属性也有专门参数apkanalyzer manifest application-id app-release.apk apkanalyzer manifest version-name app-release.apk apkanalyzer apk summary app-release.apkapk summary返回 APK 大小、minSdk、targetSdk 三项核心信息适合快速验证构建产物是否符合预期。需要确认某个 Activity 是否存在时用manifest activities结合 grep 即可。4.4 lint 的实用跑法跳过 Gradle 直接命令行执行lint 独立于 Gradle 运行可以直接扫描源码目录输出问题报告。工作量较小的检查这样跑lint --check GradleDependency --severity warning app/src/main--check指定检查规则--severity warning控制最低输出级别为 warning。想要 HTML 报告方便在浏览器里看lint --html /tmp/lint-report.html app/src/mainlint 的这些功能在 CI 里可以作为 Gradle lint 任务的轻量替代先用命令行快速扫一遍再决定是否进入完整构建流程。比起改build.gradle里的lintOptions这种临时用法更适合排查问题。5. 环境隔离、复杂变量组合与高阶排查技巧5.1 多版本共存让开发者机器里的 SDK 和 CI 不必一致同一台机器维护两个 Android SDK 根目录是常见需求比如一个给内部项目用稳定版另一个给新项目试 Preview API。命令行工具包的--sdk_root参数可以让同一套 cmdline-tools 操作不同的 SDK 目录sdkmanager --sdk_root/opt/android-sdk-stable --install platforms;android-34 sdkmanager --sdk_root/opt/android-sdk-preview --install platforms;android-34 platforms;android-35两套 SDK 并存时ANDROID_HOME只能指向其中一个但如果某个构建脚本内部显式写死了ANDROID_HOME必须确认它是从环境变量读的还是硬编码的。硬编码场景建议用--sdk_root显式覆盖避免构建脚本之间相互污染。5.2 一组可复制的高阶参数组合把前面所有技巧拼在一起构成一个可在 Linux 服务器上直接使用的完整脚本块export ANDROID_HOME$HOME/android-sdk export PATH$ANDROID_HOME/cmdline-tools/latest/bin:$PATH # 安装全部所需组件--channel0 锁稳定版 sdkmanager --channel0 \ --install platform-tools \ platforms;android-34 \ build-tools;34.0.0 \ system-images;android-34;google_apis;x86_64 # 验证 sdkmanager 自带工具版本 sdkmanager --version # 创建 AVD 并冷启动 avdmanager create avd -n ci_test -k system-images;android-34;google_apis;x86_64 -d pixel_5 --force $ANDROID_HOME/emulator/emulator -avd ci_test -no-window -no-audio -no-boot-anim -gpu swiftshader_indirect adb wait-for-device # 等 sys.boot_completed until adb shell getprop sys.boot_completed 2/dev/null | grep -q 1; do sleep 5; done执行时如果卡在某一个环节优先看环境变量env | grep -E ANDROID|JAVA原因是脚本多次 export 后可能覆盖了系统原有的ANDROID_SDK_ROOT。sdkmanager 读取优先级是--sdk_root参数大于ANDROID_SDK_ROOT大于ANDROID_HOME在不传参时两个环境变量若指向不同目录行为会变得很难预期。5.3 日志、退出码与半成品组件残留sdkmanager 的退出码设计并不复杂0 表示成功非 0 表示失败。但失败后不一定回滚可能出现组件半安装状态比如platforms/android-34目录存在但android.jar缺失。验证干净环境的方法sdkmanager --list_installed | grep android-34 test -f $ANDROID_HOME/platforms/android-34/android.jar echo OK如果android.jar缺失直接重装该组件即可sdkmanager --install platforms;android-34。卸载组件时要注意依赖关系比如先卸载了platform-toolsadb 相关脚本会直接失效但 sdkmanager 本身不受影响。提示遇到“java.lang.UnsupportedClassVersionError”时多半是 JDK 版本过低cmdline-tools 需要 JDK 17 及以上。执行java -version确认版本必要时安装新版 OpenJDK 后重新设置JAVA_HOME。5.4 版本锁定在 CI 中固定 commandlinetools 版本团队协作中commandlinetools 本身的版本漂移比 SDK 组件版本漂移更隐蔽。构建机上普遍用-latest文件名下载一旦仓库发布了新构建号下次 CI 拉取就会静默换版本。锁定的做法是保存完整构建号# 构建脚本开头记录 echo cmdline-tools version: $(sdkmanager --version)配合repository.xml的缓存到制品仓库能让构建在离线环境也不受影响。先把cmdline-tools的 tar 包推送到内网再把lib/repository.xml一并缓存之后所有安装操作都走内网源。这种做法在离线或半离线项目里是稳定输出来源的核心手段。本文还有配套的精品资源点击获取 Android commandlinetools 在 Linux 下的完整使用指南
简介Android 命令行工具commandlinetools-linux-13114758-latest.zip面向 Linux 开发者适合不想安装完整 Android Studio、又希望通过脚本自动化管理 SDK 组件的场景。压缩包共 108 个文件大小约 157.13MB其中 95 个 jar 文件提供核心运行支撑sdkmanager、avdmanager、apkanalyzer、lint、d8/r8、screenshot2、profgen 等可执行工具分别负责包管理、虚拟设备管理、APK 分析、代码检查与构建编译。目前已有 282 人学习下载适合熟悉命令行操作的中高级 Android 开发者。借助这套工具链开发者可通过 sdkmanager 灵活拉取 NDK、模拟器等平台组件并将其接入自动化构建与持续集成流程替代传统 IDE 中的图形界面操作readme、properties 等辅助文件也便于快速完成环境配置与问题排查。工具包内包含 cmdline-tools 目录集中放置了命令行操作所需的可执行文件与运行库整体结构紧凑既保留了 Linux 命令行的工作习惯又降低了维护多版本 SDK 时的重复劳动适合需要批量部署和可重复构建的团队或个人使用。1. 命令行工具包解压之后才是真正开始拿到commandlinetools-linux-13114758-latest.zip这个文件名时容易产生一个错觉解压完就有一个能用的 Android 构建环境。实际解压后只有一个cmdline-tools目录里面是bin和lib敲sdkmanager大概率会报“command not found”因为环境变量没配、目录没摆对、JDK 版本也可能不对。这个 zip 是 Android SDK 的“安装器”不是 SDK 本身它负责把platform-tools、build-tools、platforms;android-XX、system-images等组件拉取到本地。对一线工程师来说这个包的价值体现在无人值守的 CI 环境、容器构建镜像、以及不想装完整 Android Studio 的 Linux 开发机上。命令行工具包里的sdkmanager可以做静默安装和版本锁定avdmanager能创建模拟器镜像apkanalyzer能直接读取 APK 的 manifest 和资源信息。全文围绕这个工具包在 Linux 上的落地把目录结构、环境变量、常用组件、隐藏参数和实际坑位一次说清。2. 理解 commandlinetools 的目录结构与版本识别2.1 zip 里到底有什么一个自举的包管理器解压commandlinetools-linux-13114758-latest.zip后得到的是cmdline-tools/ ├── bin/ │ ├── avdmanager │ ├── lint │ ├── profgen │ ├── retrace │ ├── screenshot2 │ └── sdkmanager └── lib/ ├── dalvik-dx.jar ├── dvlib.jar ├── layoutlib.jar ├── repository.xml └── sdk-common.jarbin下的工具本质是 shell 脚本真正的逻辑在lib里的 Java 代码中。最核心的依赖是本地 JDK脚本开头会通过JAVA_HOME或PATH查找java找不到就直接退出。repository.xml这个文件容易忽略它缓存了 SDK 组件的元数据版本号、依赖关系、下载地址sdkmanager检查更新和解析依赖时都需要它。如果这个文件损坏常见的表现是sdkmanager --list卡住或报 XML 解析错误删除后重跑命令会自动重建。2.2 为什么必须放到 cmdline-tools/latest 目录commandlinetools包自 2022 年起引入了“latest”目录约定。下载后默认结构是cmdline-tools/如果直接配置 PATHsdkmanager 会提示目录层级不正确。标准做法是把它移到 SDK 根目录下的cmdline-tools/latestexport ANDROID_HOME$HOME/android-sdk mkdir -p $ANDROID_HOME/cmdline-tools unzip commandlinetools-linux-13114758-latest.zip -d /tmp/cmdline-tools mv /tmp/cmdline-tools/cmdline-tools $ANDROID_HOME/cmdline-tools/latest移动后再用find $ANDROID_HOME -name sdkmanager确认路径。sdkmanager依赖ANDROID_HOME环境变量定位 SDK 根目录然后从cmdline-tools/latest/lib加载运行库。目录层级不对会触发一个很隐蔽的错误——命令能执行但下载的组件被写到了错误位置。2.3 版本号 13114758 能告诉我们什么13114758不是传统语义化版本号而是 Google 内部构建系统的构建序列号每个 cmdline-tools 发布版本都对应唯一的构建号。它对应的发布渠道stable/beta/canary可以从repository.xml里的tool节点确认也可以直接跑$ANDROID_HOME/cmdline-tools/latest/bin/sdkmanager --version输出会是类似13.0.0这样的版本。这个信息在 CI 里很重要因为团队经常会问“当前用的 SDK 工具到底是不是稳定版”。构建号还能辅助判断和 Android Studio 的兼容性——Studio 自带的 cmdline-tools 版本如果低于项目期望值Gradle 会警告。提示实际下载时文件名可能写成commandlinetools-linux-13114758_latest.zip下划线分隔解压内容一致不影响后续操作。3. 用 sdkmanager 在 Linux 上安装 Android SDK 组件3.1 最小可用安装三条命令跑通sdkmanager 是命令行工具包里的安装主力职责是下载、安装、卸载和列出 SDK 组件。最小安装流程如下export ANDROID_HOME$HOME/android-sdk export PATH$PATH:$ANDROID_HOME/cmdline-tools/latest/bin # 接收所有 license yes | sdkmanager --licenses # 安装最基础的组件 sdkmanager --install platform-tools platforms;android-34 build-tools;34.0.0第一条命令里的yes管道用于自动应答 license 协议否则会交互式卡在y/N提示。第二条命令的包名有固定格式platform-tools没有版本号永远跟随最新platforms和build-tools必须用分号分隔并带上 API Level 或构建工具版本。安装完成后建议验证目录ls $ANDROID_HOME/platforms/android-34/android.jar ls $ANDROID_HOME/build-tools/34.0.0/aapt2 ls $ANDROID_HOME/platform-tools/adb这能确认android.jar编译用、aapt2资源打包和adb调试都真实存在而不只是 sdkmanager 认为安装成功。3.2 组件选型一套可持续维护的包名清单实际项目里常用的 SDK 组件远不止三个。下表是调试时高频使用的包名和用途sdkmanager 包名安装内容典型用途platform-toolsadb、fastboot、e2fsdroid 等设备连接、刷机build-tools;34.0.0aapt2、aidl、zipalign、apksigner构建、签名、对齐platforms;android-34android.jar、build.prop编译时引用 APIsystem-images;android-34;google_apis;x86_64完整系统镜像创建模拟器ndk;26.1.10909125NDK 工具链编译 C/C 代码cmake;3.22.1CMake 与 ninja驱动 NDK 构建emulator模拟器二进制运行 AVD日常开发机的标准组合是 platform-tools platforms build-tools加上对应 API Level 的 system image。只有 NDK 需求才装最后一个。注意包名里的版本号精确到补丁级build-tools;34这种写法是无效的必须写出完整版本。半年前踩过这个坑CI 日志里报Failed to find package build-tools;34当时查了半天才发现少写了.0.0。3.3 无人值守安装怎么做到完全静默在 CI 或容器构建环境里交互式输入是灾难。sdkmanager 支持完全静默模式sdkmanager --install platforms;android-34 build-tools;34.0.0 --channel0 --sdk_root$ANDROID_HOME echo y | sdkmanager --licenses --sdk_root$ANDROID_HOME--channel0表示只从稳定版渠道安装这个参数在团队统一版本时很关键。--sdk_root显式指定根目录避免环境变量传递不一致时把组件装错地方。锁版本的做法是把包名写死在构建脚本里并且用 checksum 校验下载echo 9a00694c86f94e28d42b5b6f9a0c3a9b | sdkmanager --install platforms;android-34 --sdk_root$ANDROID_HOME如果安装过程中 license 接收失败日志会出现Failed to install packages的提示通常是因为 license 文件目录权限不对。先执行chmod -R uw $ANDROID_HOME/licenses再重试即可。3.4 官方源之外的问题定位思路sdkmanager 默认从 Google 官方仓库下载网络不佳时表现为“解析元数据超时”或“download interrupted: Connection reset”。排查时抓两个位置一是lib/repository.xml的更新时间二是 sdkmanager 的日志输出。常用诊断命令sdkmanager --list --verbose 21 | tail -50 sdkmanager --list_installed--list_installed能列出当前已装的组件用来对比 CI 和本地环境差异。--verbose能显示 HTTP 请求细节包括实际的下载 URL方便确认是否走了代理。如果检查发现本地与 CI 组件列表不一致对齐版本后一般能解决“本地编得过、CI 编不过”的问题。4. 用 avdmanager 和 apkanalyzer 完成模拟器与 APK 分析4.1 创建模拟器系统镜像与设备定义的匹配逻辑avdmanager 是创建和管理 Android 虚拟设备AVD的命令行入口。大致流程是写system image的包名让 sdkmanager 装好镜像然后 avdmanager 创建 AVD 实例。sdkmanager --install system-images;android-34;google_apis;x86_64 avdmanager create avd -n ci_test -k system-images;android-34;google_apis;x86_64 -d pixel_5 --force-d pixel_5指定设备定义控制屏幕分辨率、内存参数和可用按键。--force在 AVD 名已存在时覆盖而不提示。创建好后用avdmanager list avd确认 AVD 出现在列表。模拟器实际启动由emulator组件提供而 cmdline-tools 包里并没有带emulator需要单独安装。很多新手会在这时去编辑config.ini来调 memory但标准做法是先查设备定义avdmanager list device | grep -A 10 pixel_54.2 命令行里跑模拟器的两个关键技巧模拟器的-no-window和-no-audio参数是 CI 环境里最常见的组合$ANDROID_HOME/emulator/emulator -avd ci_test -no-window -no-audio -no-boot-anim -gpu swiftshader_indirect启动后要轮询等待系统完全起来常见做法是循环检测sys.boot_completedadb wait-for-device until adb shell getprop sys.boot_completed 2/dev/null | grep -q 1; do sleep 5 doneswiftshader_indirect用软件渲染 GPU避免物理 GPU 带来的兼容性问题。-no-boot-anim能减少启动时间约 1015 秒。执行完测试后建议立刻关闭模拟器adb emu kill4.3 apkanalyzer不写代码直接读 APKapkanalyzer 读取 APK 的 manifest、资源和 dex 信息的能力在排查“包名写没写对”“versionCode 对不对”这类问题时特别有用。基础命令是apkanalyzer manifest print app-release.apk这个命令会输出完整 AndroidManifest.xml包括权限列表、四大组件和应用 ID。只看某个属性也有专门参数apkanalyzer manifest application-id app-release.apk apkanalyzer manifest version-name app-release.apk apkanalyzer apk summary app-release.apkapk summary返回 APK 大小、minSdk、targetSdk 三项核心信息适合快速验证构建产物是否符合预期。需要确认某个 Activity 是否存在时用manifest activities结合 grep 即可。4.4 lint 的实用跑法跳过 Gradle 直接命令行执行lint 独立于 Gradle 运行可以直接扫描源码目录输出问题报告。工作量较小的检查这样跑lint --check GradleDependency --severity warning app/src/main--check指定检查规则--severity warning控制最低输出级别为 warning。想要 HTML 报告方便在浏览器里看lint --html /tmp/lint-report.html app/src/mainlint 的这些功能在 CI 里可以作为 Gradle lint 任务的轻量替代先用命令行快速扫一遍再决定是否进入完整构建流程。比起改build.gradle里的lintOptions这种临时用法更适合排查问题。5. 环境隔离、复杂变量组合与高阶排查技巧5.1 多版本共存让开发者机器里的 SDK 和 CI 不必一致同一台机器维护两个 Android SDK 根目录是常见需求比如一个给内部项目用稳定版另一个给新项目试 Preview API。命令行工具包的--sdk_root参数可以让同一套 cmdline-tools 操作不同的 SDK 目录sdkmanager --sdk_root/opt/android-sdk-stable --install platforms;android-34 sdkmanager --sdk_root/opt/android-sdk-preview --install platforms;android-34 platforms;android-35两套 SDK 并存时ANDROID_HOME只能指向其中一个但如果某个构建脚本内部显式写死了ANDROID_HOME必须确认它是从环境变量读的还是硬编码的。硬编码场景建议用--sdk_root显式覆盖避免构建脚本之间相互污染。5.2 一组可复制的高阶参数组合把前面所有技巧拼在一起构成一个可在 Linux 服务器上直接使用的完整脚本块export ANDROID_HOME$HOME/android-sdk export PATH$ANDROID_HOME/cmdline-tools/latest/bin:$PATH # 安装全部所需组件--channel0 锁稳定版 sdkmanager --channel0 \ --install platform-tools \ platforms;android-34 \ build-tools;34.0.0 \ system-images;android-34;google_apis;x86_64 # 验证 sdkmanager 自带工具版本 sdkmanager --version # 创建 AVD 并冷启动 avdmanager create avd -n ci_test -k system-images;android-34;google_apis;x86_64 -d pixel_5 --force $ANDROID_HOME/emulator/emulator -avd ci_test -no-window -no-audio -no-boot-anim -gpu swiftshader_indirect adb wait-for-device # 等 sys.boot_completed until adb shell getprop sys.boot_completed 2/dev/null | grep -q 1; do sleep 5; done执行时如果卡在某一个环节优先看环境变量env | grep -E ANDROID|JAVA原因是脚本多次 export 后可能覆盖了系统原有的ANDROID_SDK_ROOT。sdkmanager 读取优先级是--sdk_root参数大于ANDROID_SDK_ROOT大于ANDROID_HOME在不传参时两个环境变量若指向不同目录行为会变得很难预期。5.3 日志、退出码与半成品组件残留sdkmanager 的退出码设计并不复杂0 表示成功非 0 表示失败。但失败后不一定回滚可能出现组件半安装状态比如platforms/android-34目录存在但android.jar缺失。验证干净环境的方法sdkmanager --list_installed | grep android-34 test -f $ANDROID_HOME/platforms/android-34/android.jar echo OK如果android.jar缺失直接重装该组件即可sdkmanager --install platforms;android-34。卸载组件时要注意依赖关系比如先卸载了platform-toolsadb 相关脚本会直接失效但 sdkmanager 本身不受影响。提示遇到“java.lang.UnsupportedClassVersionError”时多半是 JDK 版本过低cmdline-tools 需要 JDK 17 及以上。执行java -version确认版本必要时安装新版 OpenJDK 后重新设置JAVA_HOME。5.4 版本锁定在 CI 中固定 commandlinetools 版本团队协作中commandlinetools 本身的版本漂移比 SDK 组件版本漂移更隐蔽。构建机上普遍用-latest文件名下载一旦仓库发布了新构建号下次 CI 拉取就会静默换版本。锁定的做法是保存完整构建号# 构建脚本开头记录 echo cmdline-tools version: $(sdkmanager --version)配合repository.xml的缓存到制品仓库能让构建在离线环境也不受影响。先把cmdline-tools的 tar 包推送到内网再把lib/repository.xml一并缓存之后所有安装操作都走内网源。这种做法在离线或半离线项目里是稳定输出来源的核心手段。本文还有配套的精品资源点击获取