1Android Init Language 2--------------------- 3 4The Android Init Language consists of five broad classes of statements: 5Actions, Commands, Services, Options, and Imports. 6 7All of these are line-oriented, consisting of tokens separated by 8whitespace. The c-style backslash escapes may be used to insert 9whitespace into a token. Double quotes may also be used to prevent 10whitespace from breaking text into multiple tokens. The backslash, 11when it is the last character on a line, may be used for line-folding. 12 13Lines which start with a `#` (leading whitespace allowed) are comments. 14 15System properties can be expanded using the syntax 16`${property.name}`. This also works in contexts where concatenation is 17required, such as `import /init.recovery.${ro.hardware}.rc`. 18 19Actions and Services implicitly declare a new section. All commands 20or options belong to the section most recently declared. Commands 21or options before the first section are ignored. 22 23Services have unique names. If a second Service is defined 24with the same name as an existing one, it is ignored and an error 25message is logged. 26 27 28Init .rc Files 29-------------- 30The init language is used in plain text files that take the .rc file 31extension. There are typically multiple of these in multiple 32locations on the system, described below. 33 34`/system/etc/init/hw/init.rc` is the primary .rc file and is loaded by the init executable at the 35beginning of its execution. It is responsible for the initial set up of the system. 36 37Init loads all of the files contained within the 38`/{system,system_ext,vendor,odm,product}/etc/init/` directories immediately after loading 39the primary `/system/etc/init/hw/init.rc`. This is explained in more details in the 40[Imports](#imports) section of this file. 41 42Legacy devices without the first stage mount mechanism previously were 43able to import init scripts during mount_all, however that is deprecated 44and not allowed for devices launching after Q. 45 46The intention of these directories is: 47 48 1. /system/etc/init/ is for core system items such as 49 SurfaceFlinger, MediaService, and logd. 50 2. /vendor/etc/init/ is for SoC vendor items such as actions or 51 daemons needed for core SoC functionality. 52 3. /odm/etc/init/ is for device manufacturer items such as 53 actions or daemons needed for motion sensor or other peripheral 54 functionality. 55 56All services whose binaries reside on the system, vendor, or odm 57partitions should have their service entries placed into a 58corresponding init .rc file, located in the /etc/init/ 59directory of the partition where they reside. There is a build 60system macro, LOCAL\_INIT\_RC, that handles this for developers. Each 61init .rc file should additionally contain any actions associated with 62its service. 63 64An example is the userdebug logcatd.rc and Android.mk files located in the 65system/core/logcat directory. The LOCAL\_INIT\_RC macro in the 66Android.mk file places logcatd.rc in /system/etc/init/ during the 67build process. Init loads logcatd.rc during the mount\_all command and 68allows the service to be run and the action to be queued when 69appropriate. 70 71This break up of init .rc files according to their daemon is preferred 72to the previously used monolithic init .rc files. This approach 73ensures that the only service entries that init reads and the only 74actions that init performs correspond to services whose binaries are in 75fact present on the file system, which was not the case with the 76monolithic init .rc files. This additionally will aid in merge 77conflict resolution when multiple services are added to the system, as 78each one will go into a separate file. 79 80Versioned RC files within APEXs 81------------------------------- 82 83With the arrival of mainline on Android Q, the individual mainline 84modules carry their own init.rc files within their boundaries. Init 85processes these files according to the naming pattern `/apex/*/etc/*rc`. 86 87Because APEX modules must run on more than one release of Android, 88they may require different parameters as part of the services they 89define. This is achieved, starting in Android T, by incorporating 90the SDK version information in the name of the init file. The suffix 91is changed from `.rc` to `.#rc` where # is the first SDK where that 92RC file is accepted. An init file specific to SDK=31 might be named 93`init.31rc`. With this scheme, an APEX may include multiple init files. An 94example is appropriate. 95 96For an APEX module with the following files in /apex/sample-module/apex/etc/: 97 98 1. init.rc 99 2. init.32rc 100 4. init.35rc 101 102The selection rule chooses the highest `.#rc` value that does not 103exceed the SDK of the currently running system. The unadorned `.rc` 104is interpreted as sdk=0. 105 106When this APEX is installed on a device with SDK <=31, the system will 107process init.rc. When installed on a device running SDK 32, 33, or 34, 108it will use init.32rc. When installed on a device running SDKs >= 35, 109it will choose init.35rc 110 111This versioning scheme is used only for the init files within APEX 112modules; it does not apply to the init files stored in /system/etc/init, 113/vendor/etc/init, or other directories. 114 115This naming scheme is available after Android S. 116 117Actions 118------- 119Actions are named sequences of commands. Actions have a trigger which 120is used to determine when the action is executed. When an event 121occurs which matches an action's trigger, that action is added to 122the tail of a to-be-executed queue (unless it is already on the 123queue). 124 125Each action in the queue is dequeued in sequence and each command in 126that action is executed in sequence. Init handles other activities 127(device creation/destruction, property setting, process restarting) 128"between" the execution of the commands in activities. 129 130Actions take the form of: 131 132 on <trigger> [&& <trigger>]* 133 <command> 134 <command> 135 <command> 136 137Actions are added to the queue and executed based on the order that 138the file that contains them was parsed (see the Imports section), then 139sequentially within an individual file. 140 141For example if a file contains: 142 143 on boot 144 setprop a 1 145 setprop b 2 146 147 on boot && property:true=true 148 setprop c 1 149 setprop d 2 150 151 on boot 152 setprop e 1 153 setprop f 2 154 155Then when the `boot` trigger occurs and assuming the property `true` 156equals `true`, then the order of the commands executed will be: 157 158 setprop a 1 159 setprop b 2 160 setprop c 1 161 setprop d 2 162 setprop e 1 163 setprop f 2 164 165If the property `true` wasn't `true` when the `boot` was triggered, then the 166order of the commands executed will be: 167 168 setprop a 1 169 setprop b 2 170 setprop e 1 171 setprop f 2 172 173If the property `true` becomes `true` *AFTER* `boot` was triggered, nothing will 174be executed. The condition `boot && property:true=true` will be evaluated to 175false because the `boot` trigger is a past event. 176 177Note that when `ro.property_service.async_persist_writes` is `true`, there is no 178defined ordering between persistent setprops and non-persistent setprops. For 179example: 180 181 on boot 182 setprop a 1 183 setprop persist.b 2 184 185When `ro.property_service.async_persist_writes` is `true`, triggers for these 186two properties may execute in any order. 187 188Services 189-------- 190Services are programs which init launches and (optionally) restarts 191when they exit. Services take the form of: 192 193 service <name> <pathname> [ <argument> ]* 194 <option> 195 <option> 196 ... 197 198 199Options 200------- 201Options are modifiers to services. They affect how and when init 202runs the service. 203 204`capabilities [ <capability>\* ]` 205> Set capabilities when exec'ing this service. 'capability' should be a Linux 206 capability without the "CAP\_" prefix, like "NET\_ADMIN" or "SETPCAP". See 207 http://man7.org/linux/man-pages/man7/capabilities.7.html for a list of Linux 208 capabilities. 209 If no capabilities are provided, then behaviour depends on the user the service runs under: 210 * if it's root, then the service will run with all the capabitilies (note: whether the 211 service can actually use them is controlled by selinux); 212 * otherwise all capabilities will be dropped. 213 214`class <name> [ <name>\* ]` 215> Specify class names for the service. All services in a 216 named class may be started or stopped together. A service 217 is in the class "default" if one is not specified via the 218 class option. Additional classnames beyond the (required) first 219 one are used to group services. 220 The `animation` class should include all services necessary for both 221 boot animation and shutdown animation. As these services can be 222 launched very early during bootup and can run until the last stage 223 of shutdown, access to /data partition is not guaranteed. These 224 services can check files under /data but it should not keep files opened 225 and should work when /data is not available. 226 227`console [<console>]` 228> This service needs a console. The optional second parameter chooses a 229 specific console instead of the default. The default "/dev/console" can 230 be changed by setting the "androidboot.console" kernel parameter. In 231 all cases the leading "/dev/" should be omitted, so "/dev/tty0" would be 232 specified as just "console tty0". 233 This option connects stdin, stdout, and stderr to the console. It is mutually exclusive with the 234 stdio_to_kmsg option, which only connects stdout and stderr to kmsg. 235 236`critical [window=<fatal crash window mins>] [target=<fatal reboot target>]` 237> This is a device-critical service. If it exits more than four times in 238 _fatal crash window mins_ minutes or before boot completes, the device 239 will reboot into _fatal reboot target_. 240 The default value of _fatal crash window mins_ is 4, and default value 241 of _fatal reboot target_ is 'bootloader'. 242 For tests, the fatal reboot can be skipped by setting property 243 `init.svc_debug.no_fatal.<service-name>` to `true` for specified critical service. 244 245`disabled` 246> This service will not automatically start with its class. 247 It must be explicitly started by name or by interface name. 248 249`enter_namespace <type> <path>` 250> Enters the namespace of type _type_ located at _path_. Only network namespaces are supported with 251 _type_ set to "net". Note that only one namespace of a given _type_ may be entered. 252 253`file <path> <type>` 254> Open a file path and pass its fd to the launched process. _type_ must be 255 "r", "w" or "rw". For native executables see libcutils 256 android\_get\_control\_file(). 257 258`gentle_kill` 259> This service will be sent SIGTERM instead of SIGKILL when stopped. After a 200 ms timeout, it will 260 be sent SIGKILL. 261 262`group <groupname> [ <groupname>\* ]` 263> Change to 'groupname' before exec'ing this service. Additional 264 groupnames beyond the (required) first one are used to set the 265 supplemental groups of the process (via setgroups()). 266 Currently defaults to root. (??? probably should default to nobody) 267 268`interface <interface name> <instance name>` 269> Associates this service with a list of the AIDL or HIDL services that it provides. The interface 270 name must be a fully-qualified name and not a value name. For instance, this is used to allow 271 servicemanager or hwservicemanager to lazily start services. When multiple interfaces are served, 272 this tag should be used multiple times. An example of an entry for a HIDL 273 interface is `interface vendor.foo.bar@1.0::IBaz default`. For an AIDL interface, use 274 `interface aidl <instance name>`. The instance name for an AIDL interface is 275 whatever is registered with servicemanager, and these can be listed with `adb 276 shell dumpsys -l`. 277 278`ioprio <class> <priority>` 279> Sets the IO priority and IO priority class for this service via the SYS_ioprio_set syscall. 280 _class_ must be one of "rt", "be", or "idle". _priority_ must be an integer in the range 0 - 7. 281 282`keycodes <keycode> [ <keycode>\* ]` 283> Sets the keycodes that will trigger this service. If all of the keys corresponding to the passed 284 keycodes are pressed at once, the service will start. This is typically used to start the 285 bugreport service. 286 287> This option may take a property instead of a list of keycodes. In this case, only one option is 288 provided: the property name in the typical property expansion format. The property must contain 289 a comma separated list of keycode values or the text 'none' to indicate that 290 this service does not respond to keycodes. 291 292> For example, `keycodes ${some.property.name:-none}` where some.property.name expands 293 to "123,124,125". Since keycodes are handled very early in init, 294 only PRODUCT_DEFAULT_PROPERTY_OVERRIDES properties can be used. 295 296`memcg.limit_in_bytes <value>` and `memcg.limit_percent <value>` 297> Sets the child's memory.limit_in_bytes to the minimum of `limit_in_bytes` 298 bytes and `limit_percent` which is interpreted as a percentage of the size 299 of the device's physical memory (only if memcg is mounted). 300 Values must be equal or greater than 0. 301 302`memcg.limit_property <value>` 303> Sets the child's memory.limit_in_bytes to the value of the specified property 304 (only if memcg is mounted). This property will override the values specified 305 via `memcg.limit_in_bytes` and `memcg.limit_percent`. 306 307`memcg.soft_limit_in_bytes <value>` 308> Sets the child's memory.soft_limit_in_bytes to the specified value (only if memcg is mounted), 309 which must be equal or greater than 0. 310 311`memcg.swappiness <value>` 312> Sets the child's memory.swappiness to the specified value (only if memcg is mounted), 313 which must be equal or greater than 0. 314 315`namespace <pid|mnt>` 316> Enter a new PID or mount namespace when forking the service. 317 318`oneshot` 319> Do not restart the service when it exits. 320 321`onrestart` 322> Execute a Command (see below) when service restarts. 323 324`oom_score_adjust <value>` 325> Sets the child's /proc/self/oom\_score\_adj to the specified value, 326 which must range from -1000 to 1000. 327 328`override` 329> Indicates that this service definition is meant to override a previous definition for a service 330 with the same name. This is typically meant for services on /odm to override those defined on 331 /vendor. The last service definition that init parses with this keyword is the service definition 332 will use for this service. Pay close attention to the order in which init.rc files are parsed, 333 since it has some peculiarities for backwards compatibility reasons. The 'imports' section of 334 this file has more details on the order. 335 336`priority <priority>` 337> Scheduling priority of the service process. This value has to be in range 338 -20 to 19. Default priority is 0. Priority is set via setpriority(). 339 340`reboot_on_failure <target>` 341> If this process cannot be started or if the process terminates with an exit code other than 342 CLD_EXITED or an status other than '0', reboot the system with the target specified in 343 _target_. _target_ takes the same format as the parameter to sys.powerctl. This is particularly 344 intended to be used with the `exec_start` builtin for any must-have checks during boot. 345 346`restart_period <seconds>` 347> If a non-oneshot service exits, it will be restarted at its start time plus 348 this period. It defaults to 5s to rate limit crashing services. 349 This can be increased for services that are meant to run periodically. For 350 example, it may be set to 3600 to indicate that the service should run every hour 351 or 86400 to indicate that the service should run every day. 352 353`rlimit <resource> <cur> <max>` 354> This applies the given rlimit to the service. rlimits are inherited by child 355 processes, so this effectively applies the given rlimit to the process tree 356 started by this service. 357 It is parsed similarly to the setrlimit command specified below. 358 359`seclabel <seclabel>` 360> Change to 'seclabel' before exec'ing this service. 361 Primarily for use by services run from the rootfs, e.g. ueventd, adbd. 362 Services on the system partition can instead use policy-defined transitions 363 based on their file security context. 364 If not specified and no transition is defined in policy, defaults to the init context. 365 366`setenv <name> <value>` 367> Set the environment variable _name_ to _value_ in the launched process. 368 369`shutdown <shutdown_behavior>` 370> Set shutdown behavior of the service process. When this is not specified, 371 the service is killed during shutdown process by using SIGTERM and SIGKILL. 372 The service with shutdown_behavior of "critical" is not killed during shutdown 373 until shutdown times out. When shutdown times out, even services tagged with 374 "shutdown critical" will be killed. When the service tagged with "shutdown critical" 375 is not running when shut down starts, it will be started. 376 377`sigstop` 378> Send SIGSTOP to the service immediately before exec is called. This is intended for debugging. 379 See the below section on debugging for how this can be used. 380 381`socket <name> <type> <perm> [ <user> [ <group> [ <seclabel> ] ] ]` 382> Create a UNIX domain socket named /dev/socket/_name_ and pass its fd to the 383 launched process. The socket is created synchronously when the service starts. 384 _type_ must be "dgram", "stream" or "seqpacket". _type_ may end with "+passcred" 385 to enable SO_PASSCRED on the socket or "+listen" to synchronously make it a listening socket. 386 User and group default to 0. 'seclabel' is the SELinux security context for the 387 socket. It defaults to the service security context, as specified by 388 seclabel or computed based on the service executable file security context. 389 For native executables see libcutils android\_get\_control\_socket(). 390 391`stdio_to_kmsg` 392> Redirect stdout and stderr to /dev/kmsg_debug. This is useful for services that do not use native 393 Android logging during early boot and whose logs messages we want to capture. This is only enabled 394 when /dev/kmsg_debug is enabled, which is only enabled on userdebug and eng builds. 395 This is mutually exclusive with the console option, which additionally connects stdin to the 396 given console. 397 398`task_profiles <profile> [ <profile>\* ]` 399> Set task profiles. Before Android U, the profiles are applied to the main thread of the service. 400 For Android U and later, the profiles are applied to the entire service process. This is designed 401 to replace the use of writepid option for moving a process into a cgroup. 402 403`timeout_period <seconds>` 404> Provide a timeout after which point the service will be killed. The oneshot keyword is respected 405 here, so oneshot services do not automatically restart, however all other services will. 406 This is particularly useful for creating a periodic service combined with the restart_period 407 option described above. 408 409`updatable` 410> Mark that the service can be overridden (via the 'override' option) later in 411 the boot sequence by APEXes. When a service with updatable option is started 412 before APEXes are all activated, the execution is delayed until the activation 413 is finished. A service that is not marked as updatable cannot be overridden by 414 APEXes. 415 416`user <username>` 417> Change to 'username' before exec'ing this service. 418 Currently defaults to root. (??? probably should default to nobody) 419 As of Android M, processes should use this option even if they 420 require Linux capabilities. Previously, to acquire Linux 421 capabilities, a process would need to run as root, request the 422 capabilities, then drop to its desired uid. There is a new 423 mechanism through fs\_config that allows device manufacturers to add 424 Linux capabilities to specific binaries on a file system that should 425 be used instead. This mechanism is described on 426 <http://source.android.com/devices/tech/config/filesystem.html>. When 427 using this new mechanism, processes can use the user option to 428 select their desired uid without ever running as root. 429 As of Android O, processes can also request capabilities directly in their .rc 430 files. See the "capabilities" option above. 431 432`writepid <file> [ <file>\* ]` 433> Write the child's pid to the given files when it forks. Meant for 434 cgroup/cpuset usage. If no files under /dev/cpuset/ are specified, but the 435 system property 'ro.cpuset.default' is set to a non-empty cpuset name (e.g. 436 '/foreground'), then the pid is written to file /dev/cpuset/_cpuset\_name_/tasks. 437 The use of this option for moving a process into a cgroup is obsolete. Please 438 use task_profiles option instead. 439 440 441Triggers 442-------- 443Triggers are strings which can be used to match certain kinds of 444events and used to cause an action to occur. 445 446Triggers are subdivided into event triggers and property triggers. 447 448Event triggers are strings triggered by the 'trigger' command or by 449the QueueEventTrigger() function within the init executable. These 450take the form of a simple string such as 'boot' or 'late-init'. 451 452Property triggers are strings triggered when a named property changes 453value to a given new value or when a named property changes value to 454any new value. These take the form of 'property:<name>=<value>' and 455'property:<name>=\*' respectively. Property triggers are additionally 456evaluated and triggered accordingly during the initial boot phase of 457init. 458 459An Action can have multiple property triggers but may only have one 460event trigger. 461 462For example: 463`on boot && property:a=b` defines an action that is only executed when 464the 'boot' event trigger happens and the property a equals b at the moment. This 465will NOT be executed when the property a transitions to value b after the `boot` 466event was triggered. 467 468`on property:a=b && property:c=d` defines an action that is executed 469at three times: 470 471 1. During initial boot if property a=b and property c=d. 472 2. Any time that property a transitions to value b, while property c already equals d. 473 3. Any time that property c transitions to value d, while property a already equals b. 474 475 476Trigger Sequence 477---------------- 478 479Init uses the following sequence of triggers during early boot. These are the 480built-in triggers defined in init.cpp. 481 482 1. `early-init` - The first in the sequence, triggered after cgroups has been configured 483 but before ueventd's coldboot is complete. 484 2. `init` - Triggered after coldboot is complete. 485 3. `charger` - Triggered if `ro.bootmode == "charger"`. 486 4. `late-init` - Triggered if `ro.bootmode != "charger"`, or via healthd triggering a boot 487 from charging mode. 488 489Remaining triggers are configured in `init.rc` and are not built-in. The default sequence for 490these is specified under the "on late-init" event in `init.rc`. Actions internal to `init.rc` 491have been omitted. 492 493 1. `early-fs` - Start vold. 494 2. `fs` - Vold is up. Mount partitions not marked as first-stage or latemounted. 495 3. `post-fs` - Configure anything dependent on early mounts. 496 4. `late-fs` - Mount partitions marked as latemounted. 497 5. `post-fs-data` - Mount and configure `/data`; set up encryption. `/metadata` is 498 reformatted here if it couldn't mount in first-stage init. 499 6. `zygote-start` - Start the zygote. 500 7. `early-boot` - After zygote has started. 501 8. `boot` - After `early-boot` actions have completed. 502 503Commands 504-------- 505 506`bootchart [start|stop]` 507> Start/stop bootcharting. These are present in the default init.rc files, 508 but bootcharting is only active if the file /data/bootchart/enabled exists; 509 otherwise bootchart start/stop are no-ops. 510 511`chmod <octal-mode> <path>` 512> Change file access permissions. 513 514`chown <owner> <group> <path>` 515> Change file owner and group. 516 517`class_start <serviceclass>` 518> Start all services of the specified class if they are 519 not already running. See the start entry for more information on 520 starting services. 521 522`class_stop <serviceclass>` 523> Stop and disable all services of the specified class if they are 524 currently running. 525 526`class_reset <serviceclass>` 527> Stop all services of the specified class if they are 528 currently running, without disabling them. They can be restarted 529 later using `class_start`. 530 531`class_restart [--only-enabled] <serviceclass>` 532> Restarts all services of the specified class. If `--only-enabled` is 533 specified, then disabled services are skipped. 534 535`copy <src> <dst>` 536> Copies a file. Similar to write, but useful for binary/large 537 amounts of data. 538 Regarding to the src file, copying from symbolic link file and world-writable 539 or group-writable files are not allowed. 540 Regarding to the dst file, the default mode created is 0600 if it does not 541 exist. And it will be truncated if dst file is a normal regular file and 542 already exists. 543 544`copy_per_line <src> <dst>` 545> Copies a file line by line. Similar to copy, but useful for dst is a sysfs node 546 that doesn't handle multiple lines of data. 547 548`domainname <name>` 549> Set the domain name. 550 551`enable <servicename>` 552> Turns a disabled service into an enabled one as if the service did not 553 specify disabled. 554 If the service is supposed to be running, it will be started now. 555 Typically used when the bootloader sets a variable that indicates a specific 556 service should be started when needed. E.g. 557 558 on property:ro.boot.myfancyhardware=1 559 enable my_fancy_service_for_my_fancy_hardware 560 561`exec [ <seclabel> [ <user> [ <group>\* ] ] ] -- <command> [ <argument>\* ]` 562> Fork and execute command with the given arguments. The command starts 563 after "--" so that an optional security context, user, and supplementary 564 groups can be provided. No other commands will be run until this one 565 finishes. _seclabel_ can be a - to denote default. Properties are expanded 566 within _argument_. 567 Init halts executing commands until the forked process exits. 568 569`exec_background [ <seclabel> [ <user> [ <group>\* ] ] ] -- <command> [ <argument>\* ]` 570> Fork and execute command with the given arguments. This is handled similarly 571 to the `exec` command. The difference is that init does not halt executing 572 commands until the process exits for `exec_background`. 573 574`exec_start <service>` 575> Start a given service and halt the processing of additional init commands 576 until it returns. The command functions similarly to the `exec` command, 577 but uses an existing service definition in place of the exec argument vector. 578 579`export <name> <value>` 580> Set the environment variable _name_ equal to _value_ in the 581 global environment (which will be inherited by all processes 582 started after this command is executed) 583 584`hostname <name>` 585> Set the host name. 586 587`ifup <interface>` 588> Bring the network interface _interface_ online. 589 590`insmod [-f] <path> [<options>]` 591> Install the module at _path_ with the specified options. 592 -f: force installation of the module even if the version of the running kernel 593 and the version of the kernel for which the module was compiled do not match. 594 595`interface_start <name>` \ 596`interface_restart <name>` \ 597`interface_stop <name>` 598> Find the service that provides the interface _name_ if it exists and run the `start`, `restart`, 599or `stop` commands on it respectively. _name_ may be either a fully qualified HIDL name, in which 600case it is specified as `<interface>/<instance>`, or an AIDL name, in which case it is specified as 601`aidl/<interface>` for example `android.hardware.secure_element@1.1::ISecureElement/eSE1` or 602`aidl/aidl_lazy_test_1`. 603 604> Note that these commands only act on interfaces specified by the `interface` service option, not 605on interfaces registered at runtime. 606 607> Example usage of these commands: \ 608`interface_start android.hardware.secure_element@1.1::ISecureElement/eSE1` 609will start the HIDL Service that provides the `android.hardware.secure_element@1.1` and `eSI1` 610instance. \ 611`interface_start aidl/aidl_lazy_test_1` will start the AIDL service that 612provides the `aidl_lazy_test_1` interface. 613 614`load_exports <path>` 615> Open the file at _path_ and export global environment variables declared 616 there. Each line must be in the format `export <name> <value>`, as described 617 above. 618 619`load_system_props` 620> (This action is deprecated and no-op.) 621 622`load_persist_props` 623> Loads persistent properties when /data has been decrypted. 624 This is included in the default init.rc. 625 626`loglevel <level>` 627> Sets init's log level to the integer level, from 7 (all logging) to 0 628 (fatal logging only). The numeric values correspond to the kernel log 629 levels, but this command does not affect the kernel log level. Use the 630 `write` command to write to `/proc/sys/kernel/printk` to change that. 631 Properties are expanded within _level_. 632 633`mark_post_data` 634> Used to mark the point right after /data is mounted. 635 636`mkdir <path> [<mode>] [<owner>] [<group>] [encryption=<action>] [key=<key>]` 637> Create a directory at _path_, optionally with the given mode, owner, and 638 group. If not provided, the directory is created with permissions 755 and 639 owned by the root user and root group. If provided, the mode, owner and group 640 will be updated if the directory exists already. 641 If the directory does not exist, it will receive the security context from 642 the current SELinux policy or its parent if not specified in the policy. If 643 the directory exists, its security context will not be changed (even if 644 different from the policy). 645> 646> _action_ can be one of: 647> * `None`: take no encryption action; directory will be encrypted if parent is. 648> * `Require`: encrypt directory, abort boot process if encryption fails 649> * `Attempt`: try to set an encryption policy, but continue if it fails 650> * `DeleteIfNecessary`: recursively delete directory if necessary to set 651> encryption policy. 652> 653> _key_ can be one of: 654> * `ref`: use the systemwide DE key 655> * `per_boot_ref`: use the key freshly generated on each boot. 656 657`mount_all [ <fstab> ] [--<option>]` 658> Calls fs\_mgr\_mount\_all on the given fs\_mgr-format fstab with optional 659 options "early" and "late". 660 With "--early" set, the init executable will skip mounting entries with 661 "latemount" flag and triggering fs encryption state event. With "--late" set, 662 init executable will only mount entries with "latemount" flag. By default, 663 no option is set, and mount\_all will process all entries in the given fstab. 664 If the fstab parameter is not specified, fstab.${ro.boot.fstab_suffix}, 665 fstab.${ro.hardware} or fstab.${ro.hardware.platform} will be scanned for 666 under /odm/etc, /vendor/etc, or / at runtime, in that order. 667 668`mount <type> <device> <dir> [ <flag>\* ] [<options>]` 669> Attempt to mount the named device at the directory _dir_ 670 _flag_s include "ro", "rw", "remount", "noatime", ... 671 _options_ include "barrier=1", "noauto\_da\_alloc", "discard", ... as 672 a comma separated string, e.g. barrier=1,noauto\_da\_alloc 673 674`perform_apex_config` 675> Performs tasks after APEXes are mounted. For example, creates data directories 676 for the mounted APEXes, parses config file(s) from them, and updates linker 677 configurations. Intended to be used only once when apexd notifies the mount 678 event by setting `apexd.status` to ready. 679 680`restart [--only-if-running] <service>` 681> Stops and restarts a running service, does nothing if the service is currently 682 restarting, otherwise, it just starts the service. If "--only-if-running" is 683 specified, the service is only restarted if it is already running. 684 685`restorecon <path> [ <path>\* ]` 686> Restore the file named by _path_ to the security context specified 687 in the file\_contexts configuration. 688 Not required for directories created by the init.rc as these are 689 automatically labeled correctly by init. 690 691`restorecon_recursive <path> [ <path>\* ]` 692> Recursively restore the directory tree named by _path_ to the 693 security contexts specified in the file\_contexts configuration. 694 695`rm <path>` 696> Calls unlink(2) on the given path. You might want to 697 use "exec -- rm ..." instead (provided the system partition is 698 already mounted). 699 700`rmdir <path>` 701> Calls rmdir(2) on the given path. 702 703`readahead <file|dir> [--fully]` 704> Calls readahead(2) on the file or files within given directory. 705 Use option --fully to read the full file content. 706 707`setprop <name> <value>` 708> Set system property _name_ to _value_. Properties are expanded 709 within _value_. 710 711`setrlimit <resource> <cur> <max>` 712> Set the rlimit for a resource. This applies to all processes launched after 713 the limit is set. It is intended to be set early in init and applied globally. 714 _resource_ is best specified using its text representation ('cpu', 'rtio', etc 715 or 'RLIM_CPU', 'RLIM_RTIO', etc). It also may be specified as the int value 716 that the resource enum corresponds to. 717 _cur_ and _max_ can be 'unlimited' or '-1' to indicate an infinite rlimit. 718 719`start <service>` 720> Start a service running if it is not already running. 721 Note that this is _not_ synchronous, and even if it were, there is 722 no guarantee that the operating system's scheduler will execute the 723 service sufficiently to guarantee anything about the service's status. 724 See the `exec_start` command for a synchronous version of `start`. 725 726> This creates an important consequence that if the service offers 727 functionality to other services, such as providing a 728 communication channel, simply starting this service before those 729 services is _not_ sufficient to guarantee that the channel has 730 been set up before those services ask for it. There must be a 731 separate mechanism to make any such guarantees. 732 733`stop <service>` 734> Stop a service from running if it is currently running. 735 736`swapon_all [ <fstab> ]` 737> Calls fs\_mgr\_swapon\_all on the given fstab file. 738 If the fstab parameter is not specified, fstab.${ro.boot.fstab_suffix}, 739 fstab.${ro.hardware} or fstab.${ro.hardware.platform} will be scanned for 740 under /odm/etc, /vendor/etc, or / at runtime, in that order. 741 742`symlink <target> <path>` 743> Create a symbolic link at _path_ with the value _target_ 744 745`sysclktz <minutes_west_of_gmt>` 746> Set the system clock base (0 if system clock ticks in GMT) 747 748`trigger <event>` 749> Trigger an event. Used to queue an action from another 750 action. 751 752`umount <path>` 753> Unmount the filesystem mounted at that path. 754 755`umount_all [ <fstab> ]` 756> Calls fs\_mgr\_umount\_all on the given fstab file. 757 If the fstab parameter is not specified, fstab.${ro.boot.fstab_suffix}, 758 fstab.${ro.hardware} or fstab.${ro.hardware.platform} will be scanned for 759 under /odm/etc, /vendor/etc, or / at runtime, in that order. 760 761`verity_update_state` 762> Internal implementation detail used to update dm-verity state and 763 set the partition._mount-point_.verified properties used by adb remount 764 because fs\_mgr can't set them directly itself. This is required since 765 Android 12, because CtsNativeVerifiedBootTestCases will read property 766 "partition.${partition}.verified.hash_alg" to check that sha1 is not used. 767 See https://r.android.com/1546980 for more details. 768 769`wait <path> [ <timeout> ]` 770> Poll for the existence of the given file and return when found, 771 or the timeout has been reached. If timeout is not specified it 772 currently defaults to five seconds. The timeout value can be 773 fractional seconds, specified in floating point notation. 774 775`wait_for_prop <name> <value>` 776> Wait for system property _name_ to be _value_. Properties are expanded 777 within _value_. If property _name_ is already set to _value_, continue 778 immediately. 779 780`write <path> <content>` 781> Open the file at _path_ and write a string to it with write(2). 782 If the file does not exist, it will be created. If it does exist, 783 it will be truncated. Properties are expanded within _content_. 784 785 786Imports 787------- 788`import <path>` 789> Parse an init config file, extending the current configuration. 790 If _path_ is a directory, each file in the directory is parsed as 791 a config file. It is not recursive, nested directories will 792 not be parsed. 793 794The import keyword is not a command, but rather its own section, 795meaning that it does not happen as part of an Action, but rather, 796imports are handled as a file is being parsed and follow the below logic. 797 798There are only three times where the init executable imports .rc files: 799 800 1. When it imports `/system/etc/init/hw/init.rc` or the script indicated by the property 801 `ro.boot.init_rc` during initial boot. 802 2. When it imports `/{system,system_ext,vendor,odm,product}/etc/init/` immediately after 803 importing `/system/etc/init/hw/init.rc`. 804 3. (Deprecated) When it imports /{system,vendor,odm}/etc/init/ or .rc files 805 at specified paths during mount_all, not allowed for devices launching 806 after Q. 807 808The order that files are imported is a bit complex for legacy reasons. The below is guaranteed: 809 8101. `/system/etc/init/hw/init.rc` is parsed then recursively each of its imports are 811 parsed. 8122. The contents of `/system/etc/init/` are alphabetized and parsed sequentially, with imports 813 happening recursively after each file is parsed. 8143. Step 2 is repeated for `/system_ext/etc/init`, `/vendor/etc/init`, `/odm/etc/init`, 815 `/product/etc/init` 816 817The below pseudocode may explain this more clearly: 818 819 fn Import(file) 820 Parse(file) 821 for (import : file.imports) 822 Import(import) 823 824 Import(/system/etc/init/hw/init.rc) 825 Directories = [/system/etc/init, /system_ext/etc/init, /vendor/etc/init, /odm/etc/init, /product/etc/init] 826 for (directory : Directories) 827 files = <Alphabetical order of directory's contents> 828 for (file : files) 829 Import(file) 830 831Actions are executed in the order that they are parsed. For example the `post-fs-data` action(s) 832in `/system/etc/init/hw/init.rc` are always the first `post-fs-data` action(s) to be executed in 833order of how they appear in that file. Then the `post-fs-data` actions of the imports of 834`/system/etc/init/hw/init.rc` in the order that they're imported, etc. 835 836Properties 837---------- 838Init provides state information with the following properties. 839 840`init.svc.<name>` 841> State of a named service ("stopped", "stopping", "running", "restarting") 842 843`dev.mnt.dev.<mount_point>`, `dev.mnt.blk.<mount_point>`, `dev.mnt.rootdisk.<mount_point>` 844> Block device base name associated with a *mount_point*. 845 The *mount_point* has / replaced by . and if referencing the root mount point 846 "/", it will use "/root". 847 `dev.mnt.dev.<mount_point>` indicates a block device attached to filesystems. 848 (e.g., dm-N or sdaN/mmcblk0pN to access `/sys/fs/ext4/${dev.mnt.dev.<mount_point>}/`) 849 850 `dev.mnt.blk.<mount_point>` indicates the disk partition to the above block device. 851 (e.g., sdaN / mmcblk0pN to access `/sys/class/block/${dev.mnt.blk.<mount_point>}/`) 852 853 `dev.mnt.rootdisk.<mount_point>` indicates the root disk to contain the above disk partition. 854 (e.g., sda / mmcblk0 to access `/sys/class/block/${dev.mnt.rootdisk.<mount_point>}/queue`) 855 856Init responds to properties that begin with `ctl.`. These properties take the format of 857`ctl.[<target>_]<command>` and the _value_ of the system property is used as a parameter. The 858_target_ is optional and specifies the service option that _value_ is meant to match with. There is 859only one option for _target_, `interface` which indicates that _value_ will refer to an interface 860that a service provides and not the service name itself. 861 862For example: 863 864`SetProperty("ctl.start", "logd")` will run the `start` command on `logd`. 865 866`SetProperty("ctl.interface_start", "aidl/aidl_lazy_test_1")` will run the `start` command on the 867service that exposes the `aidl aidl_lazy_test_1` interface. 868 869Note that these 870properties are only settable; they will have no value when read. 871 872The _commands_ are listed below. 873 874`start` \ 875`restart` \ 876`stop` \ 877These are equivalent to using the `start`, `restart`, and `stop` commands on the service specified 878by the _value_ of the property. 879 880`oneshot_on` and `oneshot_off` will turn on or off the _oneshot_ 881flag for the service specified by the _value_ of the property. This is 882particularly intended for services that are conditionally lazy HALs. When 883they are lazy HALs, oneshot must be on, otherwise oneshot should be off. 884 885`sigstop_on` and `sigstop_off` will turn on or off the _sigstop_ feature for the service 886specified by the _value_ of the property. See the _Debugging init_ section below for more details 887about this feature. 888 889Boot timing 890----------- 891Init records some boot timing information in system properties. 892 893`ro.boottime.init` 894> Time after boot in ns (via the CLOCK\_BOOTTIME clock) at which the first 895 stage of init started. 896 897`ro.boottime.init.first_stage` 898> How long in ns it took to run first stage. 899 900`ro.boottime.init.selinux` 901> How long in ns it took to run SELinux stage. 902 903`ro.boottime.init.modules` 904> How long in ms it took to load kernel modules. 905 906`ro.boottime.init.cold_boot_wait` 907> How long init waited for ueventd's coldboot phase to end. 908 909`ro.boottime.<service-name>` 910> Time after boot in ns (via the CLOCK\_BOOTTIME clock) that the service was 911 first started. 912 913 914Bootcharting 915------------ 916This version of init contains code to perform "bootcharting": generating log 917files that can be later processed by the tools provided by <http://www.bootchart.org/>. 918 919On the emulator, use the -bootchart _timeout_ option to boot with bootcharting 920activated for _timeout_ seconds. 921 922On a device: 923 924 adb shell 'touch /data/bootchart/enabled' 925 926Don't forget to delete this file when you're done collecting data! 927 928The log files are written to /data/bootchart/. A script is provided to 929retrieve them and create a bootchart.tgz file that can be used with the 930bootchart command-line utility: 931 932 sudo apt-get install pybootchartgui 933 # grab-bootchart.sh uses $ANDROID_SERIAL. 934 $ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh 935 936One thing to watch for is that the bootchart will show init as if it started 937running at 0s. You'll have to look at dmesg to work out when the kernel 938actually started init. 939 940 941Comparing two bootcharts 942------------------------ 943A handy script named compare-bootcharts.py can be used to compare the 944start/end time of selected processes. The aforementioned grab-bootchart.sh 945will leave a bootchart tarball named bootchart.tgz at /tmp/android-bootchart. 946If two such tarballs are preserved on the host machine under different 947directories, the script can list the timestamps differences. For example: 948 949Usage: system/core/init/compare-bootcharts.py _base-bootchart-dir_ _exp-bootchart-dir_ 950 951 process: baseline experiment (delta) - Unit is ms (a jiffy is 10 ms on the system) 952 ------------------------------------ 953 /init: 50 40 (-10) 954 /system/bin/surfaceflinger: 4320 4470 (+150) 955 /system/bin/bootanimation: 6980 6990 (+10) 956 zygote64: 10410 10640 (+230) 957 zygote: 10410 10640 (+230) 958 system_server: 15350 15150 (-200) 959 bootanimation ends at: 33790 31230 (-2560) 960 961 962Systrace 963-------- 964Systrace (<http://developer.android.com/tools/help/systrace.html>) can be 965used for obtaining performance analysis reports during boot 966time on userdebug or eng builds. 967 968Here is an example of trace events of "wm" and "am" categories: 969 970 $ANDROID_BUILD_TOP/external/chromium-trace/systrace.py \ 971 wm am --boot 972 973This command will cause the device to reboot. After the device is rebooted and 974the boot sequence has finished, the trace report is obtained from the device 975and written as trace.html on the host by hitting Ctrl+C. 976 977Limitation: recording trace events is started after persistent properties are loaded, so 978the trace events that are emitted before that are not recorded. Several 979services such as vold, surfaceflinger, and servicemanager are affected by this 980limitation since they are started before persistent properties are loaded. 981Zygote initialization and the processes that are forked from the zygote are not 982affected. 983 984 985Debugging init 986-------------- 987When a service starts from init, it may fail to `execv()` the service. This is not typical, and may 988point to an error happening in the linker as the new service is started. The linker in Android 989prints its logs to `logd` and `stderr`, so they are visible in `logcat`. If the error is encountered 990before it is possible to access `logcat`, the `stdio_to_kmsg` service option may be used to direct 991the logs that the linker prints to `stderr` to `kmsg`, where they can be read via a serial port. 992 993Launching init services without init is not recommended as init sets up a significant amount of 994environment (user, groups, security label, capabilities, etc) that is hard to replicate manually. 995 996If it is required to debug a service from its very start, the `sigstop` service option is added. 997This option will send SIGSTOP to a service immediately before calling exec. This gives a window 998where developers can attach a debugger, strace, etc before continuing the service with SIGCONT. 999 1000This flag can also be dynamically controlled via the ctl.sigstop_on and ctl.sigstop_off properties. 1001 1002Below is an example of dynamically debugging logd via the above: 1003 1004 stop logd 1005 setprop ctl.sigstop_on logd 1006 start logd 1007 ps -e | grep logd 1008 > logd 4343 1 18156 1684 do_signal_stop 538280 T init 1009 gdbclient.py -p 4343 1010 b main 1011 c 1012 c 1013 c 1014 > Breakpoint 1, main (argc=1, argv=0x7ff8c9a488) at system/core/logd/main.cpp:427 1015 1016Below is an example of doing the same but with strace 1017 1018 stop logd 1019 setprop ctl.sigstop_on logd 1020 start logd 1021 ps -e | grep logd 1022 > logd 4343 1 18156 1684 do_signal_stop 538280 T init 1023 strace -p 4343 1024 1025 (From a different shell) 1026 kill -SIGCONT 4343 1027 1028 > strace runs 1029 1030Host Init Script Verification 1031----------------------------- 1032 1033Init scripts are checked for correctness during build time. Specifically the below is checked. 1034 10351) Well formatted action, service and import sections, e.g. no actions without a preceding 'on' 1036line, and no extraneous lines after an 'import' statement. 10372) All commands map to a valid keyword and the argument count is within the correct range. 10383) All service options are valid. This is stricter than how commands are checked as the service 1039options' arguments are fully parsed, e.g. UIDs and GIDs must resolve. 1040 1041There are other parts of init scripts that are only parsed at runtime and therefore not checked 1042during build time, among them are the below. 1043 10441) The validity of the arguments of commands, e.g. no checking if file paths actually exist, if 1045SELinux would permit the operation, or if the UIDs and GIDs resolve. 10462) No checking if a service exists or has a valid SELinux domain defined 10473) No checking if a service has not been previously defined in a different init script. 1048 1049Early Init Boot Sequence 1050------------------------ 1051The early init boot sequence is broken up into three stages: first stage init, SELinux setup, and 1052second stage init. 1053 1054First stage init is responsible for setting up the bare minimum requirements to load the rest of the 1055system. Specifically this includes mounting /dev, /proc, mounting 'early mount' partitions (which 1056needs to include all partitions that contain system code, for example system and vendor), and moving 1057the system.img mount to / for devices with a ramdisk. 1058 1059Note that in Android Q, system.img always contains TARGET_ROOT_OUT and always is mounted at / by the 1060time first stage init finishes. Android Q will also require dynamic partitions and therefore will 1061require using a ramdisk to boot Android. The recovery ramdisk can be used to boot to Android instead 1062of a dedicated ramdisk as well. 1063 1064First stage init has three variations depending on the device configuration: 10651) For system-as-root devices, first stage init is part of /system/bin/init and a symlink at /init 1066points to /system/bin/init for backwards compatibility. These devices do not need to do anything to 1067mount system.img, since it is by definition already mounted as the rootfs by the kernel. 1068 10692) For devices with a ramdisk, first stage init is a static executable located at /init. These 1070devices mount system.img as /system then perform a switch root operation to move the mount at 1071/system to /. The contents of the ramdisk are freed after mounting has completed. 1072 10733) For devices that use recovery as a ramdisk, first stage init it contained within the shared init 1074located at /init within the recovery ramdisk. These devices first switch root to 1075/first_stage_ramdisk to remove the recovery components from the environment, then proceed the same 1076as 2). Note that the decision to boot normally into Android instead of booting 1077into recovery mode is made if androidboot.force_normal_boot=1 is present in the 1078kernel commandline, or in bootconfig with Android S and later. 1079 1080Once first stage init finishes it execs /system/bin/init with the "selinux_setup" argument. This 1081phase is where SELinux is optionally compiled and loaded onto the system. selinux.cpp contains more 1082information on the specifics of this process. 1083 1084Lastly once that phase finishes, it execs /system/bin/init again with the "second_stage" 1085argument. At this point the main phase of init runs and continues the boot process via the init.rc 1086scripts. 1087