[转]android启动过程
2010-05-26 16:56
423 查看
[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.
.
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启动过程中init.c文件分析
- Android应用程序在新的进程中启动新的Activity的方法和过程分析
- Android上层启动过程的几个关键点
- Android系统启动过程
- 分析Android 根文件系统启动过程(init守护进程分析)
- Android启动过程以及各个镜像的关系
- Android窗口管理服务WindowManagerService显示Activity组件的启动窗口(Starting Window)的过程分析
- Android apk的启动过程
- 分析Android 根文件系统启动过程(init守护进程分析)
- Android系统Recovery工作原理之使用update.zip升级过程分析(三)---Android系统的三种启动模式
- Android系统启动过程简介
- 转载:Android系统启动过程uboot--kernel--Android
- 分析Android 根文件系统启动过程(init守护进程分析)
- Android应用程序进程启动过程(前篇)
- Android系统启动过程
- android的启动过程
- android中各种img文件的作用以及系统启动过程
- Android启动过程学习总结
- android 启动过程 [ZZ]
- Android 儿子Activity在启动过程中的流程组件 && 儿子Activity在一个新的进程组件启动过程