Android Init Language
---------------------
Android初始化语言
---------------------
The Android Init Language consists of five broad classes of statements,
which are Actions, Commands, Services, Options, and Imports.
Android初始化语言包含5种主要的语句类，分别是动作，命令，
服务，选项和导入。
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.
所有的这些操作都是面向行的，以空格进行分离。C样式的反斜杠
转义符可用于插入。也可以使用双引号来防止将文本分成多个标记
的空白。当反斜杠是一行的最后一个字符时，可用于折行。
Lines which start with a # (leading whitespace allowed) are comments.
以#开头的行（允许前面是空格）是注释。
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.
动作和服务隐式声明一个新的部分。所有的命令或选项属于最近
声明的部分。指令或第一部分之前的选项将会被忽略。
Actions and Services have unique names. If a second Action is defined
with the same name as an existing one, its commands are appended to
the commands of the existing action. 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
--------------
Init .rc 文件
--------------
The init language is used in plaintext files that take the .rc file
extension. These are typically multiple of these in multiple
locations on the system, described below.
初始化语言用于采用.rc结尾的纯文本文件进行拓展。
这些文件通常在系统的多个位置，如下所述。
/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. It imports /init.${ro.hardware}.rc which is the
primary vendor supplied .rc file.
/init.rc是主要的.rc文件，在执行开始时，由init可执行程序加载。
它负责初始化建立系统。它将导入/init.${ro.hardware}.rc，也就
是主要供应商提供的.rc文件。
During the mount_all command, the init executable loads all of the
files contained within the /{system,vendor,odm}/etc/init/ directories.
These directories are intended for all Actions and Services used after
file system mounting.
在mount_all命令期间，init可执行程序将加载所有
/{system,vendor,odm}/etc/init/目录中包含的文件。这些目录适用于
之后的所有操作和服务在系统挂载后。
One may specify paths in the mount_all command line to have it import
.rc files at the specified paths instead of the default ones listed above.
This is primarily for supporting factory mode and other non-standard boot
modes. The three default paths should be used for the normal boot process.
可以在mount_all命令行中指定路径以使其导入指定路径上的.rc文件，而不是
上面列出的所有文件。这主要是为了支持工厂模式和其它非标准启动模式。
正常引导过程应使用三个默认路径。
The intention of these directories is as follows
1) /system/etc/init/ is for core system items such as
SurfaceFlinger, MediaService, and logcatd.
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.
这些路径如下所示
1)/system/etc/init/用于核心系统项目，例如
SurfaceFlinger,MediaService和logcatd。
2)/vendor/etc/init/用于SoC供应商项目，例如
动作或核心SoC功能所需的守护进程。
3)/odm/etc/init/用于设备制造商的产品，例如
运动传感器或其它外围设备所需的动作或守护
程序功能。
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.
服务的二进制文件位于系统，供应商或odm上的所有分区应将其服务
条目放入相应的init.rc文件中，位于/etc/init/它们所在的分区的目录。
有一个构建系统宏LOCAL_INIT_RC，供开发人员处理。每个init.rc文件
还应该包含与它的服务。
An example is the 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.
一个示例是位于system/core/logcat/目录中的logcatd.rc和Android.mk
文件。本地的LOCAL_INIT_RC宏在执行期间，Android.mk文件将
logcatd.rc放在/system/etc/init/中。在mount_all命令期间，加载
logcatd.rc并允许在以下情况运行服务并使队列正常。
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.
首先根据守护进程对.rc文件进行拆分到以前使用的整体式init.rc文件。
该方法确保初始化读取的唯一服务条目以及唯一的初始化执行操作对应的
二进制文件确实存在于服务文件系统中，这只是其中之一，整体式的init.rc
文件，还将有助于将多个服务添加到系统时产生的合并冲突解决，例如，每
个都将划分一个单独的文件。
There are two options "early" and "late" in mount_all command
which can be set after optional paths. 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 but skip
importing rc files. By default, no option is set, and mount_all will
mount_all will process all entries in the given fstab.
mount_all命令中有两个选项，分别为"early"和"late"，可以在可选路径中设置。
当设置为"--early"时，在初始化可执行文件将跳过带有"latemount"标志的初始化条目
并触发fs加密状态事件。当设置为"--late"时，初始化可执行文件将仅装载带有"latemount"
标志的条目，但是跳过导入.rc文件。默认情况下，没有设置任何选项，并且mount_all
将mount_all需要处理的条目给定fstab中。
Actions
-------
行为
-------
Actions are named sequences of commands. Actions have a trigger which
is used to determine when the action should occur. 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).
行为Actions就是一个序列的命令集合。每个行为都有一个出发前trigger，触
发器的作用决定了行为Actions什么时候将要执行。当一个符合Action触发条
件的事件发生了，这个行为Action会加入到执行这个的队列的结尾。
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.
每个行为都依次从队列里面被不断的取出来，然后这个行为的每一个命令
都将被一一执行。在这些命令执行的时候，init还同时处理着其它的活动，
包括设备节点的创建和销毁，设置属性，重新启动进程等。
Actions take the form of:
行为的格式如下：
on <trigger> [&& <trigger>]*
<command>
<command>
<command>
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.
critical
This is a device-critical service. If it exits more than four times in
four minutes, the device will reboot into recovery mode.
disabled
This service will not automatically start with its class.
It must be explicitly started by name.
setenv <name> <value>
Set the environment variable <name> to <value> in the launched process.
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".
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.
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.
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)
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.
oneshot
Do not restart the service when it exits.
class <name>
Specify a class name 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.
onrestart
Execute a Command (see below) when service restarts.
writepid <file...>
Write the child's pid to the given files when it forks. Meant for
cgroup/cpuset usage.
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.
Commands
--------
bootchart_init
Start bootcharting if configured (see below).
This is included in the default init.rc.
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.
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.
copy <src> <dst>
Copies a file. Similar to write, but useful for binary/large
amounts 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.
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 <path>
Install the module at <path>
load_all_props
Loads properties from /system, /vendor, et cetera.
This is included in the default init.rc.
load_persist_props
Loads persistent properties when /data has been decrypted.
This is included in the default init.rc.
loglevel <level>
Sets the kernel log level to level. Properties are expanded within <level>.
mkdir <path> [mode] [owner] [group]
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.
mount_all <fstab> [ <path> ]* [--<option>]
Calls fs_mgr_mount_all on the given fs_mgr-format fstab and imports .rc files
at the specified paths (e.g., on the partitions just mounted) with optional
options "early" and "late".
Refer to the section of "Init .rc Files" for detail.
mount <type> <device> <dir> [ <flag> ]* [<options>]
Attempt to mount the named device at the directory <dir>
<device> may be of the form mtd@name to specify a mtd block
device by name.
<flag>s include "ro", "rw", "remount", "noatime", ...
<options> include "barrier=1", "noauto_da_alloc", "discard", ... as
a comma separated string, eg: barrier=1,noauto_da_alloc
powerctl
Internal implementation detail used to respond to changes to the
"sys.powerctl" system property, used to implement rebooting.
restart <service>
Like stop, but doesn't disable the service.
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.
setprop <name> <value>
Set system property <name> to <value>. Properties are expanded
within <value>.
setrlimit <resource> <cur> <max>
Set the rlimit for a resource.
start <service>
Start a service running if it is not already running.
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.
symlink <target> <path>
Create a symbolic link at <path> with the value <target>
sysclktz <mins_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.
verity_load_state
Internal implementation detail used to load dm-verity state.
verity_update_state <mount_point>
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.
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.
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
-------
The import keyword is not a command, but rather its own section and is
handled immediately after the .rc file that contains it has finished
being parsed. It takes the below form:
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.
There are only two times where the init executable imports .rc files,
1) When it imports /init.rc during initial boot
2) When it imports /{system,vendor,odm}/etc/init/ or .rc files at specified
paths during mount_all
Properties
----------
Init provides information about the services that it is responsible
for via the below properties.
init.svc.<name>
State of a named service ("stopped", "stopping", "running", "restarting")
Bootcharting
------------
This version of init contains code to perform "bootcharting": generating log
files that can be later processed by the tools provided by www.bootchart.org.
On the emulator, use the -bootchart <timeout> option to boot with bootcharting
activated for <timeout> seconds.
On a device, create /data/bootchart/start with a command like the following:
adb shell 'echo $TIMEOUT > /data/bootchart/start'
Where the value of $TIMEOUT corresponds to the desired bootcharted period in
seconds. Bootcharting will stop after that many seconds have elapsed.
You can also stop the bootcharting at any moment by doing the following:
adb shell 'echo 1 > /data/bootchart/stop'
Note that /data/bootchart/stop is deleted automatically by init at the end of
the bootcharting. This is not the case with /data/bootchart/start, so don't
forget to delete it 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 barballs 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 [1] 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.
[1] http://developer.android.com/tools/help/systrace.html
Debugging init
--------------
By default, programs executed by init will drop stdout and stderr into
/dev/null. To help with debugging, you can execute your program via the
Android program logwrapper. This will redirect stdout/stderr into the
Android logging system (accessed via logcat).
For example
service akmd /system/bin/logwrapper /sbin/akmd
For quicker turnaround when working on init itself, use:
mm -j
m ramdisk-nodeps
m bootimage-nodeps
adb reboot bootloader
fastboot boot $ANDROID_PRODUCT_OUT/boot.img
Alternatively, use the emulator:
emulator -partition-size 1024 -verbose -show-kernel -no-window
You might want to call klog_set_level(6) after the klog_init() call
so you see the kernel logging in dmesg (or the emulator output).