Notify Me 開源簡訊轉發器：把閒置手機的驗證碼推到隨身裝置

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

挑簡訊轉發工具，最值得先問的問題往往不是功能清單有多長，而是你的驗證碼會經過誰的手。這個品類的主流選擇 SmsForwarder 功能齊全、持續更新，到 2026 年 10 月已經累積超過 2.8 萬顆星；Notify Me 走的是完全相反的路線，它小到一個下午就能把整包程式碼從頭讀完，依賴清單短得一目瞭然，安裝檔解開來掃，找不到任何一支分析或廣告 SDK。把它在 GitHub 上的原始碼與官方釋出的安裝檔攤開來檢驗：哪些信任點站得住、哪些代價要先想清楚，看完你就能自己決定要不要把一支閒置的 Android 手機交給它。

一支手機收簡訊，另一支手機收通知：它做的是這件事

Notify Me 是上海開發者 Jin Weijie 在 2024 年 10 月開源的 Android 應用程式，功能用一句話就能講完：手機收到簡訊、或電話響起的瞬間，把來電號碼或簡訊內容即時推送到你指定的另一個地方。典型場景是你有一支放著當備用機的 Android 手機，門號還收得到銀行與購物網站的驗證碼，但你平常帶出門的是另一支手機，裝了它之後，驗證碼一到，人不在備用機旁邊也看得到。

推送的去向有四種，全部自己設定：Bark 推播伺服器、Email 信箱、一般 Webhook 網址，以及自訂的 HTTP 端點。Bark 是 iOS 生態裡很常見的開源推播方案，原理是伺服器收到一個 HTTP 請求就往你的 iPhone 推一則通知，對「Android 收訊、iPhone 隨身」的雙機族來說是現成的組合。雙卡手機也有顧到，程式透過系統的電信服務介面查出訊息落在哪張卡，推送內容會自動加上 SIM 卡槽編號前綴，兩張卡分別收工作與私人訊息的人不會搞混。長簡訊的處理也做了：超過單則長度的簡訊會被拆成多段送達，程式先把同一發送者的段落拼接成完整內文再推送，收到的不會是斷頭訊息。

每一條通道的設定頁都附一個測試按鈕，端點填完按一下，馬上知道這條管線通不通，不用真的等一通電話或一則簡訊進來才試。訊息的標題與內文都提供模板變數，寄件者、內容、類型、時間戳可以自由排列，想推成自己看得順眼的格式，改一次模板全部生效。

Pin

整個 App 的核心就是兩個廣播接收器：一個掛在系統的簡訊廣播上，一個掛在電話狀態廣播上。收到廣播就組內容、送往你開啟的通道，僅此而已，沒有帳號系統、沒有雲端後台、沒有廣告版位。

零追蹤器、零寫死端點：這包程式碼可以整個讀完

把 repo 的依賴清單拉出來看，除了 Android 官方的 androidx 系列，唯一的功能性依賴是 JavaMail，用來發 Email。Firebase、Crashlytics 一類的 SDK 不在依賴裡，任何分析或廣告框架的蹤影也找不到。

依賴清單可以少寫，安裝檔騙不了人。從 GitHub Release 把最新版 1.5.0 的安裝檔（6.28MB）抓下來解包，對兩個 classes.dex 做字串掃描，Firebase、AppMeasurement、Crashlytics、Sentry、友盟、AdMob、AppsFlyer、Flurry、Mixpanel 這類指紋一個都沒掃到，唯一被比對到的關鍵字是 Compose 手勢 API 的 onDoubleClick，與廣告技術毫無關係。這件事你自己也能驗：下載 APK、解壓縮、對 dex 檔跑一次字串搜尋，五分鐘就有答案。

更關鍵的是資料流向的設計。四條轉發通道在程式碼裡全部預設關閉，要哪條自己開；所有端點、帳號、密碼都存在手機本機的設定檔裡，由你自己填。程式裡找不到任何寫死的外部伺服器，Bark 端點的預設值甚至只是一個佔位用的假網址。換句話說，裝上去的當下它什麼都不會送，之後送出去的每一則簡訊，去向都是你自己指定的。

