Rc文件语法规则

解析init.rc脚本

Android Init Language

rc文件，是用Android Init Language编写的特殊文件。用这种语法编写的文件，统一用”.rc”后缀

它的语法说明可以在aosp源码system/core/init/README.md中找到:

system/core/init/README.md原文：

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.

`/system/etc/init/hw/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,system_ext,vendor,odm,product}/etc/init/` directories immediately after loading
the primary `/system/etc/init/hw/init.rc`.  This is explained in more details in the
[Imports](#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.

Versioned RC files within APEXs
-------------------------------

With the arrival of mainline on Android Q, the individual mainline
modules carry their own init.rc files within their boundaries. Init
processes these files according to the naming pattern `/apex/*/etc/*rc`.

Because APEX modules must run on more than one release of Android,
they may require different parameters as part of the services they
define. This is achieved, starting in Android T, by incorporating
the SDK version information in the name of the init file.  The suffix
is changed from `.rc` to `.#rc` where # is the first SDK where that
RC file is accepted. An init file specific to SDK=31 might be named
`init.31rc`. With this scheme, an APEX may include multiple init files. An
example is appropriate.

For an APEX module with the following files in /apex/sample-module/apex/etc/:

   1. init.rc
   2. init.32rc
   4. init.35rc

The selection rule chooses the highest `.#rc` value that does not
exceed the SDK of the currently running system. The unadorned `.rc`
is interpreted as sdk=0.

When this APEX is installed on a device with SDK <=31, the system will
process init.rc.  When installed on a device running SDK 32, 33, or 34,
it will use init.32rc.  When installed on a device running SDKs >= 35,
it will choose init.35rc

This versioning scheme is used only for the init files within APEX
modules; it does not apply to the init files stored in /system/etc/init,
/vendor/etc/init, or other directories.

This naming scheme is available after Android S.

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 [window=<fatal crash window mins>] [target=<fatal reboot target>]`
> This is a device-critical service. If it exits more than four times in
  _fatal crash window mins_ minutes or before boot completes, the device
  will reboot into _fatal reboot target_.
  The default value of _fatal crash window mins_ is 4, and default value
  of _fatal reboot target_ is 'bootloader'.
  For tests, the fatal reboot can be skipped by setting property
  `init.svc_debug.no_fatal.<service-name>` to `true` for specified critical service.

`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 AIDL or HIDL services that it provides. The interface
  name must be a fully-qualified name and not a value name. For instance, this is used to allow
  servicemanager or hwservicemanager to lazily start services. When multiple interfaces are served,
  this tag should be used multiple times. An example of an entry for a HIDL
  interface is `interface vendor.foo.bar@1.0::IBaz default`. For an AIDL interface, use
  `interface aidl <instance name>`. The instance name for an AIDL interface is
  whatever is registered with servicemanager, and these can be listed with `adb
  shell dumpsys -l`.

`ioprio <class> <priority>`
> Sets the IO priority and IO priority class for this service via the SYS_ioprio_set syscall.
  _class_ must be one of "rt", "be", or "idle". _priority_ must be an integer in the range 0 - 7.

`keycodes <keycode> [ <keycode>\* ]`
> Sets the keycodes that will trigger this service. If all of the keys corresponding to the passed
  keycodes are pressed at once, the service will start. This is typically used to start the
  bugreport service.

> This option may take a property instead of a list of keycodes. In this case, only one option is
  provided: the property name in the typical property expansion format. The property must contain
  a comma separated list of keycode values or the text 'none' to indicate that
  this service does not respond to keycodes.

> For example, `keycodes ${some.property.name:-none}` where some.property.name expands
  to "123,124,125". Since keycodes are handled very early in init,
  only PRODUCT_DEFAULT_PROPERTY_OVERRIDES properties can be used.

`memcg.limit_in_bytes <value>` and `memcg.limit_percent <value>`
> Sets the child's memory.limit_in_bytes to the minimum of `limit_in_bytes`
  bytes and `limit_percent` which is interpreted as a percentage of the size
  of the device's physical memory (only if memcg is mounted).
  Values must be equal or greater than 0.

`memcg.limit_property <value>`
> Sets the child's memory.limit_in_bytes to the value of the specified property
  (only if memcg is mounted). This property will override the values specified
  via `memcg.limit_in_bytes` and `memcg.limit_percent`.

`memcg.soft_limit_in_bytes <value>`
> Sets the child's memory.soft_limit_in_bytes to the specified value (only if memcg is mounted),
  which must be equal or greater than 0.

`memcg.swappiness <value>`
> Sets the child's memory.swappiness to the specified value (only if memcg is mounted),
  which must be equal or greater than 0.

`namespace <pid|mnt>`
> Enter a new PID or mount namespace when forking the service.

`oneshot`
> Do not restart the service when it exits.

`onrestart`
> Execute a Command (see below) when service restarts.

`oom_score_adjust <value>`
> Sets the child's /proc/self/oom\_score\_adj to the specified value,
  which must range from -1000 to 1000.

`override`
> Indicates that this service definition is meant to override a previous definition for a service
  with the same name. This is typically meant for services on /odm to override those defined on
  /vendor. The last service definition that init parses with this keyword is the service definition
  will use for this service. Pay close attention to the order in which init.rc files are parsed,
  since it has some peculiarities for backwards compatibility reasons. The 'imports' section of
  this file has more details on the order.

`priority <priority>`
> Scheduling priority of the service process. This value has to be in range
  -20 to 19. Default priority is 0. Priority is set via setpriority().

`reboot_on_failure <target>`
> If this process cannot be started or if the process terminates with an exit code other than
  CLD_EXITED or an status other than '0', reboot the system with the target specified in
  _target_. _target_ takes the same format as the parameter to sys.powerctl. This is particularly
  intended to be used with the `exec_start` builtin for any must-have checks during boot.

`restart_period <seconds>`
> If a non-oneshot service exits, it will be restarted at its start time plus
  this period. It defaults to 5s to rate limit crashing services.
  This can be increased for services that are meant to run periodically. For
  example, it may be set to 3600 to indicate that the service should run every hour
  or 86400 to indicate that the service should run every day.

`rlimit <resource> <cur> <max>`
> This applies the given rlimit to the service. rlimits are inherited by child
  processes, so this effectively applies the given rlimit to the process tree
  started by this service.
  It is parsed similarly to the setrlimit command specified below.

`seclabel <seclabel>`
> Change to 'seclabel' before exec'ing this service.
  Primarily for use by services run from the rootfs, e.g. ueventd, adbd.
  Services on the system partition can instead use policy-defined transitions
  based on their file security context.
  If not specified and no transition is defined in policy, defaults to the init context.

`setenv <name> <value>`
> Set the environment variable _name_ to _value_ in the launched process.

`shutdown <shutdown_behavior>`
> Set shutdown behavior of the service process. When this is not specified,
  the service is killed during shutdown process by using SIGTERM and SIGKILL.
  The service with shutdown_behavior of "critical" is not killed during shutdown
  until shutdown times out. When shutdown times out, even services tagged with
  "shutdown critical" will be killed. When the service tagged with "shutdown critical"
  is not running when shut down starts, it will be started.

`sigstop`
> Send SIGSTOP to the service immediately before exec is called. This is intended for debugging.
  See the below section on debugging for how this can be used.

`socket <name> <type> <perm> [ <user> [ <group> [ <seclabel> ] ] ]`
> Create a UNIX domain socket named /dev/socket/_name_ and pass its fd to the
  launched process.  _type_ must be "dgram", "stream" or "seqpacket".  _type_
  may end with "+passcred" to enable SO_PASSCRED on the socket. User and
  group default to 0.  'seclabel' is the SELinux security context for the
  socket.  It defaults to the service security context, as specified by
  seclabel or computed based on the service executable file security context.
  For native executables see libcutils android\_get\_control\_socket().

`stdio_to_kmsg`
> Redirect stdout and stderr to /dev/kmsg_debug. This is useful for services that do not use native
  Android logging during early boot and whose logs messages we want to capture. This is only enabled
  when /dev/kmsg_debug is enabled, which is only enabled on userdebug and eng builds.
  This is mutually exclusive with the console option, which additionally connects stdin to the
  given console.

`task_profiles <profile> [ <profile>\* ]`
> Set task profiles for the process when it forks. This is designed to replace the use of
  writepid option for moving a process into a cgroup.

`timeout_period <seconds>`
> Provide a timeout after which point the service will be killed. The oneshot keyword is respected
  here, so oneshot services do not automatically restart, however all other services will.
  This is particularly useful for creating a periodic service combined with the restart_period
  option described above.

`updatable`
> Mark that the service can be overridden (via the 'override' option) later in
  the boot sequence by APEXes. When a service with updatable option is started
  before APEXes are all activated, the execution is delayed until the activation
  is finished. A service that is not marked as updatable cannot be overridden by
  APEXes.

`user <username>`
> Change to 'username' before exec'ing this service.
  Currently defaults to root.  (??? probably should default to nobody)
  As of Android M, processes should use this option even if they
  require Linux capabilities.  Previously, to acquire Linux
  capabilities, a process would need to run as root, request the
  capabilities, then drop to its desired uid.  There is a new
  mechanism through fs\_config that allows device manufacturers to add
  Linux capabilities to specific binaries on a file system that should
  be used instead. This mechanism is described on
  <http://source.android.com/devices/tech/config/filesystem.html>.  When
  using this new mechanism, processes can use the user option to
  select their desired uid without ever running as root.
  As of Android O, processes can also request capabilities directly in their .rc
  files. See the "capabilities" option below.

`writepid <file> [ <file>\* ]`
> Write the child's pid to the given files when it forks. Meant for
  cgroup/cpuset usage. If no files under /dev/cpuset/ are specified, but the
  system property 'ro.cpuset.default' is set to a non-empty cpuset name (e.g.
  '/foreground'), then the pid is written to file /dev/cpuset/_cpuset\_name_/tasks.
  The use of this option for moving a process into a cgroup is obsolete. Please
  use task_profiles option instead.


Triggers
--------
Triggers are strings which can be used to match certain kinds of
events and used to cause an action to occur.

Triggers are subdivided into event triggers and property triggers.

Event triggers are strings triggered by the 'trigger' command or by
the QueueEventTrigger() function within the init executable.  These
take the form of a simple string such as 'boot' or 'late-init'.

Property triggers are strings triggered when a named property changes
value to a given new value or when a named property changes value to
any new value.  These take the form of 'property:<name>=<value>' and
'property:<name>=\*' respectively.  Property triggers are additionally
evaluated and triggered accordingly during the initial boot phase of
init.

An Action can have multiple property triggers but may only have one
event trigger.

For example:
`on boot && property:a=b` defines an action that is only executed when
the 'boot' event trigger happens and the property a equals b.

`on property:a=b && property:c=d` defines an action that is executed
at three times:

   1. During initial boot if property a=b and property c=d.
   2. Any time that property a transitions to value b, while property c already equals d.
   3. Any time that property c transitions to value d, while property a already equals b.


Trigger Sequence
----------------

Init uses the following sequence of triggers during early boot. These are the
built-in triggers defined in init.cpp.

   1. `early-init` - The first in the sequence, triggered after cgroups has been configured
      but before ueventd's coldboot is complete.
   2. `init` - Triggered after coldboot is complete.
   3. `charger` - Triggered if `ro.bootmode == "charger"`.
   4. `late-init` - Triggered if `ro.bootmode != "charger"`, or via healthd triggering a boot
      from charging mode.

Remaining triggers are configured in `init.rc` and are not built-in. The default sequence for
these is specified under the "on late-init" event in `init.rc`. Actions internal to `init.rc`
have been omitted.

   1. `early-fs` - Start vold.
   2. `fs` - Vold is up. Mount partitions not marked as first-stage or latemounted.
   3. `post-fs` - Configure anything dependent on early mounts.
   4. `late-fs` - Mount partitions marked as latemounted.
   5. `post-fs-data` - Mount and configure `/data`; set up encryption. `/metadata` is
      reformatted here if it couldn't mount in first-stage init.
   6. `zygote-start` - Start the zygote.
   7. `early-boot` - After zygote has started.
   8. `boot` - After `early-boot` actions have completed.

Commands
--------

`bootchart [start|stop]`
> Start/stop bootcharting. These are present in the default init.rc files,
  but bootcharting is only active if the file /data/bootchart/enabled exists;
  otherwise bootchart start/stop are no-ops.

`chmod <octal-mode> <path>`
> Change file access permissions.

`chown <owner> <group> <path>`
> Change file owner and group.

`class_start <serviceclass>`
> Start all services of the specified class if they are
  not already running.  See the start entry for more information on
  starting services.

`class_stop <serviceclass>`
> Stop and disable all services of the specified class if they are
  currently running.

`class_reset <serviceclass>`
> Stop all services of the specified class if they are
  currently running, without disabling them. They can be restarted
  later using `class_start`.

`class_restart [--only-enabled] <serviceclass>`
> Restarts all services of the specified class. If `--only-enabled` is
  specified, then disabled services are skipped.

`copy <src> <dst>`
> Copies a file. Similar to write, but useful for binary/large
  amounts of data.
  Regarding to the src file, copying from symbolic link file and world-writable
  or group-writable files are not allowed.
  Regarding to the dst file, the default mode created is 0600 if it does not
  exist. And it will be truncated if dst file is a normal regular file and
  already exists.

`copy_per_line <src> <dst>`
> Copies a file line by line. Similar to copy, but useful for dst is a sysfs node
  that doesn't handle multiple lines of data.

`domainname <name>`
> Set the domain name.

`enable <servicename>`
> Turns a disabled service into an enabled one as if the service did not
  specify disabled.
  If the service is supposed to be running, it will be started now.
  Typically used when the bootloader sets a variable that indicates a specific
  service should be started when needed. E.g.

    on property:ro.boot.myfancyhardware=1
        enable my_fancy_service_for_my_fancy_hardware

`exec [ <seclabel> [ <user> [ <group>\* ] ] ] -- <command> [ <argument>\* ]`
> Fork and execute command with the given arguments. The command starts
  after "--" so that an optional security context, user, and supplementary
  groups can be provided. No other commands will be run until this one
  finishes. _seclabel_ can be a - to denote default. Properties are expanded
  within _argument_.
  Init halts executing commands until the forked process exits.

`exec_background [ <seclabel> [ <user> [ <group>\* ] ] ] -- <command> [ <argument>\* ]`
> Fork and execute command with the given arguments. This is handled similarly
  to the `exec` command. The difference is that init does not halt executing
  commands until the process exits for `exec_background`.

`exec_start <service>`
> Start a given service and halt the processing of additional init commands
  until it returns.  The command functions similarly to the `exec` command,
  but uses an existing service definition in place of the exec argument vector.

`export <name> <value>`
> Set the environment variable _name_ equal to _value_ in the
  global environment (which will be inherited by all processes
  started after this command is executed)

`hostname <name>`
> Set the host name.

`ifup <interface>`
> Bring the network interface _interface_ online.

`insmod [-f] <path> [<options>]`
> Install the module at _path_ with the specified options.
  -f: force installation of the module even if the version of the running kernel
  and the version of the kernel for which the module was compiled do not match.

`interface_start <name>` \
`interface_restart <name>` \
`interface_stop <name>`
> Find the service that provides the interface _name_ if it exists and run the `start`, `restart`,
or `stop` commands on it respectively.  _name_ may be either a fully qualified HIDL name, in which
case it is specified as `<interface>/<instance>`, or an AIDL name, in which case it is specified as
`aidl/<interface>` for example `android.hardware.secure_element@1.1::ISecureElement/eSE1` or
`aidl/aidl_lazy_test_1`.

> Note that these commands only act on interfaces specified by the `interface` service option, not
on interfaces registered at runtime.

> Example usage of these commands: \
`interface_start android.hardware.secure_element@1.1::ISecureElement/eSE1`
will start the HIDL Service that provides the `android.hardware.secure_element@1.1` and `eSI1`
instance. \
`interface_start aidl/aidl_lazy_test_1` will start the AIDL service that
provides the `aidl_lazy_test_1` interface.

`load_exports <path>`
> Open the file at _path_ and export global environment variables declared
  there. Each line must be in the format `export <name> <value>`, as described
  above.

`load_system_props`
> (This action is deprecated and no-op.)

`load_persist_props`
> Loads persistent properties when /data has been decrypted.
  This is included in the default init.rc.

`loglevel <level>`
> Sets init's log level to the integer level, from 7 (all logging) to 0
  (fatal logging only). The numeric values correspond to the kernel log
  levels, but this command does not affect the kernel log level. Use the
  `write` command to write to `/proc/sys/kernel/printk` to change that.
  Properties are expanded within _level_.

`mark_post_data`
> Used to mark the point right after /data is mounted.

`mkdir <path> [<mode>] [<owner>] [<group>] [encryption=<action>] [key=<key>]`
> Create a directory at _path_, optionally with the given mode, owner, and
  group. If not provided, the directory is created with permissions 755 and
  owned by the root user and root group. If provided, the mode, owner and group
  will be updated if the directory exists already.

 > _action_ can be one of:
  * `None`: take no encryption action; directory will be encrypted if parent is.
  * `Require`: encrypt directory, abort boot process if encryption fails
  * `Attempt`: try to set an encryption policy, but continue if it fails
  * `DeleteIfNecessary`: recursively delete directory if necessary to set
  encryption policy.

  > _key_ can be one of:
  * `ref`: use the systemwide DE key
  * `per_boot_ref`: use the key freshly generated on each boot.

`mount_all [ <fstab> ] [--<option>]`
> Calls fs\_mgr\_mount\_all on the given fs\_mgr-format fstab with optional
  options "early" and "late".
  With "--early" set, the init executable will skip mounting entries with
  "latemount" flag and triggering fs encryption state event. With "--late" set,
  init executable will only mount entries with "latemount" flag. By default,
  no option is set, and mount\_all will process all entries in the given fstab.
  If the fstab parameter is not specified, fstab.${ro.boot.fstab_suffix},
  fstab.${ro.hardware} or fstab.${ro.hardware.platform} will be scanned for
  under /odm/etc, /vendor/etc, or / at runtime, in that order.

`mount <type> <device> <dir> [ <flag>\* ] [<options>]`
> Attempt to mount the named device at the directory _dir_
  _flag_s include "ro", "rw", "remount", "noatime", ...
  _options_ include "barrier=1", "noauto\_da\_alloc", "discard", ... as
  a comma separated string, e.g. barrier=1,noauto\_da\_alloc

`perform_apex_config`
> Performs tasks after APEXes are mounted. For example, creates data directories
  for the mounted APEXes, parses config file(s) from them, and updates linker
  configurations. Intended to be used only once when apexd notifies the mount
  event by setting `apexd.status` to ready.

`restart [--only-if-running] <service>`
> Stops and restarts a running service, does nothing if the service is currently
  restarting, otherwise, it just starts the service. If "--only-if-running" is
  specified, the service is only restarted if it is already running.

`restorecon <path> [ <path>\* ]`
> Restore the file named by _path_ to the security context specified
  in the file\_contexts configuration.
  Not required for directories created by the init.rc as these are
  automatically labeled correctly by init.

`restorecon_recursive <path> [ <path>\* ]`
> Recursively restore the directory tree named by _path_ to the
  security contexts specified in the file\_contexts configuration.

`rm <path>`
> Calls unlink(2) on the given path. You might want to
  use "exec -- rm ..." instead (provided the system partition is
  already mounted).

`rmdir <path>`
> Calls rmdir(2) on the given path.

`readahead <file|dir> [--fully]`
> Calls readahead(2) on the file or files within given directory.
  Use option --fully to read the full file content.

`setprop <name> <value>`
> Set system property _name_ to _value_. Properties are expanded
  within _value_.

`setrlimit <resource> <cur> <max>`
> Set the rlimit for a resource. This applies to all processes launched after
  the limit is set. It is intended to be set early in init and applied globally.
  _resource_ is best specified using its text representation ('cpu', 'rtio', etc
  or 'RLIM_CPU', 'RLIM_RTIO', etc). It also may be specified as the int value
  that the resource enum corresponds to.
  _cur_ and _max_ can be 'unlimited' or '-1' to indicate an infinite rlimit.

`start <service>`
> Start a service running if it is not already running.
  Note that this is _not_ synchronous, and even if it were, there is
  no guarantee that the operating system's scheduler will execute the
  service sufficiently to guarantee anything about the service's status.
  See the `exec_start` command for a synchronous version of `start`.

> This creates an important consequence that if the service offers
  functionality to other services, such as providing a
  communication channel, simply starting this service before those
  services is _not_ sufficient to guarantee that the channel has
  been set up before those services ask for it.  There must be a
  separate mechanism to make any such guarantees.

`stop <service>`
> Stop a service from running if it is currently running.

`swapon_all [ <fstab> ]`
> Calls fs\_mgr\_swapon\_all on the given fstab file.
  If the fstab parameter is not specified, fstab.${ro.boot.fstab_suffix},
  fstab.${ro.hardware} or fstab.${ro.hardware.platform} will be scanned for
  under /odm/etc, /vendor/etc, or / at runtime, in that order.

`symlink <target> <path>`
> Create a symbolic link at _path_ with the value _target_

`sysclktz <minutes_west_of_gmt>`
> Set the system clock base (0 if system clock ticks in GMT)

`trigger <event>`
> Trigger an event.  Used to queue an action from another
  action.

`umount <path>`
> Unmount the filesystem mounted at that path.

`umount_all [ <fstab> ]`
> Calls fs\_mgr\_umount\_all on the given fstab file.
  If the fstab parameter is not specified, fstab.${ro.boot.fstab_suffix},
  fstab.${ro.hardware} or fstab.${ro.hardware.platform} will be scanned for
  under /odm/etc, /vendor/etc, or / at runtime, in that order.

`verity_update_state`
> Internal implementation detail used to update dm-verity state and
  set the partition._mount-point_.verified properties used by adb remount
  because fs\_mgr can't set them directly itself. This is required since
  Android 12, because CtsNativeVerifiedBootTestCases will read property
  "partition.${partition}.verified.hash_alg" to check that sha1 is not used.
  See https://r.android.com/1546980 for more details.

`wait <path> [ <timeout> ]`
> Poll for the existence of the given file and return when found,
  or the timeout has been reached. If timeout is not specified it
  currently defaults to five seconds. The timeout value can be
  fractional seconds, specified in floating point notation.

`wait_for_prop <name> <value>`
> Wait for system property _name_ to be _value_. Properties are expanded
  within _value_. If property _name_ is already set to _value_, continue
  immediately.

`write <path> <content>`
> Open the file at _path_ and write a string to it with write(2).
  If the file does not exist, it will be created. If it does exist,
  it will be truncated. Properties are expanded within _content_.


Imports
-------
`import <path>`
> Parse an init config file, extending the current configuration.
  If _path_ is a directory, each file in the directory is parsed as
  a config file. It is not recursive, nested directories will
  not be parsed.

The import keyword is not a command, but rather its own section,
meaning that it does not happen as part of an Action, but rather,
imports are handled as a file is being parsed and follow the below logic.

There are only three times where the init executable imports .rc files:

   1. When it imports `/system/etc/init/hw/init.rc` or the script indicated by the property
      `ro.boot.init_rc` during initial boot.
   2. When it imports `/{system,system_ext,vendor,odm,product}/etc/init/` immediately after
      importing `/system/etc/init/hw/init.rc`.
   3. (Deprecated) When it imports /{system,vendor,odm}/etc/init/ or .rc files
      at specified paths during mount_all, not allowed for devices launching
      after Q.

The order that files are imported is a bit complex for legacy reasons.  The below is guaranteed:

1. `/system/etc/init/hw/init.rc` is parsed then recursively each of its imports are
   parsed.
2. The contents of `/system/etc/init/` are alphabetized and parsed sequentially, with imports
   happening recursively after each file is parsed.
3. Step 2 is repeated for `/system_ext/etc/init`, `/vendor/etc/init`, `/odm/etc/init`,
   `/product/etc/init`

The below pseudocode may explain this more clearly:

    fn Import(file)
      Parse(file)
      for (import : file.imports)
        Import(import)

    Import(/system/etc/init/hw/init.rc)
    Directories = [/system/etc/init, /system_ext/etc/init, /vendor/etc/init, /odm/etc/init, /product/etc/init]
    for (directory : Directories)
      files = <Alphabetical order of directory's contents>
      for (file : files)
        Import(file)

Actions are executed in the order that they are parsed.  For example the `post-fs-data` action(s)
in `/system/etc/init/hw/init.rc` are always the first `post-fs-data` action(s) to be executed in
order of how they appear in that file.  Then the `post-fs-data` actions of the imports of
`/system/etc/init/hw/init.rc` in the order that they're imported, etc.

Properties
----------
Init provides state information with the following properties.

`init.svc.<name>`
> State of a named service ("stopped", "stopping", "running", "restarting")

`dev.mnt.dev.<mount_point>`, `dev.mnt.blk.<mount_point>`, `dev.mnt.rootdisk.<mount_point>`
> Block device base name associated with a *mount_point*.
  The *mount_point* has / replaced by . and if referencing the root mount point
  "/", it will use "/root".
  `dev.mnt.dev.<mount_point>` indicates a block device attached to filesystems.
    (e.g., dm-N or sdaN/mmcblk0pN to access `/sys/fs/ext4/${dev.mnt.dev.<mount_point>}/`)

  `dev.mnt.blk.<mount_point>` indicates the disk partition to the above block device.
    (e.g., sdaN / mmcblk0pN to access `/sys/class/block/${dev.mnt.blk.<mount_point>}/`)

  `dev.mnt.rootdisk.<mount_point>` indicates the root disk to contain the above disk partition.
    (e.g., sda / mmcblk0 to access `/sys/class/block/${dev.mnt.rootdisk.<mount_point>}/queue`)

Init responds to properties that begin with `ctl.`.  These properties take the format of
`ctl.[<target>_]<command>` and the _value_ of the system property is used as a parameter.  The
_target_ is optional and specifies the service option that _value_ is meant to match with.  There is
only one option for _target_, `interface` which indicates that _value_ will refer to an interface
that a service provides and not the service name itself.

For example:

`SetProperty("ctl.start", "logd")` will run the `start` command on `logd`.

`SetProperty("ctl.interface_start", "aidl/aidl_lazy_test_1")` will run the `start` command on the
service that exposes the `aidl aidl_lazy_test_1` interface.

Note that these
properties are only settable; they will have no value when read.

The _commands_ are listed below.

`start` \
`restart` \
`stop` \
These are equivalent to using the `start`, `restart`, and `stop` commands on the service specified
by the _value_ of the property.

`oneshot_on` and `oneshot_off` will turn on or off the _oneshot_
flag for the service specified by the _value_ of the property.  This is
particularly intended for services that are conditionally lazy HALs.  When
they are lazy HALs, oneshot must be on, otherwise oneshot should be off.

`sigstop_on` and `sigstop_off` will turn on or off the _sigstop_ feature for the service
specified by the _value_ of the property.  See the _Debugging init_ section below for more details
about this feature.

Boot timing
-----------
Init records some boot timing information in system properties.

`ro.boottime.init`
> Time after boot in ns (via the CLOCK\_BOOTTIME clock) at which the first
  stage of init started.

`ro.boottime.init.first_stage`
> How long in ns it took to run first stage.

`ro.boottime.init.selinux`
> How long in ns it took to run SELinux stage.

`ro.boottime.init.modules`
> How long in ms it took to load kernel modules.

`ro.boottime.init.cold_boot_wait`
> How long init waited for ueventd's coldboot phase to end.

`ro.boottime.<service-name>`
> Time after boot in ns (via the CLOCK\_BOOTTIME clock) that the service was
  first started.


Bootcharting
------------
This version of init contains code to perform "bootcharting": generating log
files that can be later processed by the tools provided by <http://www.bootchart.org/>.

On the emulator, use the -bootchart _timeout_ option to boot with bootcharting
activated for _timeout_ seconds.

On a device:

    adb shell 'touch /data/bootchart/enabled'

Don't forget to delete this file when you're done collecting data!

The log files are written to /data/bootchart/. A script is provided to
retrieve them and create a bootchart.tgz file that can be used with the
bootchart command-line utility:

    sudo apt-get install pybootchartgui
    # grab-bootchart.sh uses $ANDROID_SERIAL.
    $ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh

One thing to watch for is that the bootchart will show init as if it started
running at 0s. You'll have to look at dmesg to work out when the kernel
actually started init.


Comparing two bootcharts
------------------------
A handy script named compare-bootcharts.py can be used to compare the
start/end time of selected processes. The aforementioned grab-bootchart.sh
will leave a bootchart tarball named bootchart.tgz at /tmp/android-bootchart.
If two such tarballs are preserved on the host machine under different
directories, the script can list the timestamps differences. For example:

Usage: system/core/init/compare-bootcharts.py _base-bootchart-dir_ _exp-bootchart-dir_

    process: baseline experiment (delta) - Unit is ms (a jiffy is 10 ms on the system)
    ------------------------------------
    /init: 50 40 (-10)
    /system/bin/surfaceflinger: 4320 4470 (+150)
    /system/bin/bootanimation: 6980 6990 (+10)
    zygote64: 10410 10640 (+230)
    zygote: 10410 10640 (+230)
    system_server: 15350 15150 (-200)
    bootanimation ends at: 33790 31230 (-2560)


Systrace
--------
Systrace (<http://developer.android.com/tools/help/systrace.html>) can be
used for obtaining performance analysis reports during boot
time on userdebug or eng builds.

Here is an example of trace events of "wm" and "am" categories:

    $ANDROID_BUILD_TOP/external/chromium-trace/systrace.py \
          wm am --boot

This command will cause the device to reboot. After the device is rebooted and
the boot sequence has finished, the trace report is obtained from the device
and written as trace.html on the host by hitting Ctrl+C.

Limitation: recording trace events is started after persistent properties are loaded, so
the trace events that are emitted before that are not recorded. Several
services such as vold, surfaceflinger, and servicemanager are affected by this
limitation since they are started before persistent properties are loaded.
Zygote initialization and the processes that are forked from the zygote are not
affected.


Debugging init
--------------
When a service starts from init, it may fail to `execv()` the service. This is not typical, and may
point to an error happening in the linker as the new service is started. The linker in Android
prints its logs to `logd` and `stderr`, so they are visible in `logcat`. If the error is encountered
before it is possible to access `logcat`, the `stdio_to_kmsg` service option may be used to direct
the logs that the linker prints to `stderr` to `kmsg`, where they can be read via a serial port.

Launching init services without init is not recommended as init sets up a significant amount of
environment (user, groups, security label, capabilities, etc) that is hard to replicate manually.

If it is required to debug a service from its very start, the `sigstop` service option is added.
This option will send SIGSTOP to a service immediately before calling exec. This gives a window
where developers can attach a debugger, strace, etc before continuing the service with SIGCONT.

This flag can also be dynamically controlled via the ctl.sigstop_on and ctl.sigstop_off properties.

Below is an example of dynamically debugging logd via the above:

    stop logd
    setprop ctl.sigstop_on logd
    start logd
    ps -e | grep logd
    > logd          4343     1   18156   1684 do_signal_stop 538280 T init
    gdbclient.py -p 4343
    b main
    c
    c
    c
    > Breakpoint 1, main (argc=1, argv=0x7ff8c9a488) at system/core/logd/main.cpp:427

Below is an example of doing the same but with strace

    stop logd
    setprop ctl.sigstop_on logd
    start logd
    ps -e | grep logd
    > logd          4343     1   18156   1684 do_signal_stop 538280 T init
    strace -p 4343

    (From a different shell)
    kill -SIGCONT 4343

    > strace runs

Host Init Script Verification
-----------------------------

Init scripts are checked for correctness during build time. Specifically the below is checked.

1) Well formatted action, service and import sections, e.g. no actions without a preceding 'on'
line, and no extraneous lines after an 'import' statement.
2) All commands map to a valid keyword and the argument count is within the correct range.
3) All service options are valid. This is stricter than how commands are checked as the service
options' arguments are fully parsed, e.g. UIDs and GIDs must resolve.

