Android init process analysis init script parsing and Processing

Android init process analysis init script parsing and Processing
(The lazy recently remembered that I still have csdn for a long time and I haven't taken care of it. This android init has been lying in my draft box for almost five years, And I want to change it a little.) RC file format

Rc files are common files executed during the startup and loading phases in linux. rc is short for run commands and can be understood as some column commands executed during the startup phase. When the android init process is started, the startup script file init. rc is also executed. The writing of init. rc is a little complicated. For details, refer to the readme file under/system/core/init. The script consists of four types:

Commands: Command action: action services: service options: Option

The syntax of this language includes the following conventions:

All types of statements are based on line-oriented. A statement contains several tokens, which are separated by space characters. If a token needs to contain space characters, it needs to be escaped by a backslash ('') in the C language style, or the entire token is caused by double quotation marks. The backslash can also appear at the end of a row, indicating that the content of the next row still belongs to the current statement. The line starting with '#' is a comment line (the comment can only be the first non-null character of the line. Please note that ). The Actions and Services statements implicitly indicate the beginning of a new section. All commands (commands) and options belong to the most recent section above. The commands (commands) and options before the first paragraph are invalid. Actions and Services have unique names. If duplicate names occur, the subsequent definition will be ignored as an error [ignore at present, not overwrite !].

In fact, strictly speaking, there should be only two types of Action and Service:

Action is composed of a bunch of commands under a specific trigger. Service is composed of a bunch of daemon Services described by options.

Action)

Action is a commands sequence with a name. Each Action defines a trigger to indicate when to execute the Action. In actual processing, when an event that matches the trigger of an action occurs, the commands under this action, will be added to the end of a queue to be executed (unless it is already in the queue ).
Each command in the queue is retrieved and executed in sequence.

An action is defined as follows:

 

on 
 
    
    
    
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Services)

Services are some programs that need to be started for initialization. Initialization programs may restart them after they exit. Services take a Service as follows:

 

service 
  
  
    [  ]*
   
     ...
  
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Options)

This option will affect the time and method of controlling the initialization program to run the service. Possible options are as follows (note that options is only a subsidiary of the Service )..

Note:

Disabled
The service is not automatically started when the class to which the service belongs is started. It is started only when it is explicitly specified that the service is to be started (usually every service belongs to a class, which is described by the class keyword)

Socket [ [ ]
Create a unix domain socket named/dev/socket/ And pass its fd to the launched process. Valid Values includedgram andstream. user andgroup default to 0.

User
Before exec starts this service, change the user of the process. The default user is root.

Group [ ] *
Before the exec cycle starts the service, the group of the service process is changed. The default group is root. By adding a service to a specific group, you can obtain certain permissions.

Capability [ ] +
Set linux capability before exec 'ing this service

Oneshot
The service is executed only once. For non-daemon programs, the onshot mode must be used.

Class
Set the class Name of the service. All services must be set. If this parameter is not set, the default class is used. Services in the same class can be started by running the class_start command.

 

Triggers)

A trigger is a string used to match specific events. These events trigger the execution of the Action of the trigger.

Command (Commands)

Which commands are supported? Different android versions are supported. For details, refer to readme in/system/core/init or the best code.

 

Properties)

The initialization program (Init) can modify system attributes as needed. In readme, there are three:
Init. action
Equal to the name of the action currently being executed or if none.

Init. command
Equal to the command being executed or if none.

Init. svc.
State of a named service (stopped, running, or restarting ).

The actual init process only updates init. svc. Each service will create such a property. You can use getprop | grep init. svc to view the status of each service, and the status will be updated at the time of status switch.

 

void notify_service_state(const char *name, const char *state){    char pname[PROP_NAME_MAX];    int len = strlen(name);    if ((len + 10) > PROP_NAME_MAX)        return;    snprintf(pname, sizeof(pname), init.svc.%s, name);    property_set(pname, state);}

 

 

 

 

 

 

The other two are meaningless and actually useless. It may have been designed at the beginning, but it is useless at the end (comman/action is executed at startup, and the duration is very short, which is not very useful ). Init parser

The Init parser is a simple automatic machine, and the code is not complicated. The main parser is three parts:

Service: The description and attributes of each service. parser is ready and placed in service_list for later startup through actions commands. Actions: Each parser action, on XXX and subsequent command, is an action. After the parser is completed, it is also placed in action_list for starting in init. Import: init. rc supports including other init. rc, this support is relatively simple, not equivalent to inserting the code to be imported at the import position, but in the main init. after all rc files are parser, parser will be included in the rc files in sequence.

 

Init. rc Script Command Execution

After the script is parsed, each Actions is pushed to action_queue in chronological order, and then executed one by one.
Actions is executed in sequence according to the trigger time. The default trigger order is as follows:

 action_for_each_trigger(early-init, action_add_queue_tail); action_for_each_trigger(init, action_add_queue_tail); action_for_each_trigger(early-fs, action_add_queue_tail); action_for_each_trigger(fs, action_add_queue_tail); action_for_each_trigger(post-fs, action_add_queue_tail); action_for_each_trigger(post-fs-data, action_add_queue_tail);  action_for_each_trigger(early-boot, action_add_queue_tail); action_for_each_trigger(boot, action_add_queue_tail); 

Therefore, each command requires special attention to handling dependencies. For example, in the init stage, it is impossible to access the data partition. In addition, note that in the same phase, the rc file for import is executed later (according to the parser sequence of the import file ).

The start time of the service. Note that it is also executed by the command in the action, for example, in the on boot phase:

 on boot  ...  class_start core

In this way, when this command is executed in the boot phase, all services that belong to the core category will be started one by one.

?

?? ?? ??