安卓保活工具 AndroidKeepAlive 實測，倉庫裡找不到一行保活程式碼

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

把 AndroidKeepAlive 的倉庫攤開檢查，結果並不尋常：它掛著 1,354 顆星、自稱「最強 Android 保活方案」，但六個原始碼檔案加起來只有 30 行，內容全部是同一組電子郵件信箱和 Telegram 帳號。這不是一份能直接拿來用或審查的開源保活庫，它是一門生意的店面。倉庫裡實際存在的東西、它自己的說法、開發者真正能走的路，下面三件事分開看。

按下 Clone 只會得到一組聯絡方式

AndroidKeepAlive 在 GitHub 上的名字是 fgkeepalive/AndroidKeepAlive，倉庫語言標示為 C。檔案列表展開後，主要內容是：六個分別叫 KeepAlive.c、KeepAlive.cpp、KeepAlive.h、KeepAlive.java、KeepAlive.js、KeepAlive.py 的檔案，三支實機示範 GIF、一張禁止卸載的示範截圖、一段螢幕錄影，外加一份 MIT 授權條款和一個空白的 LICENSE.md。

那六個「原始碼檔」是整件事的核心。每個檔案都只有五行，扣掉一行空白其實是四行文字，而且六個檔案的內容一模一樣，寫的都是「應用保活，拒絕應用強殺」，有需要請附上來意、透過指定管道聯絡取得，後面附上信箱 [email protected] 和一個 Telegram 帳號。C 版、Java 版、Python 版，無論打開哪一個，看到的都是同一張名片。倉庫的 README 也寫得明白：「暫時關閉了 demo 下載，有需要請按照下方方式聯絡，非法需求勿擾」。

Pin

MIT 授權條款在這裡的意義也跟著變了。授權條款規範的是「你可以怎麼使用這些檔案」，但它在這個倉庫裡覆蓋的標的只有名片檔和示範媒體，沒有任何一行程式適用。GitHub 自動偵測到的授權標籤是真的，只是它覆蓋的東西是空的。

倉庫裡唯一有實質內容的是示範媒體：三支 GIF 分別在三星 S21（Android 13）、小米 11（Android 12）與 Google Pixel 6 Pro（Android 12）上示範「按下強制停止後 App 仍在」，另一張截圖示範系統畫面裡的解除安裝按鈕停用成灰色。這些媒體確實存在、確實是官方放上來的，但它們全部出自作者之手，第三方至今重現不了同樣的檢驗。

Pin

提交歷史說明了 demo 去了哪裡

這個帳號在 2023 年 2 月建立，倉庫也在同一天建立，但現在能看到的第一筆提交落在 2024 年 11 月 7 日，而且是一次把所有檔案（包括當時的 Demo.apk 和六個名片檔）整批上傳。中間一年多的歷史不存在，要嘛從沒寫過，要嘛事後清空重來。

接下來的紀錄更值得注意。2025 年 11 月 24 日，作者刪除了 Demo.apk 和一張名為 code.png 的截圖，同一批操作裡把 README 大幅改寫；2026 年 5 月 24 日補上一張新的禁止卸載截圖，之後到 2026 年 9 月 11 日為止的提交，全部是 README 文字更新，沒有任何程式變更。把時間軸還原：這個倉庫曾經提供可以直接下載的示範 APK，後來由作者主動收回，改成「聯絡作者取得」。倉庫的更新看起來很勤，但三年半的倉庫生命週期裡，動到的都是 README，程式本來就不在裡面。

把十六筆提交全部列出來看更清楚：一筆是 2024 年 11 月的整批上傳、兩筆是 2025 年 11 月的刪除、一筆是 2026 年 5 月補傳新截圖，其餘十二筆的提交訊息清一色寫著 Update README.md。對一個掛著 1,354 顆星的「開源專案」來說，這份清單本身就是答案：查得到的提交記錄裡，程式碼的變更數是零。公開的 issue 清單也查不到任何一條技術討論，熱鬧與空洞在這裡又一次對上。

