上面是你的 app，外面是設備管理，中間那層是我們
終端客戶維護一個 app。板卡廠提供硬體、Device Owner app 與雲服務。中間那層 Android 沒有人負責——讓 app 不必動平台就拿得到 I/O 的 SDK、多個網路同時在時決定資料走哪一路、原廠 BSP 不再動之後的版本升級、以及無人值守設備賴以存活的記憶體與開機時間。那層是我們做的。
產品邏輯、UI、領域知識——那是客戶的 IP，也是這台設備存在的理由。一份 app，不該因為換了一塊板子就得重寫。
板卡廠有自己的 Device Owner app、雲服務與更新機制——那是他們的產品與經常性收入。我們不賣管理平台，也不在這層競爭；我們負責讓底下那層 Android 真的被他們的管得動、鎖得住、更新得了。
Modem、ISP 與 RF 校正、簽章金鑰、認證。這層不是我們的範圍，我們也直說：需要那些東西的工作，沒有它們就出不了貨。
上線前把它做出來，上線後讓它活著
多數團隊卡在第一段，然後在第二段才發現沒有退路——設備已經出貨、現場沒有人，而更新機制當初沒做進去。這兩段必須一起想，第二段沒辦法事後從遠端補上。
上線前：把設備做出來
點板、driver porting、HAL 實作、Android 版本升級、記憶體與開機時間精簡、把推論放上 NPU。這一段原廠與板卡廠都不會替你做。
上線後：讓它在沒有人的地方活著
OTA 發佈、安全補丁、經私有隧道遠端偵錯、艦隊狀態、設備卡住時自己回到可用狀態。這些如果出貨前沒做進去，出貨後就沒辦法遠端補上。
這些我們不接
規則只有一條：需要原廠簽章、授權工具或專屬校正資料的項目，我們不接。不是因為困難，是因為沒有那些東西，做出來的成果你沒辦法出貨。
不接
- MIPI 相機 ISP／3A 調校
- 電池充電曲線、電量計、安規
- Modem／aDSP／SLPI 韌體與校正
- RF 校正
- CTS／GTS 與法規認證
- Widevine L1
- 量產金鑰保管
- 硬體設計與選料決策
需要 Google Play 與 GMS？那需要與 Google 簽約並逐機型通過 CTS／GTS 核准。這類產品我們會建議你直接選用已通過認證的硬體方案，而不是把這件事接下來。
這些看起來像，但我們接
- UVC／USB 相機與熱拔插自癒
- 影像 AI 整條 pipeline
- 晶片內建 NPU 推論（公開 SDK）
- DSP 問題診斷與配置層解法
- 功耗與發熱問題定位
- 音訊 codec、功放與路由點板
界線不是「硬體或軟體」，而是這件事能不能在沒有原廠才給得起的東西的情況下，做完並且驗證得了。
三種合作方式
每種合作都有明確的範圍、交付物與驗收標準，開始前你就知道自己買的是什麼。深度聚焦 Qualcomm Android 平台。
付費評估
適合在投入預算前，想先把風險與卡點講清楚的團隊。
- 平台相容性以量測為準，不是憑經驗判斷 — 附可交付報告
- 能力清單：這塊板什麼會動、什麼不會、什麼還沒驗
- 問題定位到正確的層級（硬體 / BSP / framework / App）
- 可行的下一步與範圍建議 — 直接作為後續報價依據
Rescue Sprint（救援衝刺）
適合點板卡住、現場不穩，或整合停滯、需要在限定時間內止血的專案。
- 鎖定範圍的修復，限定時程
- 可重複驗證的穩定系統基線
- 驗收標準與交接文件
平台維護 Retainer
適合設備已出貨，需要長期有人對平台可用性負責的客戶。
- OTA release review 與回滾準備
- 診斷與遠端恢復
- 現場問題追蹤與原廠協調
不確定適合哪一種？從付費評估開始，費用可折抵後續合作。
底下每個數字都是在真機上量出來的
客戶專案，已去識別。同一台設備、同樣條件，改之前與改之後——沒有區間、沒有「最高可達」、沒有「依專案而異」。沒有量到數字的，這裡就不會有那個案例。
不再反覆斷線的 LTE
設備平均每 24 秒換一次 IP，有 16% 的時間完全沒有網路。先前的紀錄把原因歸咎於「模組省電機制」。不是。真正的原因是允許使用的網路世代開得太寬，訊號在邊緣時數據機不斷去嘗試 3G、2G，每試一次就把連線砍掉重來。
不再被系統殺掉的相機程式
3GB 無人值守設備閒置時本來就健康，風險只在相機負載下才出現：緩衝區配置暴衝，kernel 開始按分數殺人——殺掉的是客戶的相機程式，肇事的那支反而活著。單一 app 的記憶體上限攔不到它，因為那些緩衝區根本不在那套 kernel 帳上。最後的作法是加一層 watchdog，直接停掉肇事者，不等 kernel 挑人。
原廠不再更新之後，系統層還改得動
板子停在 Android 13，原廠 BSP 不再維護，手上又沒有原始碼——遇到問題就只能等一個不會來的版本。我們只替換 system image，vendor 分區一個 byte 都沒動：升上新版是順帶的結果，真正拿回來的是「系統層還動得了」。
開機時間砍掉一半以上
無人值守設備斷電後要 34 秒才回得來，那就是每次都少掉 34 秒的服務。查出來大部分時間花在 kernel 把每一行 log 寫到一個沒有人在看的序列埠。
物件偵測從 140 毫秒到 3 毫秒
偵測模型跑在 CPU 上，因為搬到 NPU 反而更慢。離線逐運算子分析找出其中一層 pooling 在那顆加速器上慢了 250 倍，換成等價的卷積之後整張圖就通了。
讓系統塞得進你現有的板子
客戶板子可用空間 2082 MB，標準映像塞不下。與其把現場每一台都重劃分區，我們拿掉無人值守工業設備用不到的東西——消費性 app、用不到的執行環境版本、虛擬化支援。
把現場真的會遇到的問題，寫成技術筆記
這些文章整理工業 Android 設備背後的工程落差：BSP 客製、網路恢復、OTA、診斷，以及出貨後的平台維護。
做這件事的人
CoreEdge Lab 由 James Lee 主導，累積 17 年以上嵌入式系統、IC 設計支援、Android BSP / SoC 平台與量產交付經驗。客戶通常是在平台落後、現場不穩，或內部沒有人能扛 Android 系統層時找上我們。我們處理的是問題真正發生的地方：點板、整合、恢復、診斷和量產強化。
預約初步評估
告訴我們目前卡在哪裡：點板、網路、VPN、OTA、診斷或量產。我們會先回覆可行的下一步，不會只丟制式業務話術。