開發者自己的態度也值得一提。README 裡明寫：Bark 有官方的公共伺服器可以免費借用，但考慮到隱私，不建議。一個轉發簡訊的工具，作者主動提醒你別把訊息推到別人的機器上，這個立場和程式碼的設計是對得上的。

端點填誰，隱私就到哪：四條通道的信任取捨

四條通道其實是四種不同的託付方式，裝機之前值得逐條想一遍。

Bark 路線最講究。用官方公共伺服器最省事，iPhone 裝個 Bark App 就能收，但每一則被轉發的簡訊都會經過別人營運的伺服器，作者自己都建議別這樣做。自建才是這條路線的完全體：bark-server 是 MIT 授權的開源專案，一台小主機或任何容器環境跑起來，推播鏈路從頭到尾都摸得到。TechMoon 介紹過的 wxpush 微信推送與挪車通知 movecar，都是同一種「自己架一條通知管線」的思路，可以對照著看。

Pin

Email 路線看似中性，其實把 SMTP 帳號密碼交出去。程式用你填的 SMTP 伺服器直接寄信，這表示你的信箱密碼（例如 Gmail 的應用程式密碼）會存在那支 Android 手機裡，而且是未加密的明文設定檔。真要走這條路，建議另外開一個專門收通知的信箱，把權限傷害範圍縮到最小。

Webhook 與 HTTP 端點路線最自由，端點指向你自己的服務、群組機器人或自動化平台都行，還能自訂請求標頭與內文模板，串進既有流程。預設模板是 JSON 格式，附帶類型、發送者、內文、時間戳四個欄位，若目標服務只吃表單編碼（form-urlencoded），設定裡也有一個開關可以切換投遞格式，老派的接收端照樣相容。要注意的是應用程式允許明文連線（manifest 裡 usesCleartextTraffic 是開的），端點若填 http:// 開頭的網址，簡訊內容就以未加密方式在網路上跑。填 https:// 是沒有理由妥協的底線。

無論選哪條，還有一個小行為要知道：收到簡訊的當下，手機畫面會跳出一則顯示全文的提示訊息，這是程式碼裡寫死的 Toast。備用機放在辦公桌或家裡客廳的話，經過的人都看得到內容，介意的人要自己評估擺放位置。

六週寫完就停手：2024 年 11 月之後沒有新程式碼

這個專案的開發節奏很戲劇化。2024 年 10 月 5 日第一次發版，接下來六週衝刺，10 個版本一路排到 11 月 15 日的 1.5.0，之後就沒有新的發行版了。看 master 分支的提交記錄更明白：最後一次實質的程式碼更動，就停在 2024 年 11 月 15 日那一筆，內容還正是主題模板功能；2025 年僅有的三筆提交全部只是改 README，最後一筆落在 2025 年 8 月 27 日。到 2026 年 10 月的今天，repo 沒有封存、還能下載，但程式本體已經將近兩年沒動過。它不是沒有人碰的死檔案：截至 2026 年 10 月初，最新版安裝檔累積了 841 次下載，獲得 638 顆星；以一個六週完成的個人專案來說，兩年後仍有人持續下載，表示它還在小規模地真實服役，只是你別期待它再長出新功能。

維護停擺的直接後果是 bug 沒有人修。2025 年 8 月有使用者回報 RCS 訊息不會被轉發（issue #10），這則到 2026 年 10 月仍開著；同期另一則關於模板變數的 issue #9 也還掛著。開發者的 GitHub 帳號是 2009 年註冊的老帳號，個人主頁還活著，但至少在這個 repo 裡，他已經很久沒有出聲了。

不過「凍結」對這種小工具的殺傷力，要看功能本質。它做的事情是攔系統廣播、發 HTTP 請求，兩個都是 Android 多年穩定的老機制，不像相機或輸入法類 App 那樣追著系統新版本跑。真正的風險點在下面這節。

RCS 吃不到、明文會亂跑：裝機前要先吞下的但書

RCS 訊息吃不到。 攔截器只掛在傳統簡訊的廣播上，RCS 聊天訊息不會經過那條路，所以對方若用 RCS 傳內容過來，轉發不會觸發。以台灣現況來說，銀行與購物平台的驗證碼仍以傳統簡訊為大宗，日常殺傷有限，但 RCS 的滲透在持續發生，這條邊界會不會哪天踩到你，要自己留心。

