Telephony Framework
前言與定位
在智慧型手機中，除了 UI、網路、感測器等子系統，通訊能力 (語音、簡訊、數據) 是最基礎、最核心的功能之一。Android 在這部分設計了一套完整的 Telephony Framework，涵蓋從 SIM 卡讀取、基站管理 (無線電連線)、電話通話、SMS / MMS、網路數據連接、到 IMS / VoLTE 等功能。
Telephony 架構總覽
要理解 Telephony Framework，首先要了解它在整個 Android 系統中的位置與層次。下面是一個簡化版的架構圖與說明：
應用程式層 (Apps / Dialer / SMS 等)
│
▼
Telephony API 層 (android.telephony / internal.telephony)
│
▼
Telephony Service 層 (系統服務，如 Phone, TelephonyRegistry 等)
│
▼
RIL (Radio Interface Layer) / RIL Daemon (rild) / Vendor RIL
│
▼
Modem / 無線電硬體
│
▼
基站 / 通訊網路 (LTE, GSM, NR...)
- 應用程式層：例如撥號程式、簡訊程式、設定中的網路選擇頁面等，使用 TelephonyManager 等 Java API 與通訊功能互動。
- Telephony API 層：提供高階 Java 類，例如 TelephonyManager、SubscriptionManager、SmsManager 等。
- Telephony Service 層：系統服務中的 telephony 模組（在 Framework / SystemServer 中啟動），負責協調 API 與下層 RIL 的通信。
- RIL 層：由 RIL Daemon (rild) 作為中介，接收來自 Telephony Service 的請求並轉發給 Vendor RIL Library，再由 Vendor RIL 與 modem / 基地台通信。
- Modem / 網路硬體：實際執行無線電通信、基站握手 (attach)、呼叫控制、數據封包傳輸等功能。
在這樣的架構中，訊息與命令可能是「Solicited」或「Unsolicited」的：
- Solicited commands：Framework 向 modem 發出請求 (如撥號、查詢網路狀態)
- Unsolicited commands：modem 主動發出訊息 (如來電通知、網路狀態變化)
SIM 與訂閱 (Subscription) 管理
在 Telephony 中，SIM 卡扮演非常重要的角色：識別使用者、提供認證、提供網路授權、提供 IMSI、電話號碼 (MSISDN) 等。以下是與 SIM / 訂閱相關的模組與流程：
- SIM 卡初始化與讀卡
- 當手機開機或插卡時，Telephony Service 會透過 RIL 向 modem 要求讀取 SIM 卡內容 (IMSI、ICCID、運營商設定、APN 設定等)。
- 框架中有 UiccController / UiccCard / UiccProfile 等內部類別，用來管理多卡時 (DSDS、Dual SIM) 的多張 SIM。
- 訂閱與運營商設定
- 訂閱 (Subscription) 管理包含多 SIM 卡之間的選擇、默認資料 / 默認語音 / 默認 SMS 卡片。
- Android 提供 SubscriptionManager API，讓應用或系統設定可以查詢與設定當前活躍訂閱。
- 還有 CarrierConfigManager，用於根據運營商提供的設定 (Carrier Config) 控制 VoLTE、Wi-Fi Calling、漫遊策略等。
- SIM Toolkit / ESIM / OTA 設定
- SIM 卡中可能包含 SIM Toolkit (STK) 應用，Telephony Framework 需支援 STK 的命令處理 (例如菜單、USSD)
- eSIM / 雙卡設備還牽涉到遠端配置 (OTA 設定、檔案下載、卡片切換)
Cellular / Radio 與網路連線流程
與基站 /網路的交互是 Telephony Framework 的另一塊核心。下面是它的主要過程與概念：
- 基站網路架構簡介
- 手機與基站子系統 (BSS / RAN) 通信，BSS 包含 BTS + BSC（GSM 架構）或 eNodeB (LTE) / gNodeB (5G)。
- BSS 再繼續連到核心網路 (如 EPC / 5G Core)，管理用戶註冊、切換 (handover)、鑑權等功能。
- 手機需執行 Attach / Registration 流程，才能被網路認可並分配 RRC / NAS 等狀態。
- Telephony 與網路連線
- 當手機開啟數據 (Data) 時，Telephony Service 通常會透過 Data Connection Tracker (DCT) 模組管理數據連線 (APN negotiation、PDP/PDN 建立)
- 在 LTE / NR 時代，是建立 EPS Bearer / 5G 的 PDU session 而非 PDP
- Telephony 必須監控網路狀態 (信號強度、切換、失連、漫遊) 並通知應用層。
- 切換 / Handover 與容錯
- 當設備移動時，需要跨基站切換 (RRC HO)；若切換失敗則可能回退到 4G / 3G 或斷網。
- Telephony Service 也需處理運營商網路的變化、漫遊 (Roaming) 狀態變更等。
通話流程與 Telephony API
電話 (語音) 通話在 Telephony 中的流程相對複雜，牽涉到 Telephony / Telecom / InCall / IMS 等模組。以下是核心流程與 API：
- 電話 API 與 Framework
- 應用層或系統撥號器 (Dialer) 使用 TelephonyManager 或 Telecom API 呼叫撥號。
- TelephonyManager 提供電話狀態、SIM 狀態、網路類型、IMEI / IMSI 等介面
- Telecom 框架（Android API 的通話管理層）負責路由呼叫、音訊路由、連接 UI 的通話控制介面等功能
Android Developers
- 通話發起流程（簡化）
- TelephonyService 會管理通話 (CallTracker)、來電 / 去電 / 切換 / Hold / Conference 等邏輯。
- 通話過程中，可能涉及 IMS (VoLTE / VoWiFi) 協議，若設備支援，它會介入 Telekom 層與 Telephony 協作。
- SMS / MMS 處理流程
- 應用呼叫 SmsManager.sendTextMessage() 或 SmsManager.sendMultipartTextMessage()
- Framework 透過 Telephony Service 將 SMS 請求送到 RIL (RIL_REQUEST_SEND_SMS)
- Modem 發送 SMS；若有回報、接收，則會由 RIL 向上輸出 unsolicited 訊息 (如 +CMT)
- Telephony Service 接收 unsolicited 命令，然後通知 BroadcastReceiver 或交給 SMS 應用處理。
系統服務與交互協作
Telephony Framework 不單是隔離的一個服務，它與整個系統有密切互動：
- SystemServer 啟動：Telephony Service 在 SystemServer 啟動階段被初始化
- Permission / AppOps：Telephony API 使用需申請 READ_PHONE_STATE、CALL_PHONE、SEND_SMS、ACCESS_FINE_LOCATION（部分網路定位）等權限
- CarrierConfig 與運營商設定：Telephony 框架會讀取 CarrierConfig 來決定運營商支持的功能 (VoLTE、Wi-Fi Calling、視頻通話等)
- 電源管理：在待機、休眠狀態下，Telephony Service 仍需維持與基站的心跳 (RRC connect / idle)，防止被網路丟棄
- 網路 / 行動數據管理：當數據連線中斷或恢復時，Telephony 必須通知系統與應用
挑戰與設計考量
在 Telephony Framework 的設計與實作中，有不少技術挑戰與考量：
- 實時性要求高
- 語音通話、來電通知、網路切換都必須反應快速，不能有明顯延遲。
- 穩定性與錯誤處理
- 基站斷訊、弱訊號、切換失敗、SIM 拔插等情況頻繁發生，框架必須具備健壯的恢復機制。
- 兼容性與設備差異
- 不同廠商提供的 Vendor RIL 不同，要兼容不同硬體的特性。
- 運營商政策、IMSI、Carrier Config 等差異。
- 節能與功耗控制
- 手機在待機狀態必須盡可能省電，同時要維持與基站的連線 (RRC 空閒 / 跳頻)。
- 通話時，要根據網路類型（2G, 3G, LTE, NR）動態調整電源模式。
- 安全性與隱私
- 電話、短信、SIM 資訊都屬於隱私資料，必須在 Framework 層進行嚴格權限檢查。
- 防止惡意應用濫用通話或發送 SMS。
iThome鐵人賽
看影片追技術