Android 系统相关学习笔记.zip

Android Init Language --------------------- The Android Init Language consists of five broad classes of statements: Actions, Commands, Services, Options, and Imports. All of these are line-oriented, consisting of tokens separated by whitespace. The c-style backslash escapes may be used to insert whitespace into a token. Double quotes may also be used to prevent whitespace from breaking text into multiple tokens. The backslash, when it is the last character on a line, may be used for line-folding. Lines which start with a `#` (leading whitespace allowed) are comments. System properties can be expanded using the syntax `${property.name}`. This also works in contexts where concatenation is required, such as `import /init.recovery.${ro.hardware}.rc`. Actions and Services implicitly declare a new section. All commands or options belong to the section most recently declared. Commands or options before the first section are ignored. Services have unique names. If a second Service is defined with the same name as an existing one, it is ignored and an error message is logged. Init .rc Files -------------- The init language is used in plain text files that take the .rc file extension. There are typically multiple of these in multiple locations on the system, described below. /init.rc is the primary .rc file and is loaded by the init executable at the beginning of its execution. It is responsible for the initial set up of the system. Init loads all of the files contained within the /{system,vendor,odm}/etc/init/ directories immediately after loading the primary /init.rc. This is explained in more details in the Imports section of this file. Legacy devices without the first stage mount mechanism previously were able to import init scripts during mount_all, however that is deprecated and not allowed for devices launching after Q. The intention of these directories is: 1. /system/etc/init/ is for core system items such as SurfaceFlinger, MediaService, and logd. 2. /vendor/etc/init/ is for SoC vendor items such as actions or daemons needed for core SoC functionality. 3. /odm/etc/init/ is for device manufacturer items such as actions or daemons needed for motion sensor or other peripheral functionality. All services whose binaries reside on the system, vendor, or odm partitions should have their service entries placed into a corresponding init .rc file, located in the /etc/init/ directory of the partition where they reside. There is a build system macro, LOCAL\_INIT\_RC, that handles this for developers. Each init .rc file should additionally contain any actions associated with its service. An example is the userdebug logcatd.rc and Android.mk files located in the system/core/logcat directory. The LOCAL\_INIT\_RC macro in the Android.mk file places logcatd.rc in /system/etc/init/ during the build process. Init loads logcatd.rc during the mount\_all command and allows the service to be run and the action to be queued when appropriate. This break up of init .rc files according to their daemon is preferred to the previously used monolithic init .rc files. This approach ensures that the only service entries that init reads and the only actions that init performs correspond to services whose binaries are in fact present on the file system, which was not the case with the monolithic init .rc files. This additionally will aid in merge conflict resolution when multiple services are added to the system, as each one will go into a separate file. Actions ------- Actions are named sequences of commands. Actions have a trigger which is used to determine when the action is executed. When an event occurs which matches an action's trigger, that action is added to the tail of a to-be-executed queue (unless it is already on the queue). Each action in the queue is dequeued in sequence and each command in that action is executed in sequence. Init handles other activities (device creation/destruction, property setting, process restarting) "between" the execution of the commands in activities. Actions take the form of: on <trigger> [&& <trigger>]* <command> <command> <command> Actions are added to the queue and executed based on the order that the file that contains them was parsed (see the Imports section), then sequentially within an individual file. For example if a file contains: on boot setprop a 1 setprop b 2 on boot && property:true=true setprop c 1 setprop d 2 on boot setprop e 1 setprop f 2 Then when the `boot` trigger occurs and assuming the property `true` equals `true`, then the order of the commands executed will be: setprop a 1 setprop b 2 setprop c 1 setprop d 2 setprop e 1 setprop f 2 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. They affect how and when init runs the service. `capabilities [ <capability>\* ]` > Set capabilities when exec'ing this service. 'capability' should be a Linux capability without the "CAP\_" prefix, like "NET\_ADMIN" or "SETPCAP". See http://man7.org/linux/man-pages/man7/capabilities.7.html for a list of Linux capabilities. If no capabilities are provided, then all capabilities are removed from this service, even if it runs as root. `class <name> [ <name>\* ]` > Specify class names for the service. All services in a named class may be started or stopped together. A service is in the class "default" if one is not specified via the class option. Additional classnames beyond the (required) first one are used to group services. The `animation` class should include all services necessary for both boot animation and shutdown animation. As these services can be launched very early during bootup and can run until the last stage of shutdown, access to /data partition is not guaranteed. These services can check files under /data but it should not keep files opened and should work when /data is not available. `console [<console>]` > This service needs a console. The optional second parameter chooses a specific console instead of the default. The default "/dev/console" can be changed by setting the "androidboot.console" kernel parameter. In all cases the leading "/dev/" should be omitted, so "/dev/tty0" would be specified as just "console tty0". This option connects stdin, stdout, and stderr to the console. It is mutually exclusive with the stdio_to_kmsg option, which only connects stdout and stderr to kmsg. `critical` > This is a device-critical service. If it exits more than four times in four minutes or before boot completes, the device will reboot into bootloader. `disabled` > This service will not automatically start with its class. It must be explicitly started by name or by interface name. `enter_namespace <type> <path>` > Enters the namespace of type _type_ located at _path_. Only network namespaces are supported with _type_ set to "net". Note that only one namespace of a given _type_ may be entered. `file <path> <type>` > Open a file path and pass its fd to the launched process. _type_ must be "r", "w" or "rw". For native executables see libcutils android\_get\_control\_file(). `group <groupname> [ <groupname>\* ]` > Change to 'groupname' before exec'ing this service. Additional groupnames beyond the (required) first one are used to set the supplemental groups of the process (via setgroups()). Currently defaults to root. (??? probably should default to nobody) `interface <interface name> <instance name>` > Associates this service with a list of the HIDL services that it provides. The interface name must be a fully-qualified name and not a value name. For instance, this is