There are other parts of init scripts that are only parsed at runtime and therefore not checked
during build time, among them are the below.

1) The validity of the arguments of commands, e.g. no checking if file paths actually exist, if
SELinux would permit the operation, or if the UIDs and GIDs resolve.
2) No checking if a service exists or has a valid SELinux domain defined
3) No checking if a service has not been previously defined in a different init script.

Early Init Boot Sequence
------------------------
The early init boot sequence is broken up into three stages: first stage init, SELinux setup, and
second stage init.

First stage init is responsible for setting up the bare minimum requirements to load the rest of the
system. Specifically this includes mounting /dev, /proc, mounting 'early mount' partitions (which
needs to include all partitions that contain system code, for example system and vendor), and moving
the system.img mount to / for devices with a ramdisk.

Note that in Android Q, system.img always contains TARGET_ROOT_OUT and always is mounted at / by the
time first stage init finishes. Android Q will also require dynamic partitions and therefore will
require using a ramdisk to boot Android. The recovery ramdisk can be used to boot to Android instead
of a dedicated ramdisk as well.

First stage init has three variations depending on the device configuration:
1) For system-as-root devices, first stage init is part of /system/bin/init and a symlink at /init
points to /system/bin/init for backwards compatibility. These devices do not need to do anything to
mount system.img, since it is by definition already mounted as the rootfs by the kernel.

