This is a blog written with heart, and I hope everyone can read it carefully and help find the improvement of the article, thank you; ## Service startup mechanism 1. parse_config_file (init.rc) in the main function of the system/core/init/init.c file reads and parses the contents of the init.rc file. Place the service information in the service_list of system/core/init/init_parser.cpp 2. The main function of the system/core/init/init.c file continues to execute restart_servie_if_needed(...) -> service_start(...) -> Execve(...) to establish the service process; In order to let everyone see more clearly, the last picture first "Overall Startup Framework": ![这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTYwNDI3MTgwNzQxMjA1?x-oss-process=image/format,png) ## init.rc Introduction At present, Linux has many communication mechanisms that can interact between user space and kernel space, such as device driver files (located in the /dev directory), memory files (/proc, /sys directories, etc.). Students who know Linux should know that one of the important features of Linux is that everything exists in the form of files. For example, a device usually corresponds to one or more device files. These files that interact with the kernel space are in the user space, so after loading in the Linux kernel, you need to first create the directory where these files are located. The program to complete these tasks is the init described in this article. Init is a command line program. One of its main tasks is to create a directory where these files that interact with the kernel space are located. When the Linux kernel is loaded, the first thing to do is to call the init program, that is, init is the first program executed in user space. Although the work done by init is not much, the code is still very complicated. **Init program is not composed of one source code file**, but is formed by linking a set of object files of source code files. These files are located in the following directories. It should be understood that these init.rc are just grammar files, not programs. The real entry point is the system/core/init/init.c mentioned above. Because the init.c file is relatively large, in the second part of the article I will briefly analyze the init startup process through the main function; There are two init.rc, located in: ./system/core/rootdir/init.rc ./bootable/recovery/etc/init.rc It can be guessed from the catalog that the two init.rc usage scenarios are different. One is used for flashing, that is, to enter the recorvery mode, and the other is used for normal startup; our focus here is the above one, which is also init The one associated with .c; ## init.rc grammatical structure analysis To understand how init.rc is parsed, we need to look at the documentation first. The documentation is there. Of course, you can also look at the [Chinese version] (https://yq.aliyun.com/articles/10311) ； init.rc is located in /bootable/recovery/etc/init.rc The Android initialization language contains four types of declarations: Actions (behavior), Commands (command), Services (service) and Options (options) All of these are in units of lines, and various signs are separated by spaces. C-style backslashes can be used to insert spaces between tokens. Double quotes can also be used to prevent a string from being split into multiple tokens by spaces. The backslash at the end of the line is used to wrap the line, and the comment line starts with a pound sign (#) (a space is allowed). ***It should be noted that this is only a grammar file, just like an xml file, without execution order, the parser obtains the desired data by reading this file, including service, action, etc.*** Actions and Services declare a new grouping Section. All commands or options belong to the most recently declared group. Commands or options before the first group will be ignored. Actions and Services have unique names. If there is a duplicate name, the second statement will be ignored as an error. ### Actions **Actions are the start of a series of commands** Actions represent some Actions. Actions represent a set of commands (Commands), and Actions have a trigger (trigger) that determines when to execute this Action, that is, under what circumstances can the defined command in the Action be executed. When some conditions meet the conditions of the trigger, the command defined in the Action will be added to the end of the command queue to be executed (if this group of commands is already in the queue, it will not be added again). Each action in the queue is extracted in turn, and each command in this action is executed in turn when an Action is removed from the queue. The format of Action is as follows: ``` on [&& ]* ... ``` On is followed by a trigger. When the trigger is triggered, command1, command2, and command3 will be executed in sequence until the next Action or the next Service. To put it simply, Actions is a startup script defined by Android at startup. When the conditions are met, the script will be executed. There are some commands in the script, and different scripts are distinguished by on. ###Triggers (Triggers) Trigger is the trigger we mentioned above, which is essentially a string that can match a certain event containing the string. Triggers are subdivided into event triggers and property triggers. Triggers (triggers) is a string used to match specific event types to make Actions happen. Event triggers can be triggered by the "trigger" command or via QueueEventTrigger() during the initialization process, usually some simple strings defined in advance, such as: boot, late-init Property trigger is triggered when the variable value of the specified property becomes the specified value, and its format is property:=* An Action can have multiple attribute triggers, but there is at most one event trigger. Let's look at two examples below: ``` on boot && property:a=b ``` This Action will only be triggered when the boot event occurs and the attributes a and b are equal. ``` on property:a=b && property:c=d ``` The Action will be triggered in the following three situations: -At startup, if the value of attribute a is equal to b and the value of attribute c is equal to d -When the value of attribute c is already d, the value of attribute a is updated to b -When the value of attribute a is already b, the value of attribute c is updated to d The following event triggers are commonly used in AIL: ``` Type Description ------------------------------------------------- Triggered after boot init.rc is loaded device-added- triggers when the specified device is added device-removed- triggers when the specified device is removed service-exited- is triggered when a specific service (service) exits Triggered before early-init initialization Triggered after late-init initialization Triggered when init is initialized (after /init.conf (startup configuration file) is loaded) ``` The trigger of Init is determined by the function action_for_each_trigger in init.c (called in the main function). ### Services A service is a program that starts with service and is started by the init process. Generally, it runs in another child process of init. Therefore, it is necessary to determine whether the corresponding executable file exists before starting the service. The sub-processes generated by init are defined in the rc file, and each service in it will generate sub-processes through the [fork](http://blog.csdn.net/jason314/article/details/5640969) method at startup. The form of Services is as follows: ``` service [ ]*

initrc

Android system init process startup and init.rc full analysis

Join Our Newsletter. No Spam, Only the good stuff.