這也解釋了網路上流傳的載點是怎麼來的。工具分享站上標註的網盤載點，是第三方把某個版本的檔案轉存到網盤空間，這個載點與作者本人的關係無法確認，轉存內容也沒有經過任何檢驗，它可能是最後一版 demo，也可能是任何東西。安裝一個來路不明的 APK，等於把手機的權限交給未知對象，這個風險跟保活技術好不好無關。這種只剩 APK、原始碼消失的處境，先前介紹安卓截圖搜尋工具 SnapSeek時也遇過，當時至少還能拿 MD5 親自核對，這裡連對象都對不上。

同一頁的但書，拆穿「永生」的說法

README 的行銷文字非常強：「就算使用者按下強制停止也無法殺死應用」「保活持續時間理論上不卸載可達永久」「即使手機關機也無法阻止」。但同一頁往下讀，作者自己寫了兩條但書：不明原因死亡後「可以在 15 分鐘內拉活」，以及「開機後的幾秒內，立即啟動」。

這兩句話其實已經承認了事實：App 會死。手機關機時電源切斷，記憶體裡的任何處理程序都會消失，沒有任何軟體能在斷電的記憶體裡存活。這套方案真正做的，是死亡之後的復活，開機自啟、安裝完成當下靜默啟動，以及「在使用其他應用的過程中被其他應用拉活」。換句話說，它賣的是很快爬起來的能力，文案寫成的卻是「永生」和「關機也無法阻止」。這幾句已經離開技術描述的範圍，剩下修辭。

強制停止的部分也一樣。Android 的強制停止會把 App 進入停止狀態、不再被喚醒，這是系統給使用者的最後手段；這個方案宣稱繞過它，用的是「基於 Linux 特性實現的一套黑科技保活技術」的說法。這條宣稱目前無法獨立驗證，demo 已經收回，剩下的只有作者自己錄的 GIF。可以確定的是：真正把對抗強制停止的實作公開出來的專案是存在的（後面會講），而它們需要面對每一版 Android 收緊的限制，沒有人宣稱自己「永生」。

保活會變成一門生意，背景是 Google 這十年的方向一直很一致：從 6.0 的 Doze 休眠機制、8.0 限制背景服務、到近幾版對前台服務啟動時機和通知的要求，系統每一版都把 App 在背景自由活動的空間壓得更小，中國品牌的手機又在自己這層加上更積極的自啟與用電管理。對老實做事的 App 開發者，這些限制有官方答案可循；對想把垃圾訊息、賭博、詐騙 App 塞進使用者手機的人，系統每收緊一次，「能躲掉收緊的技術」就漲價一次。AndroidKeepAlive 的 README 從 2022 年寫到 2026 年，每一條更新都在對齊系統的新限制，這份日誌本身就是這場貓捉老鼠的計分板。

這份更新日誌讀起來像木馬手法清單

如果只看功能列表，這個倉庫像一個很拼的技術專案。但把 README 的更新日誌逐條讀完，會發現它自我描述的內容，跟資安報告裡手機木馬賴著不走的手法清單高度重疊。

2023 年 8 月的條目寫：「核心代碼全部進入獨立加密的自訂 java 虛擬機中執行，可以完全規避代碼審核，完美過 google play 代碼掃描」，並且「保證每次的打包代碼結構都是獨一無二的」。2024 年 3 月的條目寫「去特徵化加強」。2024 年 1 月的條目更直白：「誤判報毒修復，更換 demo 包名」，防毒軟體會報警的問題，解法是換名字。功能列表裡還有：隱藏工作列、隱藏應用名稱、隱藏圖示（「圖示消失術」）、禁止卸載、無權限監聽其他 App 的啟動與關閉、安裝完成的瞬間直接啟動。

還有一項能力低調卻更值得警惕：後台彈出頁面。倉庫說明文字裡叫「後台彈出頁面、體外彈出」，2023 年 5 月的日誌說明做法是「利用 binder 驅動實現直接打開頁面」，也就是繞過正常的前景切換，讓畫面在你沒有要求的時候自己跳出來。這是廣告詐騙產業最愛的能力：配上前面那些保活與隱身手法，一個能在任何時機跳出廣告頁、又躲在各種偽裝後面的 App，就是典型的廣告木馬形態。作者把它列在功能表裡，與「開機自啟」「禁止卸載」並列，讀起來毫無違和，這件事本身就說明了這份清單的性質。

