簡介資源為面向 Linux 開發(fā)者的 Android 命令行工具壓縮包適合不希望安裝完整 Android Studio、希望通過腳本化方式管理 SDK 組件的中高級開發(fā)者。壓縮包內含 108 個文件主要類型包括 95 個 jar 工具庫如 r8、d8、lint、apkanalyzer 等、sdkmanager、avdmanager、screenshot2 等可執(zhí)行腳本以及配置屬性和說明文檔。包體積 157.13MB核心是 cmdline-tools 目錄解壓并配置環(huán)境變量后即可通過 sdkmanager 下載、更新 NDK、模擬器及其他平臺組件。資源已有 284 人學習。通過該工具包開發(fā)者能獲得輕量級的 SDK 管理入口在自動化構建和持續(xù)集成流程中快速管理 Android 開發(fā)組件是 Linux 環(huán)境下提升開發(fā)可控性與效率的實用選擇。1. 一個 zip 裝出整套 Android 構建環(huán)境commandlinetools 到底管什么我剛拿到一臺干凈的 Ubuntu 服務器時第一件事不是裝 Android Studio而是下載這個 Android 命令行工具包commandlinetools-linux-13114758-latest.zip。它不占幾個 G解壓后是一組 shell 腳本和 jar 包卻能干完“拉 SDK、裝 build-tools、建模擬器、分析 APK”這一整套臟活。很多人在 Android Studio 里點半天鼠標才能完成的事在這套工具里就是幾條命令的事。這個包管的是 Android SDK 的入口層sdkmanager 負責下載和管理各個 SDK 組件avdmanager 負責創(chuàng)建虛擬設備apkanalyzer 負責拆 APK。它解決的核心問題是“沒有圖形界面、不裝全家桶照樣能把 Android 工程跑起來”。尤其適合三類人靠 CI 出包的運維和腳本黨、在遠程 Linux 上調試的開發(fā)者以及被 Android Studio 下載慢折磨到想換方案的人。需要先說明白這不是一個“能編譯 APK 的編譯器”本身不帶 platform 和 build-tools它是個工具入口。你拿到這個 zip 只是開始后面要通過它把真正的 SDK 組件一個個裝進來。整條鏈路跑通之后你會發(fā)現自己對 Android 工程的理解比天天點 IDE 的人清楚得多因為每一步都擺在你面前。2. 拆包看貨解壓后的目錄里藏著哪幾個命令與 latest 目錄約定2.1 先解壓開看bin/ 下到底有哪些可執(zhí)行文件拿到 zip 的第一步永遠是先解開看一眼別急著配環(huán)境變量。我一般會解壓到一個臨時目錄然后再決定怎么擺放。用 unzip 直接解壓再用 find 把前幾層文件列出來。mkdir -p ~/android-sdk unzip -q commandlinetools-linux-13114758-latest.zip -d ~/android-sdk find ~/android-sdk -maxdepth 3 -type f | sort這里的-q是安靜模式解壓過程不刷屏-d指定解壓目標目錄。解壓后你會看到頂層是一個cmdline-tools文件夾里面才是真正的內容。find列出文件后重點關注cmdline-tools/bin/下的幾個可執(zhí)行腳本sdkmanager、avdmanager、apkanalyzer、lint、retrace外加一些 .bat 批處理那是給 Windows 用的和 .jar 包。這個 bin 目錄才是整套工具的精華所在。sdkmanager 是 SDK 組件管理器下載和卸載都靠它avdmanager 管虛擬設備apkanalyzer 用來分析 APK 包lint 做靜態(tài)檢查。很多人到處找獨立的 aapt2、adb 下載包其實正確的姿勢是先裝好這套命令行工具再用 sdkmanager 把那些組件拉下來版本和依賴才不容易亂。2.2 latest 目錄不是裝樣子sdkmanager 的位置約定這里有個新手幾乎必踩的坑sdkmanager 對自身所在目錄有嚴格要求不是放在哪都能跑。它要求工具必須位于$ANDROID_HOME/cmdline-tools/latest/bin這樣的層級里也就是cmdline-tools下必須套一個latest子目錄。如果你直接把解壓出來的cmdline-tools原封不動放到 SDK 根目錄運行sdkmanager --version大概率會報錯或者行為詭異。正確的擺放方式是這樣的cd ~/android-sdk mkdir -p cmdline-tools/latest mv cmdline-tools/bin cmdline-tools/lib cmdline-tools/NOTICE.txt cmdline-tools/source.properties cmdline-tools/latest/這里把原來cmdline-tools目錄里的內容全部挪進latest/子目錄最終結構是~/android-sdk/cmdline-tools/latest/bin/sdkmanager。source.properties這個文件里寫的Pkg.Revision就是構建版本號 13114758你可以用它核對當前工具版本。為什么官方要這么設計因為以后你升級工具時新版本解壓后可以替換latest目錄里的內容或者并行放一個帶版本號的目錄再通過latest做軟鏈切換。常見的做法是保留cmdline-tools/11.0.0、cmdline-tools/12.0.0這樣的舊版本出問題時能快速回滾而不是覆蓋到不可恢復。2.3 構建號 13114758、latest 與 API Level 到底是什么關系每次下載這個 zip文件名里都會帶一串數字這串 13114758 是構建號build number它只代表這一版 Android 命令行工具自身的迭代版本跟 Android 系統的 API Level比如 34、35完全是兩套編號。同一個構建號可以下載所有 API Level 的 platform 和 build-tools兩個維度不互相依賴。還有一個容易誤解的點文件名里的latest是下載頁面用來區(qū)分“當前推薦版”的命名方式不代表這個 zip 解壓后會自己更新。你裝好之后要升級工具靠的是sdkmanager --update命令而不是重新下載一遍latest.zip。我見過同事每次都重新下 zip 覆蓋安裝結果越覆蓋越亂。那這個包和 Android Studio 是什么關系Android Studio 安裝時的 SDK 組件就是通過這套命令行工具拉取的只是把過程封裝到了圖形界面里。如果你已經裝了 Android Studio它自帶的 SDK 里通常也有 cmdline-tools 目錄。但對 CI、服務器、無頭環(huán)境來說命令行工具包是更輕量的唯一合理入口。它能做到 Android Studio 能做的大部分 SDK 管理事情卻不帶幾百 MB 的 IDE 開銷。3. 在 Linux 上從零裝好 commandlinetoolsJDK、解壓、路徑與第一個實例3.1 前置條件JDK 版本和系統架構先搞清楚動手之前先跑兩條命令否則后面報了錯再回頭排查就慢了。grumpy 的經驗是這套工具對 Java 版本非常敏感新構建號基本都要求 JDK 17 起步裝個 OpenJDK 17 是最省心的選擇。java -version uname -m第一條看 JDK 版本第二條看 CPU 架構。uname -m輸出x86_64就是 64 位 x86aarch64是 ARM 64這兩個架構官方都有對應可用版本但 32 位系統直接放棄新版工具早就不支持了。如果java -version報找不到命令先裝 OpenJDKDebian/Ubuntu 上一般apt install openjdk-17-jdk-headlessCentOS/RHEL 用dnf install java-17-openjdk-devel。無頭環(huán)境裝 headless 版就夠不需要圖形模塊。有人問能不能用 JDK 11 或 JDK 8低版本的構建號配 JDK 8 是能跑的但 13114758 這種新包配老 JDK 會直接報UnsupportedClassVersionError現象就是 Java 啟動類失敗看起來像工具壞了其實是版本不匹配。所以別折騰直接上 17。還有個容易忽略的點如果你機器上有多個 Java 版本java命令指向的可能不是你以為的那個版本用update-alternatives --config java或者顯式把 JDK 17 的 bin 目錄放最前面。3.2 把 zip 放到哪、解壓到哪、目錄結構怎么擺目錄規(guī)劃很關鍵因為后面所有路徑都會跟它掛鉤。個人開發(fā)機我一般放~/android-sdk團隊共用服務器放/opt/android-sdk。選好根目錄后先建目錄再解壓到臨時位置最后挪成latest結構。這個“先解壓再挪”的順序可以避免直接解壓后目錄層級不對的問題。export ANDROID_HOME~/android-sdk export ANDROID_SDK_ROOT$ANDROID_HOME mkdir -p $ANDROID_HOME unzip -q commandlinetools-linux-13114758-latest.zip -d /tmp/cmdtools-unzip mkdir -p $ANDROID_HOME/cmdline-tools/latest mv /tmp/cmdtools-unzip/cmdline-tools/* $ANDROID_HOME/cmdline-tools/latest/ rm -rf /tmp/cmdtools-unzip這里設置了ANDROID_HOME和ANDROID_SDK_ROOT兩個變量ANDROID_HOME是主路徑ANDROID_SDK_ROOT是為了兼容一些老工具和舊項目腳本兩個都設成同一個路徑最省事。解壓到/tmp再移動是為了讓目標目錄干凈最后刪除臨時目錄。注意mv /tmp/cmdtools-unzip/cmdline-tools/*里的通配符會把所有內容挪進 latest 子目錄最終結構是~/android-sdk/cmdline-tools/latest/bin。有個細節(jié)別把整個cmdline-tools目錄直接移進去那會變成cmdline-tools/latest/cmdline-tools/bin多套一層導致腳本找不到自身位置。3.3 環(huán)境變量與 PATHsdkmanager 如何被找到目錄擺好之后要讓系統能找到這些命令。把下面幾行寫進~/.bashrc或~/.zshrcPATH 里要同時包含 cmdline-tools 的 bin 和 platform-tools后者是裝完 adb 之后才有用的但可以先把路徑寫好。platform-tools 還沒裝的時候這個路徑存在但不生效不影響什么。export ANDROID_HOME$HOME/android-sdk export ANDROID_SDK_ROOT$ANDROID_HOME export PATH$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$PATH寫完之后source ~/.bashrc讓變量立即生效。然后驗證最核心的東西sdkmanager --version如果輸出一個版本號說明工具本身已經能跑環(huán)境變量也認到了。如果提示command not found先echo $ANDROID_HOME看變量是否空再看ls $ANDROID_HOME/cmdline-tools/latest/bin里有沒有 sdkmanager。我見過很多次翻車是路徑里多個斜杠或者拼錯大小寫因為 Linux 路徑區(qū)分大小寫Android 目錄名全是小寫。一個需要留意的點如果之前裝過舊版 Android 工具鏈PATH 里可能已經有一個cmdline-tools/bin路徑指向舊版本。新舊同時存在時which sdkmanager出來的那個才真正生效建議把老的路徑從 PATH 里去掉避免兩個版本互相干擾。3.4 第一個實例接受許可并安裝 platform-tools工具能跑之后第一件事是接受所有 SDK 組件的許可協議然后安裝最小可用集合。第一次跑 sdkmanager 的時候它會往$ANDROID_HOME/licenses目錄寫授權文件這個步驟不做后面安裝任何組件都會卡在確認環(huán)節(jié)。用yes |管道可以直接把所有協議一并接受省去手動輸入 y 的麻煩。yes | sdkmanager --licenses sdkmanager --install platform-tools platforms;android-34 build-tools;34.0.0第一條命令把當前 SDK 已知的所有 license 接受并落盤。第二條安裝三樣東西platform-tools是 adb、fastboot 等調試工具的集合platforms;android-34是 Android 14 的平臺文件里面有 android.jar編譯時要用build-tools;34.0.0是構建工具包括 aapt2、zipalign、apksigner。組件名里的分號是包名的一部分不能省略也不能替換成別的符號。安裝完成后驗證一下 adb 是否可用adb version如果輸出 Android Debug Bridge version 相關信息說明整個鏈路已經通了。第一次跑 sdkmanager 時終端會輸出下載進度網絡不好時進度條可能停很久不要急著 CtrlC可以先看是不是卡在 license 確認上。這一步跑通之后后面裝什么組件都只是換個包名的事。4. 不打開 Android Studio 的日常sdkmanager、avdmanager 與 apkanalyzer 實戰(zhàn)4.1 sdkmanager 的完整用法列出、安裝、精確匹配sdkmanager 是整套工具里使用頻率最高的命令它的核心操作就三類列出、安裝、卸載。剛裝好工具時你可能想知道現在哪個 API Level 的 platform 是可用的或者自己裝了什么。兩條 list 命令的差別要分清--list列出服務器上所有可安裝的組件--list_installed只列本機已裝的。sdkmanager --list sdkmanager --list_installed sdkmanager --install platform-tools platforms;android-34 sdkmanager --uninstall build-tools;34.0.0--list的輸出會很長建議用sdkmanager --list | grep platforms;android過濾只看 platforms。包名必須精確匹配比如platforms;android-34和platforms;android-33是兩個不同包不存在模糊匹配。--uninstall同樣要寫完整包名卸載不會刪依賴需要你手動評估哪些相關的包可以一起卸。還有幾個實用參數值得記一下--channel3可以列出金絲雀版本適合想提前體驗新 API 的開發(fā)者但別用在構建機上--verbose輸出詳細日志排查網絡問題時有幫助--sdk_root$ANDROID_HOME顯式指定根目錄適用于沒設置環(huán)境變量的場景。注意新版 sdkmanager 用--install參數安裝舊版習慣是直接寫包名sdkmanager platforms;android-34新版也兼容這種寫法但推薦用帶參數的格式。如果你發(fā)現裝的 platform 版本和項目要求的對不上先用sdkmanager --list_installed確認現狀再用--install補裝對應版本。Gradle 構建時經常報錯說缺少某個 build-tools 版本就是因為 sdkmanager 裝的版本和build.gradle里buildToolsVersion指定的不一致命令行這邊裝一下就好了。4.2 avdmanager不啟動 IDE 建模擬器avdmanager 負責虛擬設備AVD的創(chuàng)建和銷毀。命令行建模擬器最大的價值在于 CI 場景無頭跑 UI 測試時需要一臺啟動的模擬器而不可能讓 Jenkins 去打開 Android Studio 點創(chuàng)建。用 avdmanager 建 AVD 之前需要先裝 system-image 和 emulator 兩個組件否則之后創(chuàng)建會失敗。sdkmanager --install system-images;android-34;google_apis;x86_64 emulator avdmanager create avd -n ci_test -k system-images;android-34;google_apis;x86_64 -d pixel_5 avdmanager list avd第一行安裝模擬器程序和系統鏡像。system-image 的包名三個分號分段system-images;android-34是 API 版本google_apis表示帶谷歌 APIx86_64是鏡像架構如果你的機器是 ARM 就選arm64-v8a。第二行創(chuàng)建 AVD-n是設備名-k是鏡像包名-d是設備配置文件。第一次創(chuàng)建時終端會問是否創(chuàng)建自定義硬件配置直接輸入no回車用默認配置就行。啟動模擬器的命令在 emulator 目錄下面不建 AVD 也能執(zhí)行但沒有設備可啟動。無頭模式跑測試時一般這樣啟動$ANDROID_HOME/emulator/emulator -avd ci_test -no-window -no-audio -gpu swiftshader_indirect-no-window是不顯示模擬器窗口-no-audio關掉音頻-gpu swiftshader_indirect用軟件渲染這三個參數組合是 CI 上跑模擬器的標準配置。啟動后可以用adb wait-for-device等待設備就緒再跑測試。注意模擬器啟動需要幾秒到幾十秒CI 腳本里要留足等待時間。4.3 apkanalyzer 與 lintAPK 的體檢和靜態(tài)檢查拿到一個 APK 之后想快速了解它是什么包名、targetSdk 多少、用了哪些權限不需要反編譯工具apkanalyzer 就夠了。它在命令行工具包里自帶直接對 APK 文件執(zhí)行。這個命令在排查問題時特別有用比如客戶反饋的包版本不對用一條命令就能確認這個 APK 到底是不是最新的。apkanalyzer manifest print app-debug.apk apkanalyzer apk summary app-debug.apk apkanalyzer dex packages app-debug.apk第一條打印 APK 的 AndroidManifest.xml 內容能看到包名、版本號、權限聲明、四大組件等第二條輸出 APK 的基本信息摘要包含最低 Android 版本、目標 SDK 版本第三條列出 dex 文件里的包結構和類數量可以用來快速判斷一個 APK 是否打過混淆、是否包含某個類。這些命令不需要啟動任何服務執(zhí)行速度和文件大小有關一般一秒內出結果。lint 靜態(tài)檢查在命令行工具里也有對應入口但對單個 APK 文件檢查比較少見更多是對工程源碼跑。常見做法是直接執(zhí)行./gradlew lint生成的報告在app/build/reports/lint-results-debug.html。命令行工具包里的 lint 腳本主要用于脫離 Gradle 的場景比如在 CI 里對一份 pull 下來的代碼單獨檢查。靜態(tài)檢查的坑在于默認規(guī)則集有時候過嚴很多團隊會在lint.xml里把不必要的規(guī)則關掉不然構建分會掛在一些無傷大雅的告警上。4.4 把這套工具接進 CI無 UI 場景的最小配方命令行工具在 CI 里的定位是“基礎鏡像的一部分”而不是每次構建時現下載。GitHub Actions 和 Jenkins 常見做法是把下載、解壓、裝 SDK 組件的過程固化成腳本緩存 SDK 目錄讓每次構建復用。第一次構建先把環(huán)境鋪好后續(xù)構建直接走緩存省掉最耗時的下載環(huán)節(jié)。set -e curl -fsSL -o /tmp/cmdtools.zip https://dl.google.com/android/repository/commandlinetools-linux-13114758_latest.zip unzip -q /tmp/cmdtools.zip -d $ANDROID_HOME yes | sdkmanager --licenses sdkmanager --install platform-tools platforms;android-34 build-tools;34.0.0 sdkmanager --list_installed | tee /opt/android-sdk/packages.txt這里的set -e讓腳本在任一步失敗時立即退出避免在殘缺環(huán)境下繼續(xù)構建。注意下載鏈接里的版本號用下劃線連接和文件名commandlinetools-linux-13114758-latest.zip里的連字符不同拼錯會 404。CI 腳本里我一般會把版本號單獨定義成一個變量比如CMDTOOLS_VERSION13114758方便以后升級時只改一行。最重要的一個經驗不要把 CI 腳本寫成每次都拉最新包。文件名里的latest會害人今天最新的版本過兩個月就變了鎖版本號才能保證構建可復現。團隊內部如果網絡到 Google 倉庫不穩(wěn)定常見做法是把 zip 和常用 SDK 組件打包放到內網對象存儲或者 Nexus 上CI 從內網拉取。這種方案同時解決了下載速度和版本固定兩個問題。5. 命令行工具常見坑與排錯從 java 報錯到 SDK 裝完用不了的 5 個現場5.1 sdkmanager 一執(zhí)行就報 Java 異?，F象執(zhí)行sdkmanager --version時直接拋Error: Could not find or load main class com.android.sdklib.tool.sdkmanager.SdkManagerCli看起來像是工具包不完整。原因絕大多數情況是 JDK 版本不對。新版 commandlinetools 的 jar 包編譯目標版本較高用 JDK 8 跑會因版本過低無法加載類。其次是目錄結構錯誤sdkmanager 腳本通過自身路徑定位 lib 下的 jar 包如果cmdline-tools/latest層級不對腳本就找不到主類。解決先java -version確認版本低于 17 就先升級。再確認目錄結構ls $ANDROID_HOME/cmdline-tools/latest/lib能看到一堆 .jar 文件source.properties在上一級。如果目錄層級多了或少了重新按 3.2 節(jié)的方式整理。有個命令行能直接定位問題which sdkmanager看它是否指向了你以為的路徑以此排除 PATH 里多個版本沖突。5.2 下載組件卡在 Fetching 或提示 Cannot download現象sdkmanager --install執(zhí)行后終端長時間停在Fetching階段進度條不動或報Cannot download后中斷。重試多次仍失敗偶爾成功但下次又不行。原因sdkmanager 默認從 Google 倉庫下載組件網絡鏈路慢或超時會被視為失敗。另一個隱藏原因是 license 未接受時部分版本會一直掛在確認狀態(tài)不報錯看起來像卡死。重試時重復的臨時文件有可能殘留影響下一步操作。解決先把 license 處理掉yes | sdkmanager --licenses。然后用--verbose重跑一次安裝看日志停留在哪個 URL判斷是哪個組件拉取失敗。對依賴公網下載的環(huán)境常見做法是配置國內鏡像源通過修改$ANDROID_HOME/cmdline-tools/latest/lib/sdkmanager.cfg指定倉庫地址sdkman.repohttps://mirrors.example.com/android/repository這里mirrors.example.com是假設的內網鏡像域名實際部署時換成自己團隊維護的鏡像地址。改完后用sdkmanager --list驗證鏡像是否可用能看到組件列表就說明倉庫生效。每次安裝前也可以--verbose看實際請求路徑確認走的是鏡像而不是默認倉庫。刪掉$ANDROID_HOME下帶 .tmp 后綴的殘留臨時文件再重試能解決一部分“裝了半截”的怪問題。5.3 裝完 build-tools 卻找不到 aapt2現象Gradle 構建時報Failed to find Build Tools revision 34.0.0或 Android Studio 提示 SDK Build Tools 缺失。但運行sdkmanager --list_installed明明顯示build-tools;34.0.0已經安裝了。原因第一種可能是 Gradle 請求的 build-tools 版本和你安裝的版本不完全一致比如項目要34.0.0而你裝的是34.0.0-rc1這在只裝了 preview 版本時經常發(fā)生。第二種是ANDROID_HOME環(huán)境變量指向的 SDK 路徑和項目實際使用的 SDK 路徑不同Gradle 沒認到sdkmanager裝的那個 SDK。第三種是構建工具安裝時目錄寫入權限有問題文件沒寫全。解決先確認本機到底裝了哪個版本直接看目錄ls $ANDROID_HOME/build-tools/ ls $ANDROID_HOME/build-tools/34.0.0/aapt2如果目錄里沒有對應版本用sdkmanager --install build-tools;34.0.0補裝。如果版本存在但 Gradle 報缺失檢查項目根目錄local.properties里的sdk.dir是否指向ANDROID_HOME用絕對路徑寫死是最可靠的方案。另外可以用aapt2 version驗證二進制能否執(zhí)行如果提示權限不足chmod x加可執(zhí)行權限。5.4 Android Studio 與命令行工具互不認SDK 路徑不一致現象命令行里 adb、sdkmanager 都能跑但 Android Studio 打開項目報SDK location not found。兩個環(huán)境各認各的路徑互不相通。原因Android Studio 通過local.properties或自身的 SDK Location 設置來確定 SDK 路徑不會自動讀取 shell 的環(huán)境變量。命令行工具通過ANDROID_HOME定位兩邊獨立管理。如果你先在命令行裝了 SDK 在~/android-sdk而 Android Studio 默認找~/Library/Android/sdkmacOS或其他路徑自然找不到。解決以命令行安裝的目錄為準在項目根目錄創(chuàng)建或修改local.propertiessdk.dir/home/yourname/android-sdk把路徑換成自己的絕對路徑。如果是新建工程也可以直接在 Android Studio 的 Project Structure 里把 SDK 路徑指定到同一目錄。一個反面典型是兩邊各自裝了獨立 SDK占了兩份磁盤空間還經常因為版本不同出現怪問題。經驗是開發(fā)機上只維護一份 SDK命令行和 IDE 都用它。5.5 手滑刪錯目錄或權限被 root 占用現象sdkmanager 安裝組件時寫到一半報 Permission denied或者整個 SDK 目錄被人誤刪所有環(huán)境變量都失效。原因最常見的兩種一是有同事為了方便用sudo sdkmanager安裝組件導致 SDK 下所有目錄的 owner 變成 root普通用戶之后想裝任何東西都沒有寫權限越補越亂二是有人rm -rf $ANDROID_HOME時少打了一個字母把整個 SDK 連同 cmdline-tools 一起刪了。解決權限錯亂的情況一個命令就能治好sudo chown -R $USER:$USER $ANDROID_HOME把所有文件歸回當前用戶之后不要再碰 sudo。誤刪目錄沒有后悔藥只能按第 3 章的流程重新下載 zip、解壓、重裝 SDK 組件。但有個能減少損失的習慣把sdkmanager --list_installed的輸出保存下來重裝的時候照著列表一條條裝回去。這個文件我一般放在 SDK 根目錄外面避免隨 SDK 一起被誤刪。刪除操作前先echo $ANDROID_HOME確認路徑是否為空這能攔下大部分手滑。6. 驗證安裝與進階配置一條命令確認 SDK 狀態(tài)與三個高頻技巧6.1 快速健康檢查一條命令連串驗證平時我檢查一臺機器的 Android 環(huán)境是否健康會直接把三個命令連起來跑先看工具版本再看已裝組件清單最后看 adb。三步都通過這個環(huán)境基本就能直接開干。sdkmanager --version sdkmanager --list_installed adb version保證前一條成功才執(zhí)行下一條任一步失敗就能定位問題在哪個環(huán)節(jié)。sdkmanager 版本號報錯多半是 JDK 或目錄問題list 結果缺失組件說明安裝不完整adb 報 command not found 則檢查 PATH 里是否包含 platform-tools。這套檢查同樣適合寫成一個check_android_env.sh腳本新入職同事拉下來跑一遍就能確認環(huán)境就緒。6.2 三個用過就回不去的小配置第一個是別名。命令行操作里sdkmanager --list輸出太長我會在.bashrc里加alias sdklistsdkmanager --list加alias sdksdkmanager --install少打一串是一串。第二個是對 AVD 設備名的約定團隊里建模擬器統一用“項目名_用途_架構”格式比如ci_test_x86_64避免 AVD 一多根本分不清誰是誰。第三個是環(huán)境變量在 CI 里的留檔習慣把每個版本號寫進一個 environment 文件讓整個構建鏈路用的同一個 SDK。我自己踩得最狠的一次是第 5 章的 5.1新工具配了舊 JDK報錯報得莫名其妙查了半天才發(fā)現是版本不匹配。現在拿到任何新版本的 commandlinetools我會先java -version再決定要不要繼續(xù)裝。這套工具的坑不算少但摸清楚規(guī)律之后它確實是 Linux 上搓 Android 構建環(huán)境最直接的路。希望幫到你。本文還有配套的精品資源點擊獲取