GoogleGit

blob: bf440c2b78a090c5d0caf81c867547f28f06e71f [file] [log] [blame]
  1. Android Init Language
  2. ---------------------
  3. The Android Init Language consists of five broad classes of statements,
  4. which are Actions, Commands, Services, Options, and Imports.
  5. All of these are line-oriented, consisting of tokens separated by
  6. whitespace. The c-style backslash escapes may be used to insert
  7. whitespace into a token. Double quotes may also be used to prevent
  8. whitespace from breaking text into multiple tokens. The backslash,
  9. when it is the last character on a line, may be used for line-folding.
  10. Lines which start with a # (leading whitespace allowed) are comments.
  11. Actions and Services implicitly declare a new section. All commands
  12. or options belong to the section most recently declared. Commands
  13. or options before the first section are ignored.
  14. Actions and Services have unique names. If a second Action is defined
  15. with the same name as an existing one, its commands are appended to
  16. the commands of the existing action. If a second Service is defined
  17. with the same name as an existing one, it is ignored and an error
  18. message is logged.
  19. Init .rc Files
  20. --------------
  21. The init language is used in plaintext files that take the .rc file
  22. extension. These are typically multiple of these in multiple
  23. locations on the system, described below.
  24. /init.rc is the primary .rc file and is loaded by the init executable
  25. at the beginning of its execution. It is responsible for the initial
  26. set up of the system. It imports /init.${ro.hardware}.rc which is the
  27. primary vendor supplied .rc file.
  28. During the mount_all command, the init executable loads all of the
  29. files contained within the /{system,vendor,odm}/etc/init/ directories.
  30. These directories are intended for all Actions and Services used after
  31. file system mounting.
  32. The intention of these directories is as follows
  33. 1) /system/etc/init/ is for core system items such as
  34. SurfaceFlinger and MediaService.
  35. 2) /vendor/etc/init/ is for SoC vendor items such as actions or
  36. daemons needed for core SoC functionality.
  37. 3) /odm/etc/init/ is for device manufacturer items such as
  38. actions or daemons needed for motion sensor or other peripheral
  39. functionality.
  40. Actions
  41. -------
  42. Actions are named sequences of commands. Actions have a trigger which
  43. is used to determine when the action should occur. When an event
  44. occurs which matches an action's trigger, that action is added to
  45. the tail of a to-be-executed queue (unless it is already on the
  46. queue).
  47. Each action in the queue is dequeued in sequence and each command in
  48. that action is executed in sequence. Init handles other activities
  49. (device creation/destruction, property setting, process restarting)
  50. "between" the execution of the commands in activities.
  51. Actions take the form of:
  52. on <trigger> [&& <trigger>]*
  53. <command>
  54. <command>
  55. <command>
  56. Services
  57. --------
  58. Services are programs which init launches and (optionally) restarts
  59. when they exit. Services take the form of:
  60. service <name> <pathname> [ <argument> ]*
  61. <option>
  62. <option>
  63. ...
  64. Options
  65. -------
  66. Options are modifiers to services. They affect how and when init
  67. runs the service.
  68. critical
  69. This is a device-critical service. If it exits more than four times in
  70. four minutes, the device will reboot into recovery mode.
  71. disabled
  72. This service will not automatically start with its class.
  73. It must be explicitly started by name.
  74. setenv <name> <value>
  75. Set the environment variable <name> to <value> in the launched process.
  76. socket <name> <type> <perm> [ <user> [ <group> [ <seclabel> ] ] ]
  77. Create a unix domain socket named /dev/socket/<name> and pass
  78. its fd to the launched process. <type> must be "dgram", "stream" or "seqpacket".
  79. User and group default to 0.
  80. 'seclabel' is the SELinux security context for the socket.
  81. It defaults to the service security context, as specified by seclabel or
  82. computed based on the service executable file security context.
  83. user <username>
  84. Change to username before exec'ing this service.
  85. Currently defaults to root. (??? probably should default to nobody)
  86. Currently, if your process requires linux capabilities then you cannot use
  87. this command. You must instead request the capabilities in-process while
  88. still root, and then drop to your desired uid.
  89. group <groupname> [ <groupname> ]*
  90. Change to groupname before exec'ing this service. Additional
  91. groupnames beyond the (required) first one are used to set the
  92. supplemental groups of the process (via setgroups()).
  93. Currently defaults to root. (??? probably should default to nobody)
  94. seclabel <seclabel>
  95. Change to 'seclabel' before exec'ing this service.
  96. Primarily for use by services run from the rootfs, e.g. ueventd, adbd.
  97. Services on the system partition can instead use policy-defined transitions
  98. based on their file security context.
  99. If not specified and no transition is defined in policy, defaults to the init context.
  100. oneshot
  101. Do not restart the service when it exits.
  102. class <name>
  103. Specify a class name for the service. All services in a
  104. named class may be started or stopped together. A service
  105. is in the class "default" if one is not specified via the
  106. class option.
  107. onrestart
  108. Execute a Command (see below) when service restarts.
  109. writepid <file...>
  110. Write the child's pid to the given files when it forks. Meant for
  111. cgroup/cpuset usage.
  112. Triggers
  113. --------
  114. Triggers are strings which can be used to match certain kinds of
  115. events and used to cause an action to occur.
  116. Triggers are subdivided into event triggers and property triggers.
  117. Event triggers are strings triggered by the 'trigger' command or by
  118. the QueueEventTrigger() function within the init executable. These
  119. take the form of a simple string such as 'boot' or 'late-init'.
  120. Property triggers are strings triggered when a named property changes
  121. value to a given new value or when a named property changes value to
  122. any new value. These take the form of 'property:<name>=<value>' and
  123. 'property:<name>=*' respectively. Property triggers are additionally
  124. evaluated and triggered accordingly during the initial boot phase of
  125. init.
  126. An Action can have multiple property triggers but may only have one
  127. event trigger.
  128. For example:
  129. 'on boot && property:a=b' defines an action that is only executed when
  130. the 'boot' event trigger happens and the property a equals b.
  131. 'on property:a=b && property:c=d' defines an action that is executed
  132. at three times,
  133. 1) During initial boot if property a=b and property c=d
  134. 2) Any time that property a transitions to value b, while property
  135. c already equals d.
  136. 3) Any time that property c transitions to value d, while property
  137. a already equals b.
  138. Commands
  139. --------
  140. bootchart_init
  141. Start bootcharting if configured (see below).
  142. This is included in the default init.rc.
  143. chmod <octal-mode> <path>
  144. Change file access permissions.
  145. chown <owner> <group> <path>
  146. Change file owner and group.
  147. class_start <serviceclass>
  148. Start all services of the specified class if they are
  149. not already running.
  150. class_stop <serviceclass>
  151. Stop and disable all services of the specified class if they are
  152. currently running.
  153. class_reset <serviceclass>
  154. Stop all services of the specified class if they are
  155. currently running, without disabling them. They can be restarted
  156. later using class_start.
  157. copy <src> <dst>
  158. Copies a file. Similar to write, but useful for binary/large
  159. amounts of data.
  160. domainname <name>
  161. Set the domain name.
  162. enable <servicename>
  163. Turns a disabled service into an enabled one as if the service did not
  164. specify disabled.
  165. If the service is supposed to be running, it will be started now.
  166. Typically used when the bootloader sets a variable that indicates a specific
  167. service should be started when needed. E.g.
  168. on property:ro.boot.myfancyhardware=1
  169. enable my_fancy_service_for_my_fancy_hardware
  170. exec [ <seclabel> [ <user> [ <group> ]* ] ] -- <command> [ <argument> ]*
  171. Fork and execute command with the given arguments. The command starts
  172. after "--" so that an optional security context, user, and supplementary
  173. groups can be provided. No other commands will be run until this one
  174. finishes. <seclabel> can be a - to denote default.
  175. export <name> <value>
  176. Set the environment variable <name> equal to <value> in the
  177. global environment (which will be inherited by all processes
  178. started after this command is executed)
  179. hostname <name>
  180. Set the host name.
  181. ifup <interface>
  182. Bring the network interface <interface> online.
  183. insmod <path>
  184. Install the module at <path>
  185. load_all_props
  186. Loads properties from /system, /vendor, et cetera.
  187. This is included in the default init.rc.
  188. load_persist_props
  189. Loads persistent properties when /data has been decrypted.
  190. This is included in the default init.rc.
  191. loglevel <level>
  192. Sets the kernel log level to level. Properties are expanded within <level>.
  193. mkdir <path> [mode] [owner] [group]
  194. Create a directory at <path>, optionally with the given mode, owner, and
  195. group. If not provided, the directory is created with permissions 755 and
  196. owned by the root user and root group. If provided, the mode, owner and group
  197. will be updated if the directory exists already.
  198. mount_all <fstab>
  199. Calls fs_mgr_mount_all on the given fs_mgr-format fstab.
  200. mount <type> <device> <dir> [ <flag> ]* [<options>]
  201. Attempt to mount the named device at the directory <dir>
  202. <device> may be of the form mtd@name to specify a mtd block
  203. device by name.
  204. <flag>s include "ro", "rw", "remount", "noatime", ...
  205. <options> include "barrier=1", "noauto_da_alloc", "discard", ... as
  206. a comma separated string, eg: barrier=1,noauto_da_alloc
  207. powerctl
  208. Internal implementation detail used to respond to changes to the
  209. "sys.powerctl" system property, used to implement rebooting.
  210. restart <service>
  211. Like stop, but doesn't disable the service.
  212. restorecon <path> [ <path> ]*
  213. Restore the file named by <path> to the security context specified
  214. in the file_contexts configuration.
  215. Not required for directories created by the init.rc as these are
  216. automatically labeled correctly by init.
  217. restorecon_recursive <path> [ <path> ]*
  218. Recursively restore the directory tree named by <path> to the
  219. security contexts specified in the file_contexts configuration.
  220. rm <path>
  221. Calls unlink(2) on the given path. You might want to
  222. use "exec -- rm ..." instead (provided the system partition is
  223. already mounted).
  224. rmdir <path>
  225. Calls rmdir(2) on the given path.
  226. setprop <name> <value>
  227. Set system property <name> to <value>. Properties are expanded
  228. within <value>.
  229. setrlimit <resource> <cur> <max>
  230. Set the rlimit for a resource.
  231. start <service>
  232. Start a service running if it is not already running.
  233. stop <service>
  234. Stop a service from running if it is currently running.
  235. swapon_all <fstab>
  236. Calls fs_mgr_swapon_all on the given fstab file.
  237. symlink <target> <path>
  238. Create a symbolic link at <path> with the value <target>
  239. sysclktz <mins_west_of_gmt>
  240. Set the system clock base (0 if system clock ticks in GMT)
  241. trigger <event>
  242. Trigger an event. Used to queue an action from another
  243. action.
  244. verity_load_state
  245. Internal implementation detail used to load dm-verity state.
  246. verity_update_state <mount_point>
  247. Internal implementation detail used to update dm-verity state and
  248. set the partition.<mount_point>.verified properties used by adb remount
  249. because fs_mgr can't set them directly itself.
  250. wait <path> [ <timeout> ]
  251. Poll for the existence of the given file and return when found,
  252. or the timeout has been reached. If timeout is not specified it
  253. currently defaults to five seconds.
  254. write <path> <content>
  255. Open the file at <path> and write a string to it with write(2).
  256. If the file does not exist, it will be created. If it does exist,
  257. it will be truncated. Properties are expanded within <content>.
  258. Imports
  259. -------
  260. The import keyword is not a command, but rather its own section and is
  261. handled immediately after the .rc file that contains it has finished
  262. being parsed. It takes the below form:
  263. import <path>
  264. Parse an init config file, extending the current configuration.
  265. If <path> is a directory, each file in the directory is parsed as
  266. a config file. It is not recursive, nested directories will
  267. not be parsed.
  268. There are only two times where the init executable imports .rc files,
  269. 1) When it imports /init.rc during initial boot
  270. 2) When it imports /{system,vendor,odm}/etc/init/ during mount_all
  271. Properties
  272. ----------
  273. Init provides information about the services that it is responsible
  274. for via the below properties.
  275. init.svc.<name>
  276. State of a named service ("stopped", "stopping", "running", "restarting")
  277. Bootcharting
  278. ------------
  279. This version of init contains code to perform "bootcharting": generating log
  280. files that can be later processed by the tools provided by www.bootchart.org.
  281. On the emulator, use the -bootchart <timeout> option to boot with bootcharting
  282. activated for <timeout> seconds.
  283. On a device, create /data/bootchart/start with a command like the following:
  284. adb shell 'echo $TIMEOUT > /data/bootchart/start'
  285. Where the value of $TIMEOUT corresponds to the desired bootcharted period in
  286. seconds. Bootcharting will stop after that many seconds have elapsed.
  287. You can also stop the bootcharting at any moment by doing the following:
  288. adb shell 'echo 1 > /data/bootchart/stop'
  289. Note that /data/bootchart/stop is deleted automatically by init at the end of
  290. the bootcharting. This is not the case with /data/bootchart/start, so don't
  291. forget to delete it when you're done collecting data.
  292. The log files are written to /data/bootchart/. A script is provided to
  293. retrieve them and create a bootchart.tgz file that can be used with the
  294. bootchart command-line utility:
  295. sudo apt-get install pybootchartgui
  296. # grab-bootchart.sh uses $ANDROID_SERIAL.
  297. $ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh
  298. One thing to watch for is that the bootchart will show init as if it started
  299. running at 0s. You'll have to look at dmesg to work out when the kernel
  300. actually started init.
  301. Comparing two bootcharts
  302. ------------------------
  303. A handy script named compare-bootcharts.py can be used to compare the
  304. start/end time of selected processes. The aforementioned grab-bootchart.sh
  305. will leave a bootchart tarball named bootchart.tgz at /tmp/android-bootchart.
  306. If two such barballs are preserved on the host machine under different
  307. directories, the script can list the timestamps differences. For example:
  308. Usage: system/core/init/compare-bootcharts.py base_bootchart_dir
  309. exp_bootchart_dir
  310. process: baseline experiment (delta)
  311. - Unit is ms (a jiffy is 10 ms on the system)
  312. ------------------------------------
  313. /init: 50 40 (-10)
  314. /system/bin/surfaceflinger: 4320 4470 (+150)
  315. /system/bin/bootanimation: 6980 6990 (+10)
  316. zygote64: 10410 10640 (+230)
  317. zygote: 10410 10640 (+230)
  318. system_server: 15350 15150 (-200)
  319. bootanimation ends at: 33790 31230 (-2560)
  320. Systrace
  321. --------
  322. Systrace [1] can be used for obtaining performance analysis reports during boot
  323. time on userdebug or eng builds.
  324. Here is an example of trace events of "wm" and "am" categories:
  325. $ANDROID_BUILD_TOP/external/chromium-trace/systrace.py wm am --boot
  326. This command will cause the device to reboot. After the device is rebooted and
  327. the boot sequence has finished, the trace report is obtained from the device
  328. and written as trace.html on the host by hitting Ctrl+C.
  329. LIMITATION
  330. Recording trace events is started after persistent properties are loaded, so
  331. the trace events that are emitted before that are not recorded. Several
  332. services such as vold, surfaceflinger, and servicemanager are affected by this
  333. limitation since they are started before persistent properties are loaded.
  334. Zygote initialization and the processes that are forked from the zygote are not
  335. affected.
  336. [1] http://developer.android.com/tools/help/systrace.html
  337. Debugging init
  338. --------------
  339. By default, programs executed by init will drop stdout and stderr into
  340. /dev/null. To help with debugging, you can execute your program via the
  341. Android program logwrapper. This will redirect stdout/stderr into the
  342. Android logging system (accessed via logcat).
  343. For example
  344. service akmd /system/bin/logwrapper /sbin/akmd
  345. For quicker turnaround when working on init itself, use:
  346. mm -j
  347. m ramdisk-nodeps
  348. m bootimage-nodeps
  349. adb reboot bootloader
  350. fastboot boot $ANDROID_PRODUCT_OUT/boot.img
  351. Alternatively, use the emulator:
  352. emulator -partition-size 1024 -verbose -show-kernel -no-window
  353. You might want to call klog_set_level(6) after the klog_init() call
  354. so you see the kernel logging in dmesg (or the emulator output).