System Services 與 ServiceManager 架構

introduction

在 Android 系統中，App 並不會直接與底層硬體或內核進行互動，而是透過 System Services（系統服務）作為橋樑。
這些服務涵蓋了 Android 幾乎所有核心功能，例如：

• ActivityManagerService (AMS)：負責 Activity / 任務管理
• WindowManagerService (WMS)：負責視窗與螢幕排版
• PackageManagerService (PMS)：負責安裝、查詢、授權
• PowerManagerService：負責電源與螢幕控制
• LocationManagerService：負責定位

而這些 System Services 的統一管理者就是 ServiceManager。
ServiceManager 在 Android 的 Binder IPC 架構中扮演「註冊中心」的角色，確保應用程式能夠透過服務名稱找到對應的系統服務。

Why we need System Services

1. Android 的安全模型
   Android 採用 應用程式沙箱（Sandbox），每個應用程式運行在自己的 UID 下，不能隨意存取其他應用或系統資源。
   如果讓應用程式直接訪問硬體或內核，將會破壞沙箱安全性。
2. 功能集中管理
   舉例：若每個 App 都要自己實作 GPS 驅動，會導致效率低下且耗電。
   因此，Android 提供統一的服務，例如 LocationManagerService，集中負責 GPS / Wi-Fi / Cell Tower 定位，App 只需呼叫 API。
3. 介面抽象
   System Services 對外提供 統一的高層 API（Java Framework API），而內部則透過 Binder IPC 與 Native / Kernel 互動。
   這樣應用程式不需要知道底層細節，只需透過 Context 取得服務。

System Services 的分類

System Services 可以大致分為以下幾類：

1. Activity / Application 管理類

• ActivityManagerService (AMS)：負責 Activity 與 Task 管理。
• PackageManagerService (PMS)：負責應用安裝、查詢、授權。

2. 視覺 / 輸入管理類

• WindowManagerService (WMS)：視窗管理。
• InputManagerService：觸控、鍵盤、滑鼠事件。

3. 硬體相關服務

• SensorService：感測器管理。
• CameraService：相機驅動接口。
• PowerManagerService：電源、螢幕控制。

4. 系統資源服務

• LocationManagerService：定位。
• NotificationManagerService：通知管理。
• AudioService：音訊管理。

ServiceManager 的角色

ServiceManager 是 Android IPC 架構中的「服務註冊中心」，負責：

1. 維護服務名稱與 Binder Handle 的對應關係

• 系統服務啟動時會透過 addService() 註冊到 ServiceManager。
• ServiceManager 建立一張「名稱 → Binder Proxy」的查詢表。

2. 提供服務查詢功能

• App 或 Framework 呼叫 getService("activity")，就能獲取對應的 Binder Proxy。

3. 統一服務管理

• 避免 Client 直接操作 Binder Driver，簡化 API 並提高安全性。

System Services 啟動流程

System Services 是在 SystemServer 進程 中啟動的。
流程大致如下：

1. Zygote 啟動

• Android 開機時，首先由 init 進程啟動 Zygote。

2. SystemServer 啟動

• Zygote fork 出 SystemServer 進程，專門負責啟動系統服務。

3. 載入服務清單

• SystemServer 會依序啟動各種服務，例如 AMS、PMS、WMS。

3. 服務註冊

• 每個服務建立後，會透過 ServiceManager.addService() 註冊到 ServiceManager。

Client 與 System Services 的交互流程

應用程式如何呼叫 System Services？
以下以 ActivityManager 為例：

1. App 呼叫 Framework API

ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);

• getSystemService() 會向 ServiceManager 查詢服務。

2. ServiceManager 查詢服務

• 返回對應的 Binder Proxy。

3. App 經由 Binder Proxy 呼叫 System Service

am.startActivity(intent);

• 其實是透過 Binder 跨進程傳遞給 AMS。

4. AMS 執行邏輯，回傳結果

案例分析

1. Activity 啟動流程（AMS 參與）

• App 呼叫 startActivity()
• Binder IPC → ActivityManagerService
• AMS 驅動 Zygote fork 新進程
• 將新 Activity 建立並回傳結果

2. 螢幕旋轉（WMS 參與）

• 使用者旋轉螢幕 → SensorService 感知 → Binder IPC 通知 WMS
• WMS 調整視窗配置，透過 Binder IPC 通知 App 重繪

架構圖解

1. System Services 與 ServiceManager 架構
   +---------------------------------------------------+
   | Application (App) |
   | 呼叫 Context.getSystemService("activity") |
   +---------------------------------------------------+
   | Android Framework API |
   | Binder Proxy / Stub (AIDL) |
   +---------------------------------------------------+
   | ServiceManager |
   | (服務名稱 <-> Binder Handle 映射表) |
   +---------------------------------------------------+
   | System Services (in SystemServer) |
   | AMS | WMS | PMS | PowerManager | Location |
   +---------------------------------------------------+
   | Native & Kernel 層 |
   | HAL | Drivers | Binder Driver (/dev/binder) |
   +---------------------------------------------------+

2. 查詢服務流程
   App (Client) ---- getService("activity") ---> ServiceManager
   | |
   | <------ 返回 Binder Proxy ---------------- |
   |
   | ---- Binder IPC ----> AMS (Server)

優缺點與挑戰

1. 優點

• 統一管理：所有服務透過 ServiceManager 註冊與查詢，結構清晰。
• 安全性高：透過 UID/PID 機制確保權限。
• 高效 IPC：Binder 機制確保了性能。

2. 缺點 / 挑戰

• 單點依賴：ServiceManager 本身是單點，若故障會造成服務不可用。
• 調試困難：System Services 問題常涉及多層 IPC，debug 難度大。
• 擴展性挑戰：隨 Android 發展，服務數量越來越多，啟動時間與資源消耗需要控制。

summary

• System Services 與 ServiceManager 是 Android Framework 的基石。
• System Services 提供了核心功能，封裝硬體與內核的複雜性。
• ServiceManager 則是它們的「註冊中心」，確保 App 能以名稱查找並使用對應的服務。