把這些條目並排：規避平台審查、對抗防毒偵測、每次打包換長相、藏圖示、擋卸載、監聽其他 App、裝了就自己啟動。任何一項單獨看都可能有正當用途，但整包放在一起，就是持久化木馬的標準規格。Google Play 的開發者政策要求如實申報 App 行為、禁止規避審查，這個日誌等於把「如何不被抓到」當成產品賣點在寫。README 的「使用要求」欄只寫了一條「不可用於違法用途」，但從技術手法看，它離合規的距離比這句免責聲明願意承認的遠得多。

「為什麼要藏」的答案也在這段日誌裡。會購買這套能力的客戶，需求多半是讓一個不想被使用者找到、也不容易被使用者移除的 App 活在手機裡；正常的計步、導航、即時通訊不需要躲審查，也不怕使用者按強制停止。這些手法本身，就標記了目標客群。README 裡那句「能 google 上架，並且持續在架的，我相信只有這裡」，在開發者眼裡是技術實力展示，在平台政策眼裡是自述違規，在使用者眼裡應該讀成警告。

賣保活的人，同時在賣什麼

單看一個倉庫還可以說是技術展示，但這個作者帳號下的其他倉庫把全貌補齊了。同帳號經營的 AndroidProtect，說明文字寫著「一鍵過馬甲包，一鍵抹除 aab 中的機器碼識別，抹除開發者資訊」；另一個倉庫直接叫 google-play-store-developer-account，內容是「高品質 google 開發者企業帳號，每個帳號都是單獨一套資訊，出現關聯封號包賠」，這是在賣可以躲避關聯封號的開發者帳號。帳號裡還有一個拼多多後門分析專案的副本，以及多個加固、脫殼、混淆工具的 fork。

作者的個人頁自述把這些串成一條龍：「專業 Android 保活合作」「提供逆向服務 so 反編譯 脫殼」「過安裝報毒，代碼混淆，apk、aab、aar 加固，可上 google play，避免關聯」「高穩定性 google 開發者帳號，封號包退換，帶 vps，歡迎聯繫購買」。翻譯成白話：保活、過審、加固、混淆、帳號，全部是商品。AndroidKeepAlive 的倉庫在整條服務鏈裡扮演的角色，就是前台櫥窗，GitHub 的星星數在這裡是行銷資產，維護 README 就是在顧店。

就連聯絡說明都帶著線索。README 裡的 Telegram 連結旁邊，官方自己加了一句標註，說明這條管道需要翻牆才連得上，等於直接交代了主要客群就住在牆內。倉庫累積的 191 次 fork 也值得停下來想：每個按下 Fork 的人，複製到手的從來沒有一行程式碼；2025 年 11 月之前 fork 的人手裡還多一個示範 APK，之後就只剩那六張名片檔和示範媒體；1,354 顆星、191 次 fork 的熱鬧數字，對照任何人都能親自驗證的空手結果，這段落差就是整個倉庫的本體。倉庫裡甚至留著一個 .DS_Store，那是 macOS 檔案管理的自動產物，跟著作者的本機資料夾一起推上來，整包東西最像「開發痕跡」的部分，反而是這類無意間留下的使用痕跡。

開源保活有真貨：Cactus 與 KeepAlive

說「保活都是騙局」並不準確，因為真正把程式碼端出來的專案是存在的，而且可以下載檢查。

gyf-dev/Cactus 有 1,647 顆星，用 Kotlin 寫成，是完整的 Android Library 專案：build.gradle、sample 專案、原始碼、授權條款一應俱全，整合方式是在自己的專案裡加依賴。它收錄的是正派打法：雙處理程序前台服務、JobScheduler、WorkManager、一像素 Activity（在螢幕上開一個幾乎看不見的小畫面，讓自己被系統當成正在使用）。對照之下，AndroidKeepAlive 的 README 特別強調「區別於常規一像素，背景音樂等方案」，它要區別的對象，就是 Cactus 這類透明方案。常規方案的共同限制是老實：系統每一版都在收緊背景限制，它們的作法跟著規則走，效果有邊界，但你可以看到每一行是在做什麼。判斷方法很樸素：點進檔案列表，看得到 Kotlin 原始碼、build 設定與 sample 專案，clone 下來能直接整合進自己的 App，這些都是 AndroidKeepAlive 給不出來的東西。

