FW:Android 启动过程

http://blog.chinaunix.net/u1/44989/showart_1856646.html

Android 启动过程 

[First written by Steve Guo, please keep the mark ifforwarding.].

init is the first process after kernel started. Thecorresponding source code lies in: 

device/system/init. 

It does the following tasks step bystep: 

1.  Initialize logsystem. 

2.  Parse /init.rc and/init.%hardware%.rc. 

3.  Execute early-init action in the twofiles parsed in step 2. 

4.  Device specific initialize. For example,make all device node in 

    /devand download firmwares. 

5.  Initialize property system. Actually theproperty system is working as a sharememory. 

    Logically it looks like a registry under Windowssystem. 

6.  Execute init action in the two filesparsed in step 2. 

7.  Start propertyservice. 

8.  Execute early-boot and boot actions inthe two files parsed in step 2. 

9.  Execute property action in the two filesparsed in step 2. 

10. Enter into an indefinite loop to wait for device/propertyset/child process exit events. 

    Forexample, if an SD card is plugined, init will receive a device addevent, so it can 

    makenode for the device. Most of the important process is forked ininit, so if any of 

    themcrashed, init will receive a SIGCHLD then translate it into a childprocess exit event,

     so inthe loop init can handle the process exit event and execute thecommands defined in 

    *.rc(it will run command onrestart). 

The .rc file is a script file defined by Android. The defaultis device/system/rootdir/init.rc. 

We can take a loot at the fileformat(device/system/init/readme.txt is a good overallintroduction

of the script). Basically the script file contains actions andservices. 

  

Actions 

------- 

Actions are named sequences of commands. Actions have atrigger which is used to determine when the

action should occur.  When an event occurswhich matches an action's trigger, that action isadded 

to the tail of a to-be-executed queue (unless it is already onthe queue). 

Each action in the queue is dequeued in sequence and eachcommand in that action is executed in sequence. 

Init handles other activities (device creation/destruction,property setting, process restarting)"between" 

the execution of the commands inactivities. 

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.  Theyaffect how and when init runs the service. 

  

Triggers 

-------- 

Triggers are strings which can be used to match certain kindsof events and used to

cause an action to occur.  

The builtin supported commands are defined indevice/system/init/keywords.h. Commands 

are implementd indevice/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 indefault 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, ifno class option is defined 

for a service, the service’s class name is “default”. So thisline 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 aforked process of init, take a 

look at the source code of service_start indevice/system/init.c. 

So according to the default init.rc, the following serviceswill be executed step by step: 

console: star a shell. The source is indevice/system/bin/ash. 

adbd: start adb daemon. The source is in device/tools/adbd. Bydefault is disabled. 

servicemanager: start binder system. The source is indevice/commands/binder. 

mountd: mount all fs defined in /system/etc/mountd.conf ifstarted, receive commands through

      local socket to mount any fs. The source is indevice/system/bin/mountd. 

debuggerd: start debug system. The source is indevice/system/bin/debuggerd. 

rild: start radio interface layer daemon. The source is indevice/commands/rind. 

zygote: start Android Java Runtime and start system server.It’s the most important service. 

       The source is indevice/servers/app. 

media: start AudioFlinger, MediaPlayerService andCameraService. The source is in 

     device/commands/mediaserver. 

bootsound: play the default boot sound/system/media/audio/ui/boot.mp3. The source isin 

         device/commands/playmp3. 

dbus: start dbus daemon, it’s only used by BlueZ. The sourceis in device/system/Bluetooth/dbus-daemon. 

hcid: redirect hcid’s stdout and stderr to the Android loggingsystem. The source is in 

     device/system/bin/logwrapper. By default isdisabled. 

hfag: start Bluetooth handsfree audio gateway, it’s only usedby BlueZ. The source is in 

     device/system/Bluetooth/bluez-utils. By defaultis disabled. 

hsag: start Bluetooth headset audio gateway, it’s only used byBlueZ. The source is in 

     device/system/Bluetooth/bluez-utils. By defaultis disabled. 

installd: start install package daemon. The source is indevice/servers/installd. 

flash_recovery: load /system/recovery.img. The source is indevice/commands/recovery/mtdutils. 

  

Zygote service does the following tasks step bystep: 

1. Create JAVA VM. 

2. Register android native function for JAVAVM. 

3. Call the main function in the JAVA class namedcom.android.internal.os.ZygoteInit whose 

   source isdevice/java/android/com/android/internal/os/ZygoteInit.java. 

  a) Load ZygoteInitclass 

  b) Register zygotesocket 

  c) Load preloadclasses(the default file isdevice/java/android/preloaded-classes) 

  d) Load preloadresources 

  e) CallZygote::forkSystemServer (implemented indevice/dalvik/vm/InternalNative.c) to fork 

     a newprocess. In the new process, call the main function in the JAVAclass named 

    com.android.server.SystemServer, whose source is indevice/java/services/com/android/server. 

     i.  Loadlibandroid_servers.so 

     ii. Call JNI native init1 function implemented indevice/libs/android_servers/com_android_server_SystemServers. Itonly calls system_init implemented indevice/servers/system/library/system_init.cpp. 

         * If running on simulator, instantiateAudioFlinger, MediaPlayerService and CameraServicehere. 

         * Call init2 function in JAVA class namedcom.android.server.SystemServer, whose source is indevice/java/services/com/android/server. This function is verycritical for Android because it start all of Android JAVAservices. 

         * If not running on simulator, callIPCThreadState::self()->joinThreadPool() to enterinto service dispatcher. 

  

SystemServer::init2 will start a new thread to start all JAVAservices as follows: 

Core Services: 

    1. Starting Power Manager 

    2. Creating Activity Manager 

    3. Starting TelephonyRegistry 

    4. Starting Package Manager 

    5. Set Activity Manager Service as SystemProcess 

    6. Starting Context Manager 

    7. Starting System ContextProviders 

    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 callActivityManagerService.systemReady to launch the firstactivity 

by senting Intent.CATEGORY_HOMEintent. 

  

There is another way to start system server, which is througha program named system_server whose source isdevice/servers/system/system_main.cpp. It also calls system_init tostart system services. So there is a question: why does Androidhave two methods to start system services? My guess is thatdirectly start system_server may have synchronous problem withzygote because system_server will call JNI to startSystemServer::init2, while at that time zygote may not start JAVAVM yet. So Android uses another method. After zynote isinitialized, fork a new process to start systemservices.