2) For devices with a ramdisk, first stage init is a static executable located at /init. These
devices mount system.img as /system then perform a switch root operation to move the mount at
/system to /. The contents of the ramdisk are freed after mounting has completed.

3) For devices that use recovery as a ramdisk, first stage init it contained within the shared init
located at /init within the recovery ramdisk. These devices first switch root to
/first_stage_ramdisk to remove the recovery components from the environment, then proceed the same
as 2). Note that the decision to boot normally into Android instead of booting
into recovery mode is made if androidboot.force_normal_boot=1 is present in the
kernel commandline, or in bootconfig with Android S and later.

Once first stage init finishes it execs /system/bin/init with the "selinux_setup" argument. This
phase is where SELinux is optionally compiled and loaded onto the system. selinux.cpp contains more
information on the specifics of this process.

Lastly once that phase finishes, it execs /system/bin/init again with the "second_stage"
argument. At this point the main phase of init runs and continues the boot process via the init.rc
scripts.

chatgpt译文：

Android Init Language
---------------------

Android Init语言由五个宽泛的语句类别组成：Actions（动作）、Commands（命令）、Services（服务）、Options（选项）和
Imports（导入）。

所有这些语句以行为单位，由空格分隔的标记组成。可以使用C风格的反斜杠转义将空格插入标记中。双引号也可以用于防止空格破坏文本形成
多个标记。当反斜杠是行末字符时，可以用于行折叠。

