把 appteka 嵌进 APK 測試流水線——我是怎麼省掉每週兩小時的

appteka 是什麼，能幹嘛，適合誰

appteka 是一款免費、開源、社區驅動的安卓應用市場——任何人都能上傳 APK，用戶直接下載安裝，不走 Google Play 的企業審核門，也不依賴谷歌服務框架（GMS）。它的主項目以 GPL v3 許可證託管，客戶端用 Kotlin 編寫，遵循 Material Design 3。

聽起來像是又一個三方應用商店？但其實 appteka 的幾個特性讓它在開發者和測試人員圈子裡特別受歡迎：歷史版本完整保留、免框架直裝、三引擎安全掃描。這三點加在一起，讓它從一個普通應用市場變成了可以嵌入工作流的工具。

適合誰？獨立開發者、小團隊測試人員、需要跨版本做兼容性驗證的 Android 工程師，還有那些手機沒裝 GMS 但又需要下載海外應用的普通用戶。更多功能細節可以參考 appteka文檔。

安裝

appteka 本身就是一個 Android APK，安裝過程和你裝任何第三方應用一樣，但有幾點值得提前注意。

appteka下載 到的安裝包只有 3.77M，非常輕量，Android 6.0 以上的設備都能跑。下載完如果系統彈出「未知來源」的警告，進系統設置找到對應的安全選項放行就行——具體路徑因品牌而異，小米在「設定→應用→特殊權限→安裝未知應用」，華為在「安全→更多安全設定→未知來源」。

安裝完打開客戶端，它不會要求你註冊帳號——直接就能搜、就能下。首次啟動會讓你選語言（簡體中文有），跳過就行。有一點要提：appteka 不依賴 GMS，所以國產 ROM、自帶框架的設備、甚至沒刷 GMS 的國行手機都能正常使用這裡面的應用。

舊流程有多麻煩

說說我之前給測試團隊分發內測 APK 是怎麼乾的。

我們團隊五個測試，三個用小米，兩個用一加。每次出一個測試包，我要做這麼一串事：構建 APK → 上傳到網盤 → 生成分享鏈接 → 去企業微信群裡發消息 → 有人要舊版本的時候去網盤歷史版本裡扒（有時候網盤存儲策略自動清理了舊包還得重構）→ 測試手機沒有 GMS 裝不上某些包的時候還得遠端指導他們裝框架。

每週至少一個下午耗在這上面。最崩潰的一次，有個測試回報「昨天那個版本在 Android 10 上閃退」，我去網盤找昨天上傳的包——版本號是 20.0-beta.3，但網盤裡存了十幾個版本，文件名全是亂的，找了半小時才找到。

還有更頭痛的：有些測試手機沒裝 GMS，Google Play 上的應用他們裝不上，我還得額外去找第三方下載源。整個流程完全是人肉維繫，沒有任何自動化可言。

把 appteka 插進流水線的哪一環

我現在的流程是這樣的：

開發 → 構建 → 上傳 appteka → 測試團隊直接從 appteka 客戶端獲取

具體來說，構建好的 APK 我直接上傳到 appteka（它的上傳頁面支持拖拽上傳，免費，不需要開發者年費，具體上傳規範可參考 appteka官網），上傳時填好應用名稱、分類（選 42 個官方分類裡最貼切的那個，別亂塞蹭流量——社區審核會卡）、中英文描述各一段。appteka 會自動從 APK 裡提取包名、版本號、簽名和圖標，這些都不用我手動填。

上傳後社區審核通常幾個小時內過——比 Google Play 的 2-7 天快太多。審核過了，測試團隊在 appteka 客戶端搜應用名就能看到最新版本，裝完直接測。

歷史版本是這個流程最關鍵的一環。appteka 的應用詳情頁自帶完整的版本歷史，從最新版往回數每一版都有對應的 APK 下載。我不用再額外維繫網盤裡的版本文件——測試員說「我要上一個版本」，他自己打開客戶端、進詳情頁、滑到版本歷史、點上一個版本的 Download，十秒鐘搞定。覆蓋安裝不會丟應用數據（除非簽名變了，那系統會提示先卸載）。

兩個最容易斷鏈的環節

整個流程跑了兩個多月，有兩個地方踩過坑，分享一下。

第一個坑：上傳素材不夠，審核被打回。第一次上傳時我只扔了 APK，沒準備截圖和描述。社區審核直接打回：請提供真實的應用界面截圖（最少一張）、應用描述（說清楚解決什麼問題）、選一個正確的分類。後面我養成了習慣：構建好 APK 後先截 3-5 張 1080×1920 的真實界面圖、寫一段中英雙語的應用描述、從 42 個分類裡選最貼切的那個，再上傳。審核基本一次過。

第二個坑：測試手機的「自動更新」沒關，新版閃退被自動推上去了。有一次我上傳了一個有問題的版本（targetSdk 從 30 升到 33，Android 9 上閃退），幾個測試員手機上 appteka 的自動更新是開著的，被自動推了閃退版本。解決方法：上傳後在測試群裡說一聲，讓大家進應用詳情頁把自動更新關掉；同時我在 appteka 上傳頁面加了版本號註解，比如「20.0-beta.3 — Android 9 用戶請跳過此版本」。appteka 的版本歷史裡每個版本都有獨立的描述欄位，可以寫這種註解。

效果和邊界

說說數字上的變化。之前每週花 1.5-2 小時在 APK 分發和版本管理上，現在大概 15 分鐘——構建完上傳 appteka、發一條群通知就行。歷史版本找回的時間從半小時縮到 10 秒。GMS 依賴的問題徹底消失——appteka 本身不依賴 GMS，它上面的應用也不會強制要求 GMS 才能運行。

但這套流程不是什麼場景都適用。如果你是一個有正式發行需求的團隊，最終還是得走 Google Play 或 App Store——appteka 適合內測分發、灰度驗證、給沒有 GMS 環境的用戶提供下載渠道。另外，appteka 的上傳審核是社區自發的，雖然有三引擎掃描（ClamAV + APKiD + Quark-Engine），但規模和嚴格程度還是比不上 Google Play 那樣的企業級審核。

還有一個邊界：如果你的應用簽名在不同版本之間變了，覆蓋安裝會失敗，必須先卸載再裝——卸載會清掉應用數據。這種情況在 SDK 升級或簽名密鑰更換時會遇到，上傳前最好在版本描述裡提前說明。

總結下：appteka 不是什麼萬能解決方案，但作為一個免費、開源、有歷史版本回退能力的應用市場，它在內測分發這個場景下確實能幫你砍掉大量重複性工作。把它嵌進你現有的開發流水線，成本幾乎為零（上傳免費、客戶端免費），收益直接體現在每週省下的那個下午。

本文为个人基于网络公开资料整理编写，非官方内容，仅供学习交流参考；软件版权归原作者所有，请支持正版；使用过程中遇到问题请查阅官方渠道，本文不承担任何责任。