先講結論：connected 不等於 reachable
Android Framework 的網路管理不是不好。它有 `ConnectivityManager`、`NetworkCapabilities`、`NetworkRequest`，也能處理 Wi-Fi、Cellular、Ethernet 和 VPN 的基本狀態。問題在於，Android 原生邏輯主要是為手機、平板和有人操作的設備設計。
對工業設備來說，真正重要的不是狀態列有沒有網路圖示，而是設備能不能連回你的服務、VPN 能不能建立、OTA server 能不能到、MQTT 或 cloud API 能不能正常工作。Android 說 connected，只代表某個 network 被系統接受，不代表你的產品在現場真的可維護。
Android Framework 缺的是產品級網路策略
工業設備常常同時有 Ethernet、LTE、Wi-Fi，甚至還有 VPN tunnel 與客戶內網。Android 可以知道哪些 interface 存在，也能選擇 default network，但它不會自然知道你的產品策略。
例如：Ethernet 插著但 gateway 壞了，要不要切 LTE？LTE 可以連網但 VPN server 不通，要不要重撥 modem？VPN 建立後 route 變了，App 流量要走 tunnel 還是 public internet？Ethernet 回來後要不要立刻切回去，還是先等一段穩定時間？這些都不是一般 framework API 會替產品做好的決策。
所以在無人值守場景裡，網路管理不能只看 Android 的連線事件，而要有一層符合產品部署環境的 policy。
Failover 不是切過去就結束
很多人會把 failover 想得太簡單：主線斷了就切備線。但現場真正麻煩的是切換過程中的副作用。
- Ethernet 斷線後，LTE 有 IP，但 DNS 還留在原本的網路。
- Default route 變了，但 VPN tunnel 沒有跟著重建。
- VPN 還顯示 alive，但實際上遠端入口已經不可達。
- 網路在好壞之間震盪，設備不停切換，反而造成服務中斷。
- Cloud endpoint 不通，但 Android 仍然認為目前 network 可用。
工業設備需要的 failover，是有條件、有冷卻時間、有健康檢查、有回切策略的 failover。否則設備表面上很聰明，實際上只是把網路狀態變得更不穩。
VPN 在工業設備不是附加功能，而是保命通道
在一般 App 裡，VPN 可能只是安全連線。但對無人值守設備來說，VPN 常常是工程師最後能抓住設備的遠端入口。設備失聯時，如果 VPN 回不來，就很可能只能請客戶現場拔插、重開機，甚至派人過去。
因此 VPN 不能只做到「開機後啟動」。它要能在 route 改變後重新建立，要能知道 tunnel 是否真的可達，要能在 LTE / Ethernet 切換後恢復，還要能把狀態回報給上層服務或維運平台。
這也是 CoreEdge Lab 很重視的部分：我們不把 VPN 當成 App feature，而是把它視為現場維修能力的一部分。
缺少診斷能力，會讓每次失聯都從零開始猜
工業設備最怕的不是單次故障，而是每次故障都無法累積經驗。客戶只會說「設備又不通了」，但工程師需要知道的是：當時走哪張網卡？IP 是什麼？default route 指到哪裡？DNS 查詢結果是什麼？VPN tunnel 是否存在？cloud endpoint 哪一段不通？
Android 原生不會自動替你的產品整理這些資訊。沒有診斷包，工程師只能靠截圖、口頭描述、遠端猜測和現場試錯。
我們通常會補一套診斷流程，把 `ip addr`、route、DNS、VPN 狀態、endpoint probe、modem 狀態、Android connectivity event、system log 整理成可回傳的資料。這樣下一次出問題時，不是從「感覺像網路問題」開始，而是直接看證據。
CoreEdge 補的是 Industrial Network Supervisor
我們會把這層能力稱為 Industrial Network Supervisor。它不是取代 Android Framework，而是在 Android 原生網路管理之上，補上工業現場需要的控制面。
這層控制面會做幾件事：
- 定義 Ethernet、LTE、Wi-Fi、VPN 的優先順序與切換條件。
- 用真實 endpoint 檢查服務可達性，而不是只相信 connected 狀態。
- 在網路切換後重建 VPN、修正 route，並確認遠端入口可用。
- 避免網路震盪造成反覆切換，加入冷卻時間與回切策略。
- 收集診斷包，讓 field issue 可以被回放、追蹤和修正。
- 提供簡單狀態給 App：online、degraded、vpn-only、cloud-unreachable、recovering、offline。
重點不是寫一個更花俏的網路 UI，而是讓設備在沒有人看著它的時候，仍然能判斷狀態、做出決策、留下證據，並且盡可能把遠端入口救回來。
這件事通常會碰到 BSP、Framework、App 和 Cloud
網路管理看起來像 Android Framework 的問題，但真正落地時常常跨很多層。modem driver、RIL、Ethernet driver、kernel route、Android network stack、VPN service、system app 權限、cloud heartbeat、OTA 流程都可能牽涉其中。
這也是為什麼它很適合由 CoreEdge Lab 這類平台工程團隊處理。單純 App team 可能碰不到底層權限；原廠 BSP team 可能不會深入你的 cloud 和現場維運；雲端團隊也不一定知道 Android route 和 VPN 怎麼變。
我們的位置就是把這幾層接起來，讓設備不是只有 demo 可以連線，而是在現場斷線、切換、恢復、更新、診斷時，都有一套可維護的工程路徑。
結論：工業 Android 網路管理，需要從「連線」升級成「可維運」
對工業無人值守設備來說，網路不是單一功能，而是所有遠端維運能力的基礎。沒有可靠網路，OTA 做不了，log 拿不到，VPN 回不來，設備狀態也無法被監控。
Android Framework 提供的是基礎網路能力；CoreEdge Lab 補的是現場設備需要的產品化網路管理：多網路策略、failover、VPN 保命通道、可達性檢查、診斷包與自動恢復。這些東西做起來不一定顯眼，但它們決定設備能不能真的放到現場長期運行。