System_Server進程
運行在system server進程中的服務比較多,這是整個android架構的基礎
Native服務
SurfaceFlinger
這是framebuffer合成的服務,將各個應用程式及應用程式中的邏輯視窗映像資料(surface)合成到一個物理視窗中顯示(framebuffer)的服務程式
Java服務:
這部分的服務大部分都有一個供應用進程使用的manager類,這就是一個RPC調用,使用者通過調用xxxManager的方法,實際上被Binder給遷移到system_server進程中對應的xxxManagerService中對應的方法,並將結果再通過binder帶回。
1. EntropyService
熵服務,周期性的載入和儲存隨機資訊。主要是linux開機後,/dev/random的狀態可能是可預知的,這樣一些需要隨機資訊的應用程式就可能會有問題。這個無需提供應用程式介面。
2. PowerManagerService –> PowerManager
Android 的電源管理也是很重要的一部分。比如在待機的時候關掉不用的裝置,待機時螢幕和鍵盤背光的關閉,使用者操作的時候該開啟多少裝置等等。
3. ActivityManagerService->ActivityManager
這個是整個Android framework架構中最為核心的一個服務,管理整個架構中任務、進程管理, Intent解析等的核心實現。雖然名為Activity的Manager Service,但它管轄的範圍,不只是Activity,還有其他三大組件,和它們所在的進程。也就是說使用者應用程式的生命管理,都是由他負責的。
4. TelephonyRegistry->TelephonyManager
電話註冊、管理服務模組,可以擷取電話的連結狀態、訊號強度等等。<可以刪掉,但要看的大概明白>
5. PackageManagerService -> PackageManager
包括對軟體包的解包,驗證,安裝以及升級等等,對於我們現在不能安裝.so檔案的問題,應該先從這塊著手分析原因。
6. AccountManagerService -> AccountManager
A system service that provides account, password, and authtoken management for all
accounts on the device。
7. ContentService -> ContentResolver
內容服務,主要是資料庫等提供解決方案的服務。
8. BatteryService
監控電池充電及狀態的服務,當狀態改變時,會廣播Intent
9. HardwareService
一般是ring和vibrate的服務程式
10. SensorService -> SensorManager
管理Sensor裝置的服務,負責註冊client裝置及當client需要使用sensor時啟用Sensor
11. WindowManagerService -> WindowManager -> PhoneWindowManager
和ActivityManagerService高度粘合
視窗管理,這裡最核心的就是輸入事件的分發和管理。
12. AlarmManagerService -> AlarmManager
鬧鐘服務程式
13. BluetoothService -> BluetoothDevice
藍芽的後台管理和服務程式
14. StatusBarService -> StatusBarManager
負責statusBar標的更新、動畫等等的服務,服務不大。
15. ClipboardService -> ClipboardManager
和其他系統的clipBoard服務類似,提供複製黏貼功過。
16. InputMethodManagerService -> InputMethodManager
IME的管理服務程式,包括何時使能IME,切換IME等等。
17. NetStatService
行動電話通訊服務
18. ConnectivityService -> ConnectivityManager
網路連接狀態服務,可供其他應用查詢,當網路狀態變化時,也可廣播改變。
19. AccessibilityManagerService-> AccessibilityManager
這塊可能要仔細看一下,主要是一些View獲得點擊、焦點、文字改變等事件的分發管理,對整個系統的調試、問題定位等,也需要最這個服務仔細過目一下。
20. NotificationManagerService -> NotificationManager
負責管理和通知後台事件的發生等,這個和statusbar膠黏在一起,一般會在statusbar上添加響應表徵圖。使用者可以通過這知道系統後台發生了什麼事情。
21. MountService
磁碟載入服務程式,一般要和一個linux daemon程式如vold/mountd等合作起作用,主要負責監聽並廣播device的mount/unmount/bad removal等等事件。
22. DeviceStorageMonitorService
監控磁碟空間的服務,當磁碟空間不足10%的時候會給使用者警告
23. LocationManagerService -> LocationManager
要加入GPS服務等,這部分要細看,現在應用中的navigation沒響應,可以從此處著手看一下
24. SearchManagerService -> SearchManager
The search manager service handles the search UI, and maintains a registry of searchable activities.
25. Checkin Service(FallbackCheckinService)
貌似checkin service是google提供的包,沒有原始碼,源碼只有fallbackCheckinService
26. WallpaperManagerService -> WallpaperManager
管理案頭背景的服務,深度定製化案頭系統,需要看懂並擴充<同時要相容>這部分
27. AudioService -> AudioManager
AudioFlinger的上層管理封裝,主要是音量、音效、聲道及鈴聲等的管理
28. HeadsetObserver
耳機插拔事件的監控小迴圈
29. DockObserver
如果系統有個座子,當手機裝上或拔出這個座子的話,就得靠他來管理了
30. BackupManagerService -> BackupManager
備份服務
31. AppWidgetService -> AppWidgetManager
Android可以讓使用者寫的程式以widget的方式放在案頭上,這就是這套管理和服務的介面
32. StatusBarPolicy
管理哪個表徵圖該在status bar上顯示的策略。
mediaServer服務進程
MediaServer服務基本上都是native的services,mediaServer進程也是在init.rc中啟動的,它不是一個daemon進程,這點容易搞混。他也是和systemserver進程類似的系統服務進程,提供應用進程的RPC調用的真正服務代碼所啟動並執行位置。其服務都是和媒體錄播放有關,主要有三個服務:
AudioFlinger
聲音的錄播放服務,包括混音等
MediaPlayerService
提供媒體播放服務,opencore是這塊的核心模組,對java端的介面在mediaplayer.java
CameraService
提供camera的錄製、preview等功能的服務
AudioPolicyService
主要功能有檢查輸入輸出裝置的串連狀態及系統的音頻策略的切換等。
9.4.1 啟動各種系統服務線程
SystemServer進程在Android的運行環境中扮演了"神經中樞"的作用,APK應用中能夠直接互動的大部分系統服務都在該進程中運行,常見的比如WindowManagerServer(Wms)、ActivityManagerSystemService(AmS)、PackageManagerServer(PmS)等,這些系統服務都是以一個線程的方式存在於SystemServer進程中。下面就來介紹到底都有哪些服務線程,及其啟動的順序。
SystemServer的main()函數首先調用的是init1()函數,這是一個native函數,內部會進行一些與Dalvik虛擬機器相關的初始化工作。該函數執行完畢後,其內部會調用Java端的init2()函數,這就是為什麼Java源碼中沒有引用init2()的地方,主要的系統服務都是在init2()函數中完成的。
該函數首先建立了一個ServerThread對象,該對象是一個線程,然後直接運行該線程,如以下代碼所示:
於是,從ServerThread的run()方法內部開始真正啟動各種服務線程。
基本上每個服務都有對應的Java類,從編碼規範的角度來看,啟動這些服務的模式可歸類為三種,9-3所示。
模式一是指直接使用建構函式構造一個服務,由於大多數服務都對應一個線程,因此,在建構函式內部就會建立一個線程並自動運行。
模式二是指服務類會提供一個getInstance()方法,通過該方法擷取該服務物件,這樣的好處是保證系統中僅包含一個該服務物件。
模式三是指從服務類的main()函數中開始執行。
無論以上何種模式,當建立了服務物件後,有時可能還需要調用該服務類的init()或者systemReady()函數以完成該對象的啟動,當然這些都是服務類內部自訂的。為了區分以上啟動的不同,以下採用一種新的方式描述該啟動過程。比如當一個服務物件是通過模式一建立,並調用init()完成該服務的啟動,我們就用模式1.2表示;如果建構函式返回後就已經啟動,而無須任何其他調用,即什麼都不做(nothing),我們就用模式1.1表示。
表9-2列出了SystemServer中所啟動的所有服務,以及這些服務的啟動模式。
表9-2 SystemServer中啟動服務列表
服務類名稱 |
作用描述 |
啟動模式 |
EntropyService |
提供偽隨機數 |
1.0 |
PowerManagerService |
電源管理服務 |
1.2/3 |
ActivityManagerService |
最核心的服務之一,管理Activity |
自訂 |
TelephonyRegistry |
通過該服務註冊電話模組的事件響應,比如重啟、關閉、啟動等 |
1.0 |
PackageManagerService |
程式包管理服務 |
3.3 |
AccountManagerService |
賬戶管理服務,是指連絡人賬戶,而不是Linux系統的賬戶 |
1.0 |
ContentService |
ContentProvider服務,提供跨進程資料交換 |
3.0 |
BatteryService |
電池管理服務 |
1.0 |
LightsService |
自然光強度感應感應器服務 |
1.0 |
VibratorService |
震動器服務 |
1.0 |
AlarmManagerService |
定時器管理服務,提供定時提醒服務 |
1.0 |
WindowManagerService |
Framework最核心的服務之一,負責視窗管理 |
3.3 |
BluetoothService |
藍芽服務 |
1.0 + |
DevicePolicyManagerService |
提供一些系統層級的設定及屬性 |
1.3 |
StatusBarManagerService |
狀態列管理服務 |
1.3 |
ClipboardService |
系統剪下板服務 |
1.0 |
InputMethodManagerService |
IME管理服務 |
1.0 |
NetStatService |
網路狀態服務 |
1.0 |
NetworkManagementService |
網路管理服務 |
NMS.create() |
ConnectivityService |
網路連接管理服務 |
2.3 |
ThrottleService |
暫不清楚其作用 |
1.3 |
(續表)
服務類名稱 |
作用描述 |
啟動模式 |
AccessibilityManagerService |
輔助管理程式截獲所有的使用者輸入,並根據這 些輸入給使用者一些額外的反饋,起到輔助的效果 |
1.0 |
MountService |
掛載服務,可通過該服務調用Linux層面的mount程式 |
1.0 |
NotificationManagerService |
通知欄管理服務,Android中的通知欄和狀 態欄在一起,只是介面上前者在左邊,後者在右邊 |
1.3 |
DeviceStorageMonitorService |
磁碟空間狀態檢測服務 |
1.0 |
LocationManagerService |
地理位置服務 |
1.3 |
SearchManagerService |
搜尋管理服務 |
1.0 |
DropBoxManagerService |
通過該服務訪問Linux層面的Dropbox程式 |
1.0 |
WallpaperManagerService |
牆紙管理服務,牆紙不等同於案頭背景, 在View系統內部,牆紙可以作為任何視窗的背景 |
1.3 |
AudioService |
音頻管理服務 |
1.0 |
BackupManagerService |
系統備份服務 |
1.0 |
AppWidgetService |
Widget服務 |
1.3 |
RecognitionManagerService |
身份識別服務 |
1.3 |
DiskStatsService |
磁碟統計服務 |
1.0 |
AmS的啟動模式如下:
調用main()函數,返回一個Context對象,而不是AmS服務本身。
調用AmS.setSystemProcess()。
調用AmS.installProviders()。
調用systemReady(),當AmS執行完systemReady()後,會相繼啟動相關聯服務的systemReady()函數,完成整體初始化。
關於具體某個服務的內部啟動過程,請參照源碼,這些過程一般都比較簡單。