Analysis of the Startup Process of the android root file system (init daemon process analysis)

When the Android system is started, "init =/init" is usually set in the kernel boot parameters. In this way, if the kernel is successfully mounted to the file system, the INIT program in the root directory is run first. What does this program do? We only have rfsc (readthe fucking source code )!!
The INIT program source code is in system/CORE/init of Android official source code, and main is in init. C. Our analysis starts from main. Init :( 1) install the sigchld signal. (If the parent process does not wait for the child process to end, the child process will become a zombie process, occupying system resources. Therefore, the sigchld signal must be processed to recycle the resources of the zombie process to avoid unnecessary waste of resources. (2) reset umask.
What is umask, see http://www.szstudy.cn/showArticle/53978.shtml (3) create necessary folders for root FS and mount the appropriate partitions.
/Dev (tmpfs)
/Dev/PTS (devpts)
/Dev/socket
/Proc (Proc)
/Sys (sysfs) (4) creates/dev/null and/dev/kmsg nodes. (5) Parse/init. RC and add all service and operation information to the linked list. (6) extract information kernel startup parameters from/proc/cmdline and save them to global variables. (7) obtain the information hardware information and version number from the global variables obtained in the previous step. If not, extract the information from/proc/cpuinfo and save the information to the global variables. (8) Select/init. (hardware). RC Based on the hardware information, parse and add the service and operation information to the linked list.
There are two/init. (hardware ). RC: init. goldfish. RC and init. trout. RC and init programs will select a resolution based on the hardware information obtained in the previous step. (9) execute the command triggered by "early-init" in the linked list. (10) traverse the/sys folder, which is a device addition event generated by the kernel (to automatically generate a device node ). (11) initialize the property system and import the initialization property file. (12) Obtain Ro. debuggable from the property system. If the value is 1, The keychord listener is initialized. (13) Open the console. If the console is not specified in the cmdline, open the/dev/console. (14) retrieve/initlogo. RLE (a memory of 565 RLE memory segments). If it succeeds, the logo is displayed in/dev/graphics/fb0, if the parameter is missing, set/dev/tty0 to text mode and enable/dev/tty0. Then, the text "android" is displayed. (15) determine the number of rows in the Parameter Line and set the parameters in the attribute system:
1. If bootmode is
-Factory, set Ro. factorytest to 1
-Factory2: Set Ro. factorytest to 2.
-The value of other preset Ro. factorytest is 0.
2. If the serialno parameter exists, set Ro. serialno ""
3. If you have the bootmod parameter, set Ro. bootmod. Otherwise, it is "unknown"
4. If the baseband parameter is set, set Ro. baseband. Otherwise, set it to "unknown"
5. If the carrier parameter exists, set Ro. Carrier. Otherwise, it is "unknown"
6. If the bootloader parameter exists, set Ro. bootloader to "unknown"
7. Set Ro. Hardware and Ro. version through global variables (extracted from/proc/cpuinfo. (16) all the actions that are triggered as init in the response line. (17) Start the property service and fetch some property files. This action must be performed in the previous Ro. set Foo to/data/local. prop cannot commit to them.
-/System/build. Prop
-/System/Default. Prop
-/Data/local. Prop
-After the hacker obtains the property of the Mo-recognized, the hacker obtains the presistent propertie. In/data/Property (18), the sender creates a trust plane for the sigchld handler. (19) confirm that all initialization is completed:
Device_fd (device init completed)
Property_set_fd (property Server start is complete)
Signal_recv_fd (created on the trusted machine) (20) all the actions (21) that trigger the early-boot feature on the Response line (22) all the actions that trigger the feature as boot (22) based on all action (23) that are triggered as property in the response row before the expiration date, note:
-Device_fd
-Property_set_fd
-Signal_recv_fd
-If keychord exists, note that keychord_fd (24) supports bootchart. If bootchart is supported, initialize bootchart (25) and perform the following process:
-Reset the acceptance of the zookeeper event. The revents value is 0.
-Query and execute the action details column.
-Services that require heavy failover
-Zookeeper: indicates the event of callback.
-If the revents of signal_recv_fd is Pollin, a message is obtained and processed.
-If the revents of device_fd is Pollin, the handler uses handle_device_fd.
-If the revents of property_fd is Pollin, the handler uses handle_property_set_fd.
-If the keychord_fd revents is Pollin, the handler uses handle_keychord. This article is from the csdn blog, reprinted please indicate the source: http://blog.csdn.net/chatliang/archive/2009/07/13/4344432.aspx