以`#`开头的行（允许前置空格）是注释。

可以使用`${property.name}`的语法扩展系统属性。这在需要连接的上下文中也适用，例如`import /init.recovery.${ro.hardware}.rc`。

Actions和Services隐式声明了一个新的区块。所有的命令或选项都属于最近声明的区块。在第一个区块之前的命令或选项将被忽略。

Services具有唯一的名称。如果定义了第二个名称与现有Service相同的Service，则会被忽略并记录错误消息。

Init .rc文件
--------------

Init语言用于采用.rc文件扩展的纯文本文件中。通常在系统中有多个这样的文件，如下所述。

`/system/etc/init/hw/init.rc`是主要的.rc文件，由init可执行文件在其启动时加载。它负责系统的初始设置。

在加载主要的`/system/etc/init/hw/init.rc`之后，Init会立即加载`/{system,system_ext,vendor,odm,product}/etc/init/`目录
中包含的所有文件。这在本文件的[Imports](#imports)部分中有更详细的解释。

在Q之后启动的设备不再支持在mount_all期间导入init脚本。

这些目录的目的是：

   1. /system/etc/init/ 用于核心系统项，如SurfaceFlinger、MediaService和logd。
   2. /vendor/etc/init/ 用于SoC供应商项，如用于核心SoC功能的动作或守护进程。
   3. /odm/etc/init/ 用于设备制造商项，如用于运动传感器或其他外围设备功能的动作或守护进程。

所有二进制文件位于系统、供应商或odm分区的服务应将其服务条目放置在相应的init .rc文件中，位于它们所在分区的/etc/init/目录中。
开发人员可以使用构建系统宏LOCAL_INIT_RC来处理此问题。每个init .rc文件还应包含与其服务关联的任何操作。

一个例子是位于system/core/logcat目录中的userdebug logcatd.rc和Android.mk文件。Android.mk文件中的LOCAL_INIT_RC宏在构建
过程中将logcatd.rc放置在/system/etc/init/中。Init在执行mount_all命令时加载logcatd.rc，并在适当时运行服务和排队操作。

将init .rc文件按照它们的守护进程进行拆分比以前使用的大型init .rc文件更可取。这种方法确保init读取的只有存在于文件系统上的二
进制文件对应的服务条目，而在大型init .rc文件中并非如此。此外，当向系统添加多个服务时，这样分拆将有助于解决合并冲突，因为每个
服务都将进入单独的文件。

APEXs中的带版本的RC文件
---------------------------
随着在Android Q上的主线开始，各个主线模块在其范围内携带自己的init.rc文件。Init根据命名模式`/apex/*/etc/*rc`来处理这些文件。

由于APEX模块必须在多个Android版本上运行，它们可能需要不同的参数作为其定义的服务的一部分。从Android T开始，通过在init文件名
中加入SDK版本信息来实现。后缀从`.rc`变为`.#rc`，其中#是该RC文件被接受的第一个SDK版本。一个特定于SDK=31的init文件可以被命名
为`init.31rc`。使用这种方案，一个APEX可以包含多个init文件。下面是一个示例。

对于/apex/sample-module/apex/etc/目录下拥有以下文件的APEX模块：

   1. init.rc
   2. init.32rc
   4. init.35rc

选择规则选择不超过当前运行系统的SDK的最高`.#rc`值。不带后缀的`.rc`表示sdk=0。

当此APEX安装在SDK <=31的设备上时，系统会处理init.rc。当安装在运行SDK 32、33或34的设备上时，它将使用init.32rc。当安装在运
行SDK >= 35的设备上时，它将选择init.35rc。

此版本方案仅适用于APEX模块中的init文件，不适用于存储在/system/etc/init、/vendor/etc/init或其他目录中的init文件。

此命名方案在Android S之后提供。

动作
-------
动作是命令的命名序列。动作有一个触发器，用于确定何时执行该动作。当发生与动作的触发器匹配的事件时，该动作将被添加到待执行队列
的末尾（除非它已经在队列中）。

队列中的每个动作都按顺序出队，并执行该动作中的每个命令。在执行活动命令期间，Init处理其他活动（设备创建/销毁、属性设置、进程
重启）。

动作的形式如下：

    on <trigger> [&& <trigger>]*
       <command>
       <command>
       <command>

根据包含它们的文件的解析顺序（请参阅导入部分），动作按顺序添加到队列并执行，然后在单个文件内顺序执行。

例如，如果一个文件包含：

    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

那么当`boot`触发器发生并且假设属性`true`等于`true`时，执行命令的顺序将是：

    setprop a 1
    setprop b 2
    setprop c 1
    setprop d 2
    setprop e 1
    setprop f 2
    
    服务
--------
服务是在init启动和（可选地）重新启动时运行的程序。服务的形式如下：

    service <名称> <路径> [ <参数> ]*
       <选项>
       <选项>
       ...
       
 选项
--------
选项是对服务的修改器。它们会影响到init运行服务的方式和时间。

`capabilities [ <capability>\* ]`
> 在执行该服务时设置能力（capabilities）。'capability'应为一个Linux能力（capability），没有"CAP_"前缀，比如"NET_ADMIN"
或"SETPCAP"。请参考http://man7.org/linux/man-pages/man7/capabilities.7.html 获取Linux能力的列表。
  如果未提供任何能力，则该服务将被移除所有能力，即使它以root用户运行。

`class <name> [ <name>\* ]`
> 为该服务指定类名（class names）。一个指定类的所有服务可以一起启动或停止。如果没有通过class选项指定类名，则该服务默认为
"default"类。除了（必需的）第一个类名外，额外的类名用于分组服务。
  "animation"类应包括所有启动动画和关机动画所需的服务。由于这些服务可以在启动过程的非常早期被启动，并且可能一直运行到关机
  的最后阶段，因此不能保证可以访问/data分区。这些服务可以检查/data下的文件，但不能保持文件处于打开状态，且在/data不可用时应该正常工作。

`console [<console>]`
> 该服务需要一个控制台。可选的第二个参数选择一个特定的控制台，而不使用默认规定的控制台。默认的"/dev/console"可以通过设置
"androidboot.console"内核参数来更改。在所有情况下，应省略"/dev/"前缀，所以"/dev/tty0"可以指定为"console tty0"。
  此选项将标准输入、标准输出和标准错误连接到控制台。它与stdio_to_kmsg选项互斥，后者只将标准输出和标准错误连接到kmsg。

`critical [window=<fatal crash window分钟>] [target=<fatal reboot目标>]`
> 这是一个设备关键的服务。如果在_fatal crash window分钟_内它退出了超过四次，或者在启动完成之前退出，设备将重新启动到
_fatal reboot目标_。
  _fatal crash window分钟_的默认值为4，_fatal reboot目标_的默认值为'bootloader'。
  可以通过将属性`init.svc_debug.no_fatal.<service-name>`设置为`true`来跳过对指定关键服务的致命重启，以进行测试。
  
  `disabled`
> 这个服务不会随其类一起自动启动。
  必须通过名称或接口名称显式启动。

`enter_namespace <type> <path>`
> 进入位于 _path_ 的 _type_ 类型的命名空间。仅支持网络命名空间，_type_ 设置为 "net"。请注意，每种 _type_ 类型只能进入一
个命名空间。

`file <path> <type>`
> 打开文件路径并将其文件描述符传递给启动的进程。_type_ 必须为
  "r"、"w" 或 "rw"。对于原生可执行文件，请参阅 libcutils
  android\_get\_control\_file()。

`group <groupname> [ <groupname>\* ]`
> 在执行此服务之前切换到“groupname”。除了（必需的）第一个 groupname 之外的其他 groupname 用于设置进程的附加组（通过 
	setgroups()）。
  当前默认为 root。 （？？？应该默认为 nobody）

`interface <interface name> <instance name>`
> 将此服务与其提供的一组 AIDL 或 HIDL 服务关联起来。接口名称必须是完全限定的名称而不是值名称。例如，这用于允许 servicemanager
	或 hwservicemanager 惰性启动服务。
  当提供多个接口时，此标记应多次使用。HIDL 接口的示例条目是 `interface vendor.foo.bar@1.0::IBaz default`。对于 AIDL 接口，
  请使用`interface aidl <instance name>`。AIDL 接口的实例名称是
  与 servicemanager 注册的实例名称一致，可以使用 `adb
  shell dumpsys -l` 列出它们。

`ioprio <class> <priority>`
> 通过 SYS_ioprio_set 系统调用设置此服务的 IO 优先级和 IO 优先级类。
  _class_ 必须是 "rt"、"be" 或 "idle" 中的一个。_priority_ 必须是 0 - 7 范围内的整数。

`keycodes <keycode> [ <keycode>\* ]`
> 设置触发该服务的按键代码。如果同时按下与传递的按键代码对应的所有按键，则服务将启动。这通常用于启动 bugreport 服务。

> 此选项可以接受属性而不是按键代码列表。在这种情况下，提供一个选项：按典型属性扩展格式的属性名。属性必须包含逗号分隔的按键代
码值列表或文本 'none'，表示该服务不响应按键代码。

> 例如，`keycodes ${some.property.name:-none}`，其中 some.property.name 扩展
  为 "123,124,125"。由于按键代码在 init 非常早期处理，
  只能使用 PRODUCT_DEFAULT_PROPERTY_OVERRIDES 属性。

`memcg.limit_in_bytes <value>` 和 `memcg.limit_percent <value>`
> 将子进程的 memory.limit_in_bytes 设置为 `limit_in_bytes`
  字节和 `limit_percent` 中较小的一个，`limit_percent` 表示设备物理内存大小的百分比（仅在 memcg 挂载时）。
  值必须大于等于 0。

`memcg.limit_property <value>`
> 将子进程的 memory.limit_in_bytes 设置为指定属性的值（仅在 memcg 挂载时）。此属性将覆盖通过 `memcg.limit_in_bytes` 
和 `memcg.limit_percent` 指定的值。

`memcg.soft_limit_in_bytes <value>`
> 将子进程的 memory.soft_limit_in_bytes 设置为指定值（仅在 memcg 挂载时），该值必须大于等于 0。

`memcg.swappiness <value>`
> 将子进程的 memory.swappiness 设置为指定值（仅在 memcg 挂载时），该值必须大于等于 0。

`namespace <pid|mnt>`
> 在 fork 服务时进入新的 PID 或挂载命名空间。

`oneshot`
> 当服务退出时不重新启动。

`onrestart`
> 在服务重新启动时执行命令（参见下文）。

`oom_score_adjust <value>`
> 将子进程的 /proc/self/oom\_score\_adj 设置为指定值，
  该值必须在 -1000 到 1000 范围内。

`override`
> 表示此服务定义旨在覆盖先前定义的具有相同名称的服务。这通常用于在 /odm 上覆盖在 /vendor 上定义的服务。init 解析的具有此关
	键字的最后一个服务定义将用于此服务。
  请注意 init.rc 文件解析的顺序，因为出于向后兼容性原因，它具有一些特殊性。此文件的 'imports' 部分详细介绍了顺序。

`priority <priority>`
> 服务进程的调度优先级。该值必须在
  -20 到 19 的范围内。默认优先级为 0。优先级通过 setpriority() 设置。
  
  `reboot_on_failure <目标>`
> 如果该进程无法启动，或者进程以CLD_EXITED以外的退出代码或非0的状态码终止，则重新启动带有指定目标的系统。_target_ 的格式与
sys.powerctl的参数相同。这主要用于在启动期间进行一些必要的检查。

`restart_period <秒数>`
> 如果非一次性服务退出，则在其启动时间加上此持续时间后重新启动。默认为5秒，用于限制崩溃服务的速率。可以增加此值以适应定期运行
的服务。例如，可以将其设置为3600表示服务应每小时运行一次，或者设置为86400表示服务应每天运行一次。

`rlimit <资源> <当前值> <最大值>`
> 将给定的rlimit应用于服务。rlimit会被子进程继承，因此这实际上将给定的rlimit应用于由此服务启动的进程树。解析方式与下面的
setrlimit命令类似。

`seclabel <安全标签>`
> 在执行此服务之前切换到“seclabel”。主要用于从根文件系统运行的服务，例如ueventd、adbd。位于系统分区上的服务可以根据其文件
安全上下文使用策略定义的转换代替。如果未指定，并且策略中未定义转换，则默认为init上下文。

`setenv <变量名> <值>`
> 在启动的进程中将环境变量_name_设置为_value_。

`shutdown <关机行为>`
> 设置服务进程的关机行为。如果未指定，则在关机过程中使用SIGTERM和SIGKILL终止服务。使用"critical"关机行为的服务在关机期间不
会被终止，直到关机超时。当关机超时时，即使标记为"shutdown critical"的服务也会被终止。如果在关机开始时标记为
"shutdown critical"的服务未运行，则会启动该服务。

`sigstop`
> 在调用exec之前立即向服务发送SIGSTOP信号。这用于调试。关于如何使用该选项的更多信息，请参见下面有关调试的部分。

`socket <名称> <类型> <权限> [ <用户> [ <组> [ <安全标签> ] ] ]`
> 创建名为/dev/socket/_name_的UNIX域套接字，并将其文件描述符传递给启动的进程。_type_必须是"dgram"、"stream"或"seqpacket"。
_type_可以以"+passcred"结尾，以启用套接字上的SO_PASSCRED选项。用户和组默认为0。'seclabel'是套接字的SELinux安全上下文。它默
认为服务的安全上下文，如seclabel中指定的，或根据服务可执行文件的安全上下文计算得出。对于原生可执行文件，请参见
libcutils android\_get\_control\_socket()。

`stdio_to_kmsg`
> 将stdout和stderr重定向到/dev/kmsg_debug。这对于在早期启动期间不使用本机Android日志记录且我们希望捕获其日志消息的服务非常
有用。仅当启用/dev/kmsg_debug时，即仅在userdebug和eng构建上启用时，才会启用此功能。这与console选项互斥，console选项还会将
stdin连接到给定的控制台。

`task_profiles <配置文件> [ <配置文件>* ]`
> 在进程分叉时为进程设置任务配置文件。这旨在取代使用writepid选项将进程移动到cgroup的方法。

`timeout_period <秒数>`
> 提供超时时间，在该时间之后，服务将被终止。在这里，将尊重oneshot关键字，因此一次性服务不会自动重新启动，但其他所有服务都会
重新启动。这对于创建与上面描述的restart_period选项结合使用的周期性服务特别有用。

`updatable`
> 标记服务可以后续被APEX覆盖（通过'override'选项）。具有可更新选项的服务在APEX全部激活之前启动时，执行将会延迟，直到激活完
成。不标记为可更新的服务无法被APEX覆盖。

`user <用户名>`
> 在执行此服务之前切换到'username'。当前默认为root。（？？？可能应默认为nobody）从Android M版本开始，即使进程需要Linux特
权，也应使用此选项。以前，为了获取Linux特权，进程需要以root身份运行，请求特权，然后切换到所需的uid。这里有一种新的机制，通
过fs\_config允许设备厂商向特定文件系统上的特定二进制文件添加Linux特权。该机制在
<http://source.android.com/devices/tech/config/filesystem.html>上进行了描述。使用此新机制时，进程可以使用user选项选择其
所需的uid，而无需以root身份运行。从Android O开始，进程还可以在其.rc文件中直接请求特权。参见下面的"capabilities"选项。

`writepid <文件> [ <文件>* ]`
> 当进程分叉时，将子进程的pid写入给定的文件。用于cgroup/cpuset。如果未指定/dev/cpuset/下的文件，但系统属性
'ro.cpuset.default'设置为非空的cpuset名称（例如'/foreground'），则pid将写入文件/dev/cpuset/_cpuset\_name_/tasks。
对于将进程移动到cgroup，此选项的使用已过时。请改用task_profiles选项。

触发器
--------
触发器是用来匹配特定类型事件并引发某个动作的字符串。

触发器被分为事件触发器和属性触发器。

事件触发器是由'trigger'命令或在init可执行文件中使用QueueEventTrigger()函数引发的字符串。它们采用简单的字符串形式，比
如'boot'或'late-init'。

属性触发器是在命名属性的值变为给定新值或命名属性的值变为任意新值时引发的字符串。它们采用'property:<name>=<value>'
和'property:<name>=\*'的形式。在init的初始引导阶段，属性触发器还会进行评估并相应地引发。

一个动作可以有多个属性触发器，但只能有一个事件触发器。

例如：
`on boot && property:a=b`定义了一个只有在'boot'事件触发发生且属性a等于b时才执行的动作。

`on property:a=b && property:c=d`定义了一个在以下三种情况下执行的动作：

   1. 在初始引导期间，如果属性a=b且属性c=d。
   2. 每当属性a从其他值过渡到值b时，而属性c已经等于d。
   3. 每当属性c从其他值过渡到值d时，而属性a已经等于b。


触发器顺序
----------------

在早期引导过程中，init使用以下一系列触发器。这些是在init.cpp中定义的内置触发器。

   1. `early-init` - 首个触发器，在cgroups被配置之后、ueventd的冷启动完成之前触发。
   2. `init` - 冷启动完成后触发。
   3. `charger` - 如果`ro.bootmode == "charger"`，则触发。
   4. `late-init` - 如果`ro.bootmode != "charger"`，或者通过healthd从充电模式启动，则触发。

剩余的触发器由`init.rc`中配置，并非内置的。这些触发器的默认顺序在`init.rc`的"on late-init"事件下指定。在`init.rc`内部的
动作被省略。

   1. `early-fs` - 启动vold。
   2. `fs` - Vold已启动。将未标记为first-stage或latemounted的分区挂载。
   3. `post-fs` - 配置任何依赖早期挂载的内容。
   4. `late-fs` - 挂载被标记为latemounted的分区。
   5. `post-fs-data` - 挂载和配置`/data`；设置加密。如果在第一阶段init中无法挂载`/metadata`，则在这里重新格式化。
   6. `zygote-start` - 启动Zygote。
   7. `early-boot` - 在Zygote启动后。
   8. `boot` - 在`early-boot`动作完成后。
   
   命令
----

`bootchart [start|stop]`
> 启动/停止启动图表记录。这些命令在默认的init.rc文件中存在，但仅当文件/data/bootchart/enabled存在时，启动图表记录才会生
效；否则，启动图表记录的start/stop命令不起作用。

`chmod <octal-mode> <path>`
> 更改文件访问权限。

`chown <owner> <group> <path>`
> 更改文件所有者和组。

`class_start <serviceclass>`
> 如果指定类别的所有服务尚未运行，则启动它们。有关启动服务的更多信息，请参阅启动条目。

`class_stop <serviceclass>`
> 如果指定类别的所有服务当前正在运行，则停止并禁用它们。

`class_reset <serviceclass>`
> 如果指定类别的所有服务当前正在运行，则停止它们，但不禁用。稍后可以使用`class_start`命令重新启动它们。

`class_restart [--only-enabled] <serviceclass>`
> 重新启动指定类别的所有服务。如果指定了`--only-enabled`选项，则跳过已禁用的服务。

`copy <src> <dst>`
> 复制文件。与write类似，但适用于二进制/大量数据。关于src文件，不允许从符号链接文件和world-writable或group-writable文件
复制。关于dst文件，如果文件不存在，则创建的默认模式是0600。如果dst文件是一个普通常规文件并且已经存在，则会被截断。

`copy_per_line <src> <dst>`
> 逐行复制文件。与copy类似，但适用于dst是不能处理多行数据的sysfs节点。

`domainname <name>`
> 设置域名。

`enable <servicename>`
> 将禁用的服务变为启用状态，就好像该服务未指定禁用一样。
  如果该服务应该在运行，则现在它将被启动。
  通常在引导加载程序设置指定特定服务在需要时启动的变量时使用。例如：

    on property:ro.boot.myfancyhardware=1
        enable my_fancy_service_for_my_fancy_hardware

`exec [ <seclabel> [ <user> [ <group>\* ] ] ] -- <command> [ <argument>\* ]`
> 分支并以给定的参数执行命令。命令在“--”之后开始，以便可以提供可选的安全上下文、用户和辅助组。在此命令完成之前，不会执行其他
命令。_seclabel_可以是“-”表示默认值。属性会在_argument_中展开。
  Init会等待分支的进程退出后再继续执行命令。

`exec_background [ <seclabel> [ <user> [ <group>\* ] ] ] -- <command> [ <argument>\* ]`
> 分支并以给定的参数执行命令。这与“exec”命令类似处理。
  不同之处在于，对于`exec_background`，init不会在该进程退出之前停止执行命令。

`exec_start <service>`
> 启动给定的服务，并暂停处理其他init命令，直到该服务返回。该命令的功能类似于“exec”命令，但使用现有的服务定义替代exec参数向量。

`export <name> <value>`
> 在全局环境中将环境变量_name_设置为_value_（该变量将被所有在执行此命令后启动的进程继承）

`hostname <name>`
> 设置主机名。

`ifup <interface>`
> 将网络接口_interface_上线。

`insmod [-f] <path> [<options>]`
> 使用指定选项安装_path_处的模块。
  -f: 强制安装模块，即使运行的内核版本和编译该模块的内核版本不匹配。

`interface_start <name>`
`interface_restart <name>`
`interface_stop <name>`
> 查找提供接口_name_的服务（如果存在），并在其上分别运行`start`、`restart`或`stop`命令。_name_可以是完全限定的HIDL名称，
格式为`<interface>/<instance>`，也可以是AIDL名称，格式为`aidl/<interface>`，例
如`android.hardware.secure_element@1.1::ISecureElement/eSE1`或`aidl/aidl_lazy_test_1`。

> 注意，这些命令只作用于由`interface`服务选项指定的接口，而不作用于动态注册的接口。

> 这些命令的示例用法：\
`interface_start android.hardware.secure_element@1.1::ISecureElement/eSE1`将启动
提供`android.hardware.secure_element@1.1`和`eSI1`实例的HIDL服务。\
`interface_start aidl/aidl_lazy_test_1`将启动提供`aidl_lazy_test_1`接口的AIDL服务。

`load_exports <path>`
> 打开_path_处的文件，并导出其中声明的全局环境变量。每一行必须按照上述格式`export <name> <value>`。

`load_system_props`
> （此操作已弃用，并且不会执行任何操作。）

`load_persist_props`
> 在/data被解密后加载持久属性。
  这在默认的init.rc中包含。

`loglevel <level>`
> 将init的日志级别设置为整数级别，从7（所有日志）到0（仅致命日志）。数字值对应于内核日志级别，但此命令不会影响内核日志级别。
使用`write`命令写入`/proc/sys/kernel/printk`以更改内核日志级别。属性在_level_中展开。

`mark_post_data`
> 用于标记/data挂载后的点。

`mkdir <path> [<mode>] [<owner>] [<group>] [encryption=<action>] [key=<key>]`
> 在_path_处创建目录，可选择使用给定的模式、所有者和组。如果未提供，目录将以权限755创建，并由root用户和root组拥有。如果提供
了该参数，将在目录已存在时更新模式、所有者和组。

> _action_可以是以下之一：
  * `None`：不采取加密操作；如果父目录已加密，则目录将被加密。
  * `Require`：加密目录，如果加密失败，则中止引导过程。
  * `Attempt`：尝试设置加密策略，如果失败继续执行。
  * `DeleteIfNecessary`：递归删除必要的目录以设置加密策略。

> _key_可以是以下之一：
  * `ref`：使用系统范围的DE密钥
  * `per_boot_ref`：使用每次启动时新生成的密钥。

`mount_all [ <fstab> ] [--<option>]`
> 在给定的fs\_mgr格式fstab上调用fs\_mgr\_mount\_all，可选使用选项"early"和"late"。
  如果设置了“--early”，init可执行文件将跳过具有“latemount”标志的挂载条目，并触发fs加密状态事件。如果设置了“--late”，init
  可执行文件将仅挂载具有“latemount”标志的条目。默认情况下，未设置选项，并且mount\_all将处理给定fstab中的所有条目。
  如果未指定fstab参数，则在运行时将扫描fstab.${ro.boot.fstab_suffix}、fstab.${ro.hardware}
  或fstab.${ro.hardware.platform}，按照/odm/etc、/vendor/etc或/的顺序。
  
  `mount <类型> <设备> <目录> [ <标志>\*] [<选项>]`
> 尝试将指定的设备挂载到目录_dir_上。
  _标志_包括"ro"、"rw"、"remount"、"noatime"，...
  _选项_是一个逗号分隔的字符串，例如，barrier=1,noauto\_da\_alloc

`perform_apex_config`
> 在APEX挂载后执行任务。例如，为已挂载的APEX创建数据目录、解析其配置文件，并更新链接器配置。仅在apexd将`apexd.status`设
置为ready时通知挂载事件时使用。

`restart [--only-if-running] <服务>`
> 停止并重启正在运行的服务，如果服务当前正在重新启动，则不执行任何操作，否则，仅启动服务。如果指定了"--only-if-running"，
则只有在服务已经运行时才会重启服务。

`restorecon <路径> [ <路径>\* ]`
> 将名为_path_的文件恢复为文件上指定的安全上下文中的状态。
  对于由init.rc创建的目录不需要此操作，因为它们会自动进行正确的标记。

`restorecon_recursive <路径> [ <路径>\* ]`
> 递归地将名为_path_的目录树恢复为文件上指定的安全上下文中的状态。

`rm <路径>`
> 对给定路径调用unlink(2)。如果系统分区已经挂载，可能应该使用
"exec -- rm ..." (provided the system partition is already mounted)。

`rmdir <路径>`
> 对给定路径调用rmdir(2)。

`readahead <文件|目录> [--fully]`
> 对给定的文件或指定目录中的文件调用readahead(2)。使用选项--fully以读取完整的文件内容。

`setprop <名称> <值>`
> 将系统属性_name_的值设置为_value_。属性将在_value_中进行扩展。

`setrlimit <资源> <当前值> <最大值>`
> 设置资源的rlimit。此设置将应用于在限制设置后启动的所有进程。它旨在在init早期进行设置，并应用于全局。
  _资源_最好使用其文本表示（'cpu'、'rtio'等）或'RLIM_CPU'、'RLIM_RTIO'等表示。也可以将其指定为资源枚举对应的整数值。
  _当前值_和_最大值_可以设置为'unlimited'或'-1'，表示无限制的rlimit。
  
  开始<service>
通过启动服务来运行，如果服务尚未运行。
请注意，这不是同步的，即使是同步的，也不能保证操作系统的调度程序会执行足够的次数来保证服务的状态。
有关同步版本的"start"命令，请参阅"exec_start"命令。

这带来了一个重要的结果，如果服务向其他服务提供功能，例如提供通信通道，那么仅仅在那些服务之前启动此服务是不足以保证在那些服务
请求它之前已经建立了通道的。必须有一种单独的机制来做出任何这样的保证。

停止<service>
如果服务当前正在运行，则停止运行。

swapon_all [<fstab>]
在给定的fstab文件上调用fs_mgr_swapon_all命令。
如果没有指定fstab参数，则会在/odm/etc、/vendor/etc或/根目录下以fstab.${ro.boot.fstab_suffix}、fstab.${ro.hardware}
或fstab.${ro.hardware.platform}的顺序进行扫描。

symlink <target> <path>
在路径_path_上创建一个带有值_target_的符号链接。

sysclktz <minutes_west_of_gmt>
设置系统时钟基准（如果系统时钟在GMT中嘀嗒，则为0）

trigger <event>
触发一个事件。用于将一个动作排队从另一个动作中执行。

umount <path>
卸载位于该路径的文件系统。

umount_all [<fstab>]
在给定的fstab文件上调用fs_mgr_umount_all命令。
如果没有指定fstab参数，则会在/odm/etc、/vendor/etc或/根目录下以fstab.${ro.boot.fstab_suffix}、fstab.${ro.hardware}
或fstab.${ro.hardware.platform}的顺序进行扫描。

verity_update_state
用于更新dm-verity状态并设置由adb remount使用的partition._mount-point_.verified属性的内部实现细节，因为fs_mgr不能直接设
置这些属性。这是自Android 12以来所需的，因为CtsNativeVerifiedBootTestCases将读取属性
"partition.${partition}.verified.hash_alg"以检查是否使用了sha1。有关更多详情，请参见https://r.android.com/1546980。

wait <path> [<timeout>]
轮询给定文件的存在，直到找到为止，或者超时已达到。如果未指定超时时间，默认为五秒。超时值可以是小数秒，以浮点数表示法指定。

wait_for_prop <name> <value>
等待系统属性_name_的值为_value_。_value_中的属性将被展开。如果属性_name_已经设置为_value_，则立即继续。

write <path> <content>
打开位于路径_path_的文件，并使用write(2)将字符串写入其中。
如果文件不存在，则会创建文件。如果文件已存在，则会将其截断。_content_中的属性将被展开。

导入
-------
`import <路径>`
> 解析一个init配置文件，扩展当前的配置。
  如果`路径`是一个目录，则会解析目录中的每个文件作为配置文件。这是非递归的，嵌套目录不会被解析。

import关键字不是一个命令，而是它自己的部分，即它不会作为一个动作的一部分发生，而是在解析文件时处理导入，并遵循以下逻辑。

只有三种情况下，init可执行程序会导入.rc文件：

   1. 当它在初始启动时导入`/system/etc/init/hw/init.rc`或由属性`ro.boot.init_rc`指示的脚本时。
   2. 当它在导入`/system/etc/init/hw/init.rc`之后立即导入`/{system,system_ext,vendor,odm,product}/etc/init/`。
   3. （不推荐使用）当它在mount_all期间导入/{system,vendor,odm}/etc/init/或.rc文件时，
      不允许在Q之后启动的设备使用。

文件的导入顺序因遗留原因而稍微复杂。以下是保证的：

1. 首先，解析`/system/etc/init/hw/init.rc`，然后递归解析它的每个导入文件。
2. `/system/etc/init/`的内容按字母顺序排序并顺序解析，每个文件解析后递归进行导入。
3. 对`/system_ext/etc/init`，`/vendor/etc/init`，`/odm/etc/init`，`/product/etc/init`执行步骤2。

下面的伪代码可以更清楚地解释这个问题：

    fn Import(文件)
      解析(文件)
      for (导入 : 文件.导入)
        导入(导入)

    导入(/system/etc/init/hw/init.rc)
    目录 = [/system/etc/init, /system_ext/etc/init, /vendor/etc/init, /odm/etc/init, /product/etc/init]
    for (目录 : 目录)
      文件 = <按目录内容的字母顺序排序>
      for (文件 : 文件)
        导入(文件)

动作按照解析顺序执行。例如，在`/system/etc/init/hw/init.rc`中的`post-fs-data`动作总是按照它们在文件中出现的顺序执行。
然后，按导入的顺序执行`/system/etc/init/hw/init.rc`的导入中的`post-fs-data`动作，依此类推。

属性
------
Init提供以下属性的状态信息。

`init.svc.<名称>`
> 一个命名服务的状态（"stopped"，"stopping"，"running"，"restarting"）

`dev.mnt.dev.<挂载点>`，`dev.mnt.blk.<挂载点>`，`dev.mnt.rootdisk.<挂载点>`
> 与*挂载点*关联的块设备基本名称。
  *挂载点*将/替换为.，如果引用根挂载点"/"，则使用"/root"。
  `dev.mnt.dev.<挂载点>`表示附加到文件系统的块设备。
    （例如，使用`${dev.mnt.dev.<挂载点>}`/sys/fs/ext4/来访问）

  `dev.mnt.blk.<挂载点>`表示上述块设备的磁盘分区。
    （例如，使用`/sys/class/block/${dev.mnt.blk.<挂载点>}`来访问）

  `dev.mnt.rootdisk.<挂载点>`表示包含上述磁盘分区的根磁盘。
    （例如，使用`/sys/class/block/${dev.mnt.rootdisk.<挂载点>}/queue`来访问）

Init会响应以`ctl.`开头的属性。这些属性的格式为`ctl.[<target>_]<command>`，系统属性的_value_将用作参数。
_target_是可选的，指定_value_应与哪个服务选项匹配。_target_只有一个选项，即`interface`，表示_value_将引用服务提供的接口，
而不是服务名称本身。

例如：

`SetProperty("ctl.start", "logd")` 将在 `logd` 上运行 `start` 命令。

`SetProperty("ctl.interface_start", "aidl/aidl_lazy_test_1")` 将在公开 `aidl aidl_lazy_test_1` 接口的服务上运行
`start` 命令。

请注意，这些属性只是可设置的，当读取时它们没有值。

以下是 _commands_。

`start` \
`restart` \
`stop` \
这等效于在由属性的 _value_ 指定的服务上使用 `start`、`restart` 和 `stop` 命令。

`oneshot_on` 和 `oneshot_off` 将打开或关闭由属性的 _value_ 指定的服务的 _oneshot_ 标志。这特别适用于条件上懒加载硬件抽
象层 (HAL) 的服务。当它们是懒加载 HAL 时，oneshot 必须开启，否则 oneshot 应该关闭。

`sigstop_on` 和 `sigstop_off` 将打开或关闭由属性的 _value_ 指定的服务的 _sigstop_ 功能。有关此功能的更多详细信息，请参阅
下面的 _Debugging init_ 部分。

引导时间
-----------
Init 在系统属性中记录了一些引导时间信息。

`ro.boottime.init`
> 使用 CLOCK_BOOTTIME 时钟以纳秒为单位记录的启动后阶段 init 开始的时间。

`ro.boottime.init.first_stage`
> 运行第一阶段所需的时间，以纳秒为单位。

`ro.boottime.init.selinux`
> 运行 SELinux 阶段所需的时间，以纳秒为单位。

`ro.boottime.init.modules`
> 加载内核模块所需的时间，以毫秒为单位。

`ro.boottime.init.cold_boot_wait`
> init 等待 ueventd 的冷启动阶段结束的时间，以毫秒为单位。

`ro.boottime.<service-name>`
> 服务首次启动后的时间，以 CLOCK_BOOTTIME 时钟为单位，以纳秒表示。

Bootcharting
------------
这个版本的init包含有执行“bootcharting”的代码：生成日志文件，可以在之后使用<http://www.bootchart.org/>提供的工具进行处理。

在模拟器上，使用-bootchart _timeout_选项激活bootcharting功能，持续_timeout_秒。

在设备上：

    adb shell 'touch /data/bootchart/enabled'

完成数据收集后，请不要忘记删除此文件！

日志文件将被写入到/data/bootchart/。提供了一个脚本来检索这些文件并创建一个可以与bootchart命令行工具一起使用的bootchart.tgz
文件：

    sudo apt-get install pybootchartgui
    # grab-bootchart.sh使用$ANDROID_SERIAL。
    $ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh

需要注意的一点是，bootchart将显示init从0秒开始运行。您需要查看dmesg来确定内核实际上何时启动init。

比较两个bootchart
------------------------
一个方便的脚本名为compare-bootcharts.py用于比较所选进程的开始/结束时间。上述的grab-bootchart.sh将
在/tmp/android-bootchart下留下一个名为bootchart.tgz的bootchart tarball。如果在主机上的不同目录下保存了两个这
样的tarballs，脚本可以列出时间戳的差异。例如：

用法：system/core/init/compare-bootcharts.py _base-bootchart-dir_ _exp-bootchart-dir_

    进程：基准 实验 (增量) - 单位为ms（系统上的jiffy是10ms）
    ------------------------------------
    /init: 50 40 (-10)
    /system/bin/surfaceflinger: 4320 4470 (+150)
    /system/bin/bootanimation: 6980 6990 (+10)
    zygote64: 10410 10640 (+230)
    zygote: 10410 10640 (+230)
    system_server: 15350 15150 (-200)
    bootanimation ends at: 33790 31230 (-2560)

Systrace
--------
在userdebug或eng构建上，可以使用Systrace (<http://developer.android.com/tools/help/systrace.html>) 获取在启动过程中
的性能分析报告。

以下是“wm”和“am”类别的示例跟踪事件：

    $ANDROID_BUILD_TOP/external/chromium-trace/systrace.py \
          wm am --boot

该命令将导致设备重新启动。设备重新启动并完成启动顺序后，通过按Ctrl+C从设备获取跟踪报告，并将其作为trace.html写入主机。

限制：记录跟踪事件是在加载持久属性之后开始的，因此不记录在那之前发出的跟踪事件。一些服务，如vold、surfaceflinger和
servicemanager受到此限制的影响，因为它们在加载持久属性之前启动。Zygote初始化和从Zygote派生的进程不受影响。

调试初始化
--------------
当一个服务从init启动时，可能会无法`execv()`该服务。这种情况并不常见，可能是由于新服务启动时链接器发生错误引起的。Android中的
链接器将其日志打印到`logd`和`stderr`中，因此它们可以在`logcat`中看到。如果在访问`logcat`之前遇到错误，可以使
用`stdio_to_kmsg`服务选项将链接器打印到`stderr`中的日志导向到`kmsg`，然后可以通过串口读取这些日志。

不建议在没有init的情况下启动init服务，因为init设置了大量环境（用户、组、安全标签、能力等），很难手动复制。

如果需要从服务的起始位置开始调试，可以添加`sigstop`服务选项。该选项将在调用exec之前立即发送SIGSTOP给服务。在继续使用SIGCONT
继续服务之前，开发者可以通过附加调试器、strace等进行调试。

该标志也可以通过ctl.sigstop_on和ctl.sigstop_off属性动态控制。

以下是通过上述方法动态调试logd的示例：

    stop logd
    setprop ctl.sigstop_on logd
    start logd
    ps -e | grep logd
    > logd          4343     1   18156   1684 do_signal_stop 538280 T init
    gdbclient.py -p 4343
    b main
    c
    c
    c
    > Breakpoint 1, main (argc=1, argv=0x7ff8c9a488) at system/core/logd/main.cpp:427

以下是使用strace进行相同操作的示例：

    stop logd
    setprop ctl.sigstop_on logd
    start logd
    ps -e | grep logd
    > logd          4343     1   18156   1684 do_signal_stop 538280 T init
    strace -p 4343

    （从另一个Shell执行）
    kill -SIGCONT 4343

    > strace运行

主机Init脚本验证
-----------------------------
在构建时会检查Init脚本的正确性。具体检查如下所示。

1) 格式良好的action、service和import部分，例如没有在'import'语句之后多余的行，没有在'on'行之前的动作。
2) 所有命令都映射到有效的关键词，并且参数计数在正确范围内。
3) 所有服务选项都是有效的。这比命令检查更严格，因为服务选项的参数会完全解析，例如需要解析UID和GID。

