keith猴子实验假的:Android Initialization Process

来源:百度文库 编辑:偶看新闻 时间:2024/04/18 21:33:04

initis the first process after kernel started. The corresponding sourcecode lies in: device/system/init. It does the following tasks step bystep:

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.       Initializeproperty system. Actually the property system is working as a sharememory. 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.   Enterinto an indefinite loop to wait for device/property set/child processexit events. For example, if an SD card is plugined, init will receivea device add event, so it can make node for the device. Most of theimportant process is forked in init, so if any of them crashed, initwill receive a SIGCHLD then translate it into a child process exitevent, so in the loop init can handle the process exit event andexecute the commands defined in *.rc(it will run command onrestart).

 

The.rc file is a script file defined by Android. The default isdevice/system/rootdir/init.rc. We can take a loot at the fileformat(device/system/init/readme.txt is a good overall introduction ofthe 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.  Whenan event occurs which matches an action's trigger, that action is addedto the tail of a to-be-executed queue (unless it is already on thequeue).

Each action in the queue is dequeued in sequence and each command in that action is executed in sequence.  Inithandles other activities (device creation/destruction, propertysetting, process restarting) "between" the execution of the commands inactivities.

Actions take the form of:

on

  

  

  

...

 

Services

--------

Services are programs which init launches and (optionally) restarts when they exit.  Services take the form of:

service [ ]*

  

  

   ...

 

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.

 

Thebuiltin supported commands are defined indevice/system/init/keywords.h. Commands are implementd indevice/system/init/bultins.c.

 

Theinit program only executes five kinds of triggers: “early-init”,“init”, “early-boot”, “boot”, “property:*”. Take a look at thefollowing line in default init.rc.

class_start default

Thisline is a command for the action corresponding to “boot” trigger. Itwill start all services whose class name equals to “default”. Bydefault, if no class option is defined for a service, the service’sclass name is “default”. So this line will start all the services inthe order of position in the file by default. (BTW, you can start anyservice using start commands, if you like.) Any service is run as aforked process of init, take a look at the source code of service_startin 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, receivecommands through local socket to mount any fs. The source is indevice/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. Thesource is in device/system/bin/logwrapper. By default is disabled.

hfag:start Bluetooth handsfree audio gateway, it’s only used by BlueZ. Thesource is in device/system/Bluetooth/bluez-utils. By default isdisabled.

hsag:start Bluetooth headset audio gateway, it’s only used by BlueZ. Thesource is in device/system/Bluetooth/bluez-utils. By default isdisabled.

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.       Callthe main function in the JAVA class namedcom.android.internal.os.ZygoteInit whose source isdevice/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)         CallZygote::forkSystemServer (implemented indevice/dalvik/vm/InternalNative.c) to fork a new process. In the newprocess, call the main function in the JAVA class namedcom.android.server.SystemServer, whose source is indevice/java/services/com/android/server.

                         i.              Load libandroid_servers.so

                       ii.              CallJNI native init1 function implemented indevice/libs/android_servers/com_android_server_SystemServers. It onlycalls system_init implemented indevice/servers/system/library/system_init.cpp.

l         If running on simulator, instantiate AudioFlinger, MediaPlayerService and CameraService here.

l         Callinit2 function in JAVA class named com.android.server.SystemServer,whose source is in device/java/services/com/android/server. Thisfunction is very critical for Android because it start all of AndroidJAVA 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

FinallySystemServer::init2 will call ActivityManagerService.systemReady tolaunch the first activity by senting Intent.CATEGORY_HOME intent.

 

Thereis another way to start system server, which is through a program namedsystem_server whose source is device/servers/system/system_main.cpp. Italso calls system_init to start system services. So there is aquestion: why does Android have two methods to start system services?My guess is that directly start system_server may have synchronousproblem with zygote because system_server will call JNI to startSystemServer::init2, while at that time zygote may not start JAVA VMyet. So Android uses another method. After zynote is initialized, forka new process to start system services.


-----------------------------------------------------------------------------------------------------------------------------------------------

Original link: http://blog.chinaunix.net/u2/66024/showart_1892735.html