更激進的技術也有公開版本。lcodecorex/KeepAlive 用 C 語言透過 binder ioctl 處理強制停止問題，593 顆星，原始碼完整公開，任何人都讀得到它怎麼跟系統互動。它跟 AndroidKeepAlive 同樣瞄準「強制停止殺不死」，差別只有一個：一個把實作攤在陽光下讓你檢驗，一個把實作收回去叫你私訊。對開發者來說，這個差別就是全部。同樣需要高權限的開源 root 備份工具走的是同一條路：原始碼公開、作法可驗，需要信任的時候至少有東西可以看。

至於一般使用者的正當需求（某個 App 在背景收不到通知、系統把運動紀錄砍掉），Google 官方一直有路可走：需要持續運作的用前台服務（通知列會掛常駐通知的那種）、需要延後執行的用 WorkManager、省電機制誤殺個別 App 的，到電池設定裡把它加進最佳化白名單。這些路徑不神秘，也不會讓你的 App「永生」，它們是在系統規則內爭取合理的生存空間，這本來就是保活這件事誠實的樣子。

哪些宣稱無法驗證

以上判斷全部來自倉庫裡可以核對的證據：檔案內容、提交歷史、作者帳號、官方示範媒體。證據能說什麼、說不了什麼，界線先畫清楚，讀的人才好自己判斷，同樣重要的是那些沒有驗證的部分。

我沒有安裝任何 APK。作者收回 demo 後，能接觸實體的管道只剩私訊作者或第三方網盤轉存，一個是閉門交易、一個內容無法信任，所以「強制停止殺不死」「耗電低」「不佔用 CPU」「支援 Android 16」這些效果宣稱，全部維持在作者說法的層級，這裡不做背書。三支示範 GIF 與禁止卸載截圖是官方媒體，但它們證明的是「作者展示了這些畫面」，證明不了效果在每一台裝置上都成立。「能上 Google Play 並持續在架」同樣只有作者自述，無法查證是哪一款 App，就算真有這款 App，也沒有管道從外部把它連回這個倉庫對號入座。至於 1,354 顆星，在這類倉庫上只反映熱度，證明不了品質，星星給的是「README 寫得夠兇」這件事。

另一個方向的不確定性也要說：這門服務很可能真的存在。示範媒體有實際裝置畫面、聯絡管道持續運作、README 持續更新說法，這些都不是純詐騙專案的典型特徵。無法驗證跟不存在是兩回事，這裡能負責的結論，停在「不可驗證且手法危險」。

什麼需求走什麼路

如果你的身分是 App 開發者，要背景可靠性，先走官方文件裡的前台服務與 WorkManager，需要更強的背景存活能力，拿 Cactus 這類原始碼公開的庫來讀、來整合，出了問題至少查得到原因。如果你的身分是一般使用者，只是想讓導航、運動紀錄或即時通訊在背景活著，先到手機的電池設定把該 App 排除在最佳化之外，再到各廠牌的自啟管理裡放行，這兩步解決大多數「背景被殺」的抱怨，防盜類 App那種必須常駐背景的需求，走的也是同樣的設定路。操作位置各廠牌叫法不同，常見入口是設定裡的應用程式資訊頁，把電池選項從「最佳化」改成「不受限制」或「無限制」，再確認該 App 的通知權限是打開的；中國品牌的手機通常還要多檢查一層電池與效能管理裡的自行啟動開關。如果你在哪個論壇看到有人推薦「免 root 殺不死的保活神器」，附的又是網盤載點，這篇的建議很簡單：不要裝。判斷標準也簡單，調整完設定後，App 在背景收得到通知、鎖屏後紀錄沒斷，就是正路走得通；如果還是活不下去，該回頭檢查的是廠牌的電源管理，會躲審查的 APK 解決不了這個問題。

回到 AndroidKeepAlive 本身。它值得認識的地方，在於它把「灰產保活」這門生意的完整樣貌攤在檯面上：宣稱寫到最滿、程式碼一行不給、靠私訊成交、旁邊還掛著加固與帳號的價目。看懂這個結構，比記住任何一個保活手法都有用，因為手法會換名字，結構不會。這個倉庫最誠實的部分，反而是那六個一模一樣的名片檔：至少它們沒有假裝成程式。