还有一些Init脚本的其他部分是仅在运行时解析的，因此在构建时不会进行检查，其中包括以下内容。

1) 命令的参数的有效性，例如不会检查文件路径是否存在，SELinux是否允许操作，以及UID和GID是否可解析。
2) 不会检查服务是否存在或是否定义了有效的SELinux域。
3) 不会检查服务是否在其他Init脚本中已经定义。

早期Init引导顺序
------------------------
早期Init引导顺序分为三个阶段：第一阶段init、SELinux设置、第二阶段init。

第一阶段init负责设置加载系统的最低要求。具体包括挂载/dev、/proc，挂载'early mount'分区（需要包括包含系统代码的所有分区，
例如system和vendor），并将system.img挂载到/（对于使用ramdisk的设备）。

需要注意的是，在Android Q中，system.img始终包含TARGET_ROOT_OUT，并且总是在第一阶段init完成时挂载到/。Android Q还需要动态
分区，因此需要使用ramdisk引导Android。还可以使用恢复ramdisk来引导到Android，而不是使用专用的ramdisk。

根据设备配置的不同，第一阶段init有三个变种：
1) 对于system-as-root设备，第一阶段init是/system/bin/init的一部分，而/init是一个指向/system/bin/init的符号链接，以向后兼
容。这些设备不需要执行任何操作来挂载system.img，因为根据定义，它已经被内核作为根文件系统挂载。

2) 对于具有ramdisk的设备，第一阶段init是位于/init的静态可执行文件。这些设备将system.img挂载为/system，然后通过切换根操作将
挂载点从/system移动到/。挂载完成后，ramdisk的内容被释放。

3) 对于使用恢复模式作为ramdisk的设备，在恢复ramdisk中的/shared init中包含了第一阶段init。这些设备首先切换根目录到
/first_stage_ramdisk，以从环境中删除恢复组件，然后像第二种情况一样继续处理。注意，决定正常启动到Android而不是启动到恢复模
式时，是通过内核命令行中是否存在androidboot.force_normal_boot=1或在Android S及更高版本中的bootconfig中指定。

第一阶段init完成后，它会使用"selinux_setup"参数执行/system/bin/init。此阶段是可选地编译和加载SELinux到系统上。有关此过程
的详细信息，请参阅selinux.cpp。

最后，一旦该阶段完成，它会再次使用"second_stage"参数执行/system/bin/init。此时，主要的init阶段运行，并通过init.rc脚本继续
引导过程。