來電只攔得到響鈴，撥出通話的權限是死的。 程式在電話狀態變成響鈴時觸發一次，推送來電號碼，沒有別的動作。有趣的是 manifest 裡宣告了處理撥出通話的權限，程式碼裡卻沒有任何接收器使用它，那是 Android 9 之後就被系統架構淘汰的老權限，留在清單裡純屬遺跡。

工程面有一處粗糙，收行銷簡訊時可能踩到。 組 Bark 推播內容時，程式用字串拼接的方式組 JSON，中間沒有做跳脫處理；簡訊內文若含半形引號，送出去的 JSON 會直接壞掉，通知顯示可能跟著出錯。銀行驗證碼多半是一串數字不受影響，但夾帶引號的行銷文字有機會觸發。這類小毛病正是凍結專案的痛處：看得到、改得了原始碼，卻沒有人合併修復。

開機自啟的寫法有靜態可見的隱憂。 開機後系統會啟動它的一個背景服務，但那個服務的程式碼整包是空的，只在啟動時跳一行「NotifyMe Started」的提示，從未真正進入前景服務狀態，manifest 也沒有宣告 Android 14 起要求的服務類型。這種「叫了前景服務、卻沒真的呼叫前景化」的寫法，在較新的 Android 版本上有引發崩潰的紀錄前例；這是翻原始碼就能看到的隱憂，實際會不會發作，視機型與系統版本而定。好在實際轉發工作由兩個廣播接收器承擔，它們由系統喚醒，不倚賴這個服務活著。

授權狀態有一個尷尬的落差。 README 的授權段宣稱採用 WTFPL（「你想幹嘛就幹嘛」公眾授權），但 repo 裡找不到任何 LICENSE 檔案，GitHub 的授權偵測也因此顯示為 None。要拿去改、拿去散佈之前，嚴格按規矩走，先跟作者要一份正式聲明比較穩妥。

不在 Google Play 上。 安裝途徑就是 GitHub Release 的 APK 側載，這也合理，畢竟 Google Play 對第三方 App 取用簡訊權限有極嚴格的限制，這類工具本來就難以通過審查。側載自然要承擔對應的風險判斷：下載來的安裝檔與原始碼之間的對應關係，靠 repo 裡的 GitHub Action 建置流程背書，發版標籤一推、雲端自動打包，這條鏈是透明的。

系統支援範圍倒是寬鬆，最低要求 Android 7.0，目標版本對齊 Android 14，絕大多數還活著的備用機都裝得動。另外有個實際的日常課題：Android 的電池最佳化會把久久沒動的背景 App 休眠，官方說明也提醒要把程式排除在電池最佳化之外，否則轉發會在你沒注意的時候停擺。

跟主流選擇怎麼比，跟站上哪些工具搭

同品類裡，SmsForwarder 這類主流方案走的是大而全路線：通道更多、規則引擎更強、維護活躍，多數人直接選它不會錯。Notify Me 的價值在另一頭：小、可讀、每個端點自己掌握。如果你會想親自確認每行程式在做什麼，或是只想把簡訊轉發這單一事項用最小的程式搞定，它的定位沒有重複。

在 TechMoon 站上，它跟幾篇先前的介紹正好湊成一組場景。備用機丟在家裡，除了收驗證碼還想看著它，escrcpy 電腦投影把畫面搬到桌面；舊簡訊堆積如山，SMS Cleaner先清出空間；擔心備用機被摸走，Stay Put 防盜工具補上定位與警報。一支閒置 Android 的第二人生，這幾件裝備各管一段。

極簡可讀是它的立身之本，三個訊號出現任何一個就選主流

適合的輪廓很清楚：手上有支閒置 Android、門號還活著、想把簡訊與來電集中到隨身裝置，而且願意自己把程式碼讀一遍、或自建一條推播管線的人。對這群人，它的極簡是優點，信任邊界一翻兩瞪眼。

反過來看，要豐富通道與規則引擎、要持續維護的安全感、不想碰側載安裝，這三個需求任何一個成立，主流方案都是更合理的選擇。把驗證碼託付給一個長期停更的專案，前提是你清楚知道自己在託付什麼。