Android的启动过程
Passion注：本篇文章描述的是Android的啟動過程，不包括Linux的啟動過程
分別來自
http://dingpwen.spaces.live.com/blog/cns!4CADD02D22459860!208.entry?fl=cat
http://www.eepw.com.cn/article/89567.htm
http://blog.csdn.net/guiterb/archive/2009/04/03/4047369.aspx
#####################################################
1. Boot 系統(tǒng)初始化， 具體過程參見 (system/core/init/Init.c) 中的 main 函數(shù)，這時候，手機或者模擬器出現(xiàn)的畫面是一個 console ，顯示 “ANDROID”msg 。
?
2. 初始化成功后，就開始 mounting 系統(tǒng)，具體參見 (system/core/mountd/Mountd.c)? 中的 main 函數(shù)。
?
3 ．接下來運行 ndroidRuntime ，并開始啟動 java 虛擬機 dalvikvm 。
?
4. Java 虛擬機啟動成功后，開始系統(tǒng)初始化。系統(tǒng)初始的第一步是用 JNI 方式實現(xiàn)的，對應 java 代碼為 (frameworks/base/services/java/com/android/server/SystemServer.java) init1 （ Native ）函數(shù)，對應的 JNI C++ 代碼為 (frameworks/base/core/jni/server/com_android_server_SystemServer.cpp) ，而實現(xiàn)的 C++ 代碼為
(frameworks/base/cmds/system_server/library/ System_init.cpp)?? 中的 system_init （）函數(shù)。
?
5. system_init 調用 SurfaceFlinger ， SurfaceFlinger 的 readyToRun() 函數(shù)用 BootAnimation 來實現(xiàn)開機動畫，這時候手機或者模擬器顯示是一副背景圖加一個動態(tài)的小機器人。
?
6. 系統(tǒng)初始化的第二步，將啟動 ServerThread 進程，參見 SystemServer.init2() 。 ServerThread 將啟動各種系統(tǒng)服務，如 Power Manager 、 Activity Manager 等等，具體參見 ServerThread 的 run 函數(shù)， ServerThread 同在 SystemServer.java 中。
?
7. 這之后的事，應該就是進入系統(tǒng)了。（這部分沒有調查過）。
#####################################################
對于關注Android 底層的朋友來說，其具體的啟動過程應該是比較吸引我們的。但是很多啟動文件什么的，都得adb push到host上來看，挺不方便的，都怪Android 自帶的Toolbox太簡略了。所以在深入了解Android 的啟動流程之前，我們來把Busybox安裝到Android 上去，這樣，就有很多工具供我們使用了。
首先去busybox主頁 下載最新版本的源代碼，然后用arm的交叉編譯器編譯出busybox的可執(zhí)行程序，編譯的時候需要注意一些設置選項，例如
Build Options —>
Build BusyBox as a static binary (no shared libs) 這個要選上，因上這樣子編譯出來的busyBox才是可以獨立運行的。
│Do you want to build BusyBox with a Cross Compiler? │ │
│ │(/HOME/toolchains/gcc-4.0.2-glibc-2.3.5/arm-9tdmi-linux-gnu/bin/arm-9tdmi-linux-gnu│ 這是交叉編譯器的路徑，要根據(jù)具體的情況來設置。
Installation Options —>
Don’t use /usr
這樣子編譯出來的busybox才不會安裝到你主機的/usr目錄下。一定要選上。
busybox的功能選項根據(jù)需要自選,但是不要太貪心.
OK，這里就不糾纏于編譯busybox的東西了，網上資料無數(shù)。接下來，我們把busybox安裝到模擬器上去。先在模擬器上隨便建一個busybox的文件夾，然后進入busybox可執(zhí)行文件目錄，使用命令
adb push busybox.asc /data/busybox/busybox
然后進入adb shell，chmod 777 ./busybox，就可以直接使用了。但現(xiàn)在還是不方便，總不能每用一個命令就輸一次busybox吧?所以，我們可以先用./busybox --install將程序都安裝到當前目錄下，然后把當前目錄添加到PATH變量中即可。暫時使用export來添加吧，如果想永久添加，往下看。
好了，準備工作完成，開始研究的工作了。既然是研究啟動過程，那當然是先看看init.rc文件。去etc目錄打開它，分析一下內容，首先是對 env的定義，也就是全局環(huán)境變量的定義，接下來的建立和初始化里面的內容目前還不清楚什么意思，緊接著就是系統(tǒng)啟動時運行的初始進程信息，這個比較有意 思，包括了usbd-config和qemu，qemu自不用說，而usbd-config作為初始啟動的進程，應該就是和上一篇文章猜的一樣，用來調試 或者usb通信的。往下看，是在初始啟動進程完成之后開始啟動的服務進程，這些進程如果因故退出，會自動重啟。這里面包括了console控制 臺，adbd監(jiān)護進程，usbd監(jiān)護進程，debuggerd監(jiān)護進程等.除去這些守護進程，能引起我們注意的，是runtime和zygote。這兩個 進程似乎掌管著其他進程以及應用程序的啟動。
現(xiàn)在，來讓我們做一個實驗吧，將自動調用的啟動過程變成手動，看看啟動流程具體是什么樣的。想達到這個目的，首先就是要修改init.rc文 件，當然不是在模擬器的console中改，一是不能改，二是你改了也沒用，下次加載就會給你覆蓋了。所以，我們要從原始鏡像ramdisk.img入手 了。從2.6標準Linux內核開始，initrd.img都采用cpio壓縮，猜測ramdisk.img也一樣，需要使用gunzip解壓縮，然后再 使用cpio解包。好，進入tools/lib/images目錄下，先用file命令看看ramdisk.img的類型，沒錯，系統(tǒng)提示
ramdisk.img: gzip compressed data, from Unix
很好，然后將ramdisk.img復制一份到任何其他目錄下，將其名稱改為ramdisk.img.gz，并使用命令
gunzip ramdisk.img.gz
然后新建一個文件夾，叫ramdisk吧，進入，輸入命令
cpio -i -F ../ramdisk.img
這下，你就能看見并操作ramdisk里面的內容了。當然你也可以直接在外面進行操作，但是還是建議把cpio解壓縮出來的內容全部集中在一個文件夾里面，因為一會我們還要將其壓縮成新的ramdisk.img。
OK，現(xiàn)在開始修改步驟吧。用任何一款編輯器打開init.rc，首先在PATH那里加上你的Busybox安裝路徑，然后注釋內容，我們要手工啟動他們。
# zygote {# exec /system/bin/app_process
# args {
# 0 -Xzygote
# 1 /system/bin
# 2 –zygote
# }
# autostart 1
# }# runtime {
# exec /system/bin/runtime
# autostart 1
# }
在這里需要注意，不要同時把兩者都注釋了，注釋某一個，再試驗手工啟動它，如果兩者同時注釋我這里有問題，無法啟動。
好，接下來，使用下列命令重新打包成鏡像
cpio -i -t -F ../ramdisk.img > list
cpio -o -H newc -O lk.img < list
當前目錄下生成的lk.img就是我們的新鏡像了。使用自己的鏡像啟動emulator;
emulator -console -ramdisk lk.img
如果我們注釋的是zygote，那么在#后輸入
app_process -Xzygote /system/bin –zygote
手工啟動，命令行中輸出的信息是
Prepping: /system/app/AlarmProvider.apk:/system/app/Browser.apk:/system/app/
Calendar.apk:/system/app/Camera.apk:/system/app/Contacts.apk:
/system/app/Development.apk:/system/app/GDataFeedsProvider.apk:/system/app/
Gmail.apk:/system/app/GmailProvider.apk:/system/app/GoogleApps.apk:
/system/app/GoogleAppsProvider.apk:/system/app/Home.apk:/system/app/ImProvider.apk:
/system/app/Maps.apk:/system/app/MediaPickerActivity.apk:
/system/app/MediaProvider.apk:/system/app/Phone.apk:/system/app/PimProvider.apk:/system/
app/ApiDemos.apk:/system/app/SettingsProvider.apk:
/system/app/Sms.apk:/system/app/SyncProvider.apk:/system/app/TelephonyProvider.apk:
/system/app/XmppService.apk:/system/app/YouTube.apk
File not found: /system/app/AlarmProvider.apk
File not found: /system/app/Calendar.apk
File not found: /system/app/Camera.apk
File not found: /system/app/GDataFeedsProvider.apk
File not found: /system/app/Gmail.apk
File not found: /system/app/GmailProvider.apk
File not found: /system/app/MediaPickerActivity.apk
File not found: /system/app/PimProvider.apk
File not found: /system/app/ApiDemos.apk
File not found: /system/app/Sms.apk
File not found: /system/app/SyncProvider.apk
File not found: /system/app/YouTube.apk
Prep complete
嘿嘿，從File not found的信息中可以看到一些Google可能會即將推出的應用，比如Gmail什么的。當然，這些都是Java框架的啟動信息，我們以后還要借助其他工具來進行進一步探索。
如果我們注釋的是runtime，那么輸出信息是：
+++ post-zygote
老實說，沒有明白這是啥意思，呵呵，吃飯時間到了，懶得看了。
好了，今天就說到這，基本的方法就是這樣，有興趣的朋友可以進一步深入研究。我們下一篇文章見。
?
#####################################################
[First written by Steve Guo, please keep the mark if forwarding.] .
init is the first process after kernel started. The corresponding source code lies in: device/system/init. It does the following tasks step by step:
1. ?????? Initialize log system.
2. ?????? Parse /init.rc and /init.%hardware%.rc.
3. ?????? Execute early-init action in the two files parsed in step 2.
4. ?????? Device specific initialize. For example, make all device node in /dev and download firmwares.
5. ?????? Initialize property system. Actually the property system is working as a share memory. Logically it looks like a registry under Windows system.
6. ?????? Execute init action in the two files parsed in step 2.
7. ?????? Start property service.
8. ?????? Execute early-boot and boot actions in the two files parsed in step 2.
9. ?????? Execute property action in the two files parsed in step 2.
10. ?? Enter into an indefinite loop to wait for device/property set/child process exit events. For example, if an SD card is plugined, init will receive a device add event, so it can make node for the device. Most of the important process is forked in init, so if any of them crashed, init will receive a SIGCHLD then translate it into a child process exit event, so in the loop init can handle the process exit event and execute the commands defined in *.rc(it will run command onrestart).
?
The .rc file is a script file defined by Android. The default is device/system/rootdir/init.rc. We can take a loot at the file format(device/system/init/readme.txt is a good overall introduction of the script). Basically the script file contains actions and services.
?
Actions
-------
Actions are named sequences of commands. Actions have a trigger which is used to determine when the action should occur.? When an event occurs which matches an action's trigger, that action is added to the tail of a to-be-executed queue (unless it is already on the queue).
Each action in the queue is dequeued in sequence and each command in that action is executed in sequence.? Init handles other activities (device creation/destruction, property setting, process restarting) "between" the execution of the commands in activities.
Actions take the form of:
on <trigger>
?? <command>
?? <command>
?? <command>
...
?
Services
--------
Services are programs which init launches and (optionally) restarts when they exit.? Services take the form of:
service <name> <pathname> [ <argument> ]*
?? <option>
?? <option>
?? ...
?
Options
-------
Options are modifiers to services.? They affect how and when init runs the service.
?
Triggers
--------
Triggers are strings which can be used to match certain kinds of events and used to cause an action to occur.
?
The builtin supported commands are defined in device/system/init/keywords.h. Commands are implementd in device/system/init/bultins.c.
?
The init program only executes five kinds of triggers: “early-init”, “init”, “early-boot”, “boot”, “property:*”. Take a look at the following line in default init.rc.
class_start default
This line is a command for the action corresponding to “boot” trigger. It will start all services whose class name equals to “default”. By default, if no class option is defined for a service, the service’s class name is “default”. So this line will start all the services in the order of position in the file by default. (BTW, you can start any service using start commands, if you like.) Any service is run as a forked process of init, take a look at the source code of service_start in device/system/init.c.
?
So according to the default init.rc, the following services will be executed step by step:
console : star a shell. The source is in device/system/bin/ash.
adbd : start adb daemon. The source is in device/tools/adbd. By default is disabled.
servicemanager : start binder system. The source is in device/commands/binder.
mountd : mount all fs defined in /system/etc/mountd.conf if started, receive commands through local socket to mount any fs. The source is in device/system/bin/mountd.
debuggerd : start debug system. The source is in device/system/bin/debuggerd.
rild : start radio interface layer daemon. The source is in device/commands/rind.
zygote : start Android Java Runtime and start system server. It’s the most important service. The source is in device/servers/app.
media : start AudioFlinger, MediaPlayerService and CameraService. The source is in device/commands/mediaserver.
bootsound : play the default boot sound /system/media/audio/ui/boot.mp3. The source is in device/commands/playmp3.
dbus : start dbus daemon, it’s only used by BlueZ. The source is in device/system/Bluetooth/dbus-daemon.
hcid : redirect hcid’s stdout and stderr to the Android logging system. The source is in device/system/bin/logwrapper. By default is disabled.
hfag : start Bluetooth handsfree audio gateway, it’s only used by BlueZ. The source is in device/system/Bluetooth/bluez-utils. By default is disabled.
hsag : start Bluetooth headset audio gateway, it’s only used by BlueZ. The source is in device/system/Bluetooth/bluez-utils. By default is disabled.
installd : start install package daemon. The source is in device/servers/installd.
flash_recovery : load /system/recovery.img. The source is in device/commands/recovery/mtdutils.
?
Zygote service does the following tasks step by step:
1. ?????? Create JAVA VM.
2. ?????? Register android native function for JAVA VM.
3. ?????? Call the main function in the JAVA class named com.android.internal.os.ZygoteInit whose source is device/java/android/com/android/internal/os/ZygoteInit.java.
a) ???????? Load ZygoteInit class
b) ??????? Register zygote socket
c) ??????? Load preload classes(the default file is device/java/android/preloaded-classes)
d) ??????? Load preload resources
e) ???????? Call Zygote::forkSystemServer (implemented in device/dalvik/vm/InternalNative.c) to fork a new process. In the new process, call the main function in the JAVA class named com.android.server.SystemServer, whose source is in device/java/services/com/android/server.
???????????????????????? i. ????????????? Load libandroid_servers.so
?????????????????????? ii. ????????????? Call JNI native init1 function implemented in device/libs/android_servers/com_android_server_SystemServers. It only calls system_init implemented in device/servers/system/library/system_init.cpp.
l ???????? If running on simulator, instantiate AudioFlinger, MediaPlayerService and CameraService here.
l ???????? Call init2 function in JAVA class named com.android.server.SystemServer, whose source is in device/java/services/com/android/server. This function is very critical for Android because it start all of Android JAVA services .
l ???????? If not running on simulator, call IPCThreadState::self()->joinThreadPool() to enter into service dispatcher.
?
SystemServer::init2 will start a new thread to start all JAVA services as follows:
Core Services:
1. ?????? Starting Power Manager
2. ?????? Creating Activity Manager
3. ?????? Starting Telephony Registry
4. ?????? Starting Package Manager
5. ?????? Set Activity Manager Service as System Process
6. ?????? Starting Context Manager
7. ?????? Starting System Context Providers
8. ?????? Starting Battery Service
9. ?????? Starting Alarm Manager
10. ?? Starting Sensor Service
11. ?? Starting Window Manager
12. ?? Starting Bluetooth Service
13. ?? Starting Mount Service
Other services
1. ?????? Starting Status Bar Service
2. ?????? Starting Hardware Service
3. ?????? Starting NetStat Service
4. ?????? Starting Connectivity Service
5. ?????? Starting Notification Manager
6. ?????? Starting DeviceStorageMonitor Service
7. ?????? Starting Location Manager
8. ?????? Starting Search Service
9. ?????? Starting Clipboard Service
10. ?? Starting Checkin Service
11. ?? Starting Wallpaper Service
12. ?? Starting Audio Service
13. ?? Starting HeadsetObserver
14. ?? Starting AdbSettingsObserver
Finally SystemServer::init2 will call ActivityManagerService.systemReady to launch the first activity by senting Intent.CATEGORY_HOME intent .
?
There is another way to start system server, which is through a program named system_server whose source is device/servers/system/system_main.cpp. It also calls system_init to start system services. So there is a question: why does Android have two methods to start system services? My guess is that directly start system_server may have synchronous problem with zygote because system_server will call JNI to start SystemServer::init2, while at that time zygote may not start JAVA VM yet. So Android uses another method. After zynote is initialized, fork a new process to start system services.
?
總結
以上是生活随笔為你收集整理的Android的启动过程的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 官居几品所有女角色介绍
- 下一篇： Android中Log信息的输出方法