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/init.rc is the primary .rc file and is loaded by the init executable 35at the beginning of its execution. It is responsible for the initial 36set up of the system. 37 38Devices that mount /system, /vendor through the first stage mount mechanism 39load all of the files contained within the 40/{system,vendor,odm}/etc/init/ directories immediately after loading 41the primary /init.rc. This is explained in more details in the 42Imports section of this file. 43 44Legacy devices without the first stage mount mechanism do the following: 451. /init.rc imports /init.${ro.hardware}.rc which is the primary 46 vendor supplied .rc file. 472. During the mount\_all command, the init executable loads all of the 48 files contained within the /{system,vendor,odm}/etc/init/ directories. 49 These directories are intended for all Actions and Services used after 50 file system mounting. 51 52One may specify paths in the mount\_all command line to have it import 53.rc files at the specified paths instead of the default ones listed above. 54This is primarily for supporting factory mode and other non-standard boot 55modes. The three default paths should be used for the normal boot process. 56 57The intention of these directories is: 58 59 1. /system/etc/init/ is for core system items such as 60 SurfaceFlinger, MediaService, and logcatd. 61 2. /vendor/etc/init/ is for SoC vendor items such as actions or 62 daemons needed for core SoC functionality. 63 3. /odm/etc/init/ is for device manufacturer items such as 64 actions or daemons needed for motion sensor or other peripheral 65 functionality. 66 67All services whose binaries reside on the system, vendor, or odm 68partitions should have their service entries placed into a 69corresponding init .rc file, located in the /etc/init/ 70directory of the partition where they reside. There is a build 71system macro, LOCAL\_INIT\_RC, that handles this for developers. Each 72init .rc file should additionally contain any actions associated with 73its service. 74 75An example is the logcatd.rc and Android.mk files located in the 76system/core/logcat directory. The LOCAL\_INIT\_RC macro in the 77Android.mk file places logcatd.rc in /system/etc/init/ during the 78build process. Init loads logcatd.rc during the mount\_all command and 79allows the service to be run and the action to be queued when 80appropriate. 81 82This break up of init .rc files according to their daemon is preferred 83to the previously used monolithic init .rc files. This approach 84ensures that the only service entries that init reads and the only 85actions that init performs correspond to services whose binaries are in 86fact present on the file system, which was not the case with the 87monolithic init .rc files. This additionally will aid in merge 88conflict resolution when multiple services are added to the system, as 89each one will go into a separate file. 90 91There are two options "early" and "late" in mount\_all command 92which can be set after optional paths. With "--early" set, the 93init executable will skip mounting entries with "latemount" flag 94and triggering fs encryption state event. With "--late" set, 95init executable will only mount entries with "latemount" flag but skip 96importing rc files. By default, no option is set, and mount\_all will 97process all entries in the given fstab. 98 99Actions 100------- 101Actions are named sequences of commands. Actions have a trigger which 102is used to determine when the action is executed. When an event 103occurs which matches an action's trigger, that action is added to 104the tail of a to-be-executed queue (unless it is already on the 105queue). 106 107Each action in the queue is dequeued in sequence and each command in 108that action is executed in sequence. Init handles other activities 109(device creation/destruction, property setting, process restarting) 110"between" the execution of the commands in activities. 111 112Actions take the form of: 113 114 on <trigger> [&& <trigger>]* 115 <command> 116 <command> 117 <command> 118 119Actions are added to the queue and executed based on the order that 120the file that contains them was parsed (see the Imports section), then 121sequentially within an individual file. 122 123For example if a file contains: 124 125 on boot 126 setprop a 1 127 setprop b 2 128 129 on boot && property:true=true 130 setprop c 1 131 setprop d 2 132 133 on boot 134 setprop e 1 135 setprop f 2 136 137Then when the `boot` trigger occurs and assuming the property `true` 138equals `true`, then the order of the commands executed will be: 139 140 setprop a 1 141 setprop b 2 142 setprop c 1 143 setprop d 2 144 setprop e 1 145 setprop f 2 146 147 148Services 149-------- 150Services are programs which init launches and (optionally) restarts 151when they exit. Services take the form of: 152 153 service <name> <pathname> [ <argument> ]* 154 <option> 155 <option> 156 ... 157 158 159Options 160------- 161Options are modifiers to services. They affect how and when init 162runs the service. 163 164`console [<console>]` 165> This service needs a console. The optional second parameter chooses a 166 specific console instead of the default. The default "/dev/console" can 167 be changed by setting the "androidboot.console" kernel parameter. In 168 all cases the leading "/dev/" should be omitted, so "/dev/tty0" would be 169 specified as just "console tty0". 170 171`critical` 172> This is a device-critical service. If it exits more than four times in 173 four minutes, the device will reboot into recovery mode. 174 175`disabled` 176> This service will not automatically start with its class. 177 It must be explicitly started by name. 178 179`setenv <name> <value>` 180> Set the environment variable _name_ to _value_ in the launched process. 181 182`socket <name> <type> <perm> [ <user> [ <group> [ <seclabel> ] ] ]` 183> Create a unix domain socket named /dev/socket/_name_ and pass its fd to the 184 launched process. _type_ must be "dgram", "stream" or "seqpacket". User and 185 group default to 0. 'seclabel' is the SELinux security context for the 186 socket. It defaults to the service security context, as specified by 187 seclabel or computed based on the service executable file security context. 188 For native executables see libcutils android\_get\_control\_socket(). 189 190`enter_namespace <type> <path>` 191> Enters the namespace of type _type_ located at _path_. Only network namespaces are supported with 192 _type_ set to "net". Note that only one namespace of a given _type_ may be entered. 193 194`file <path> <type>` 195> Open a file path and pass its fd to the launched process. _type_ must be 196 "r", "w" or "rw". For native executables see libcutils 197 android\_get\_control\_file(). 198 199`user <username>` 200> Change to 'username' before exec'ing this service. 201 Currently defaults to root. (??? probably should default to nobody) 202 As of Android M, processes should use this option even if they 203 require Linux capabilities. Previously, to acquire Linux 204 capabilities, a process would need to run as root, request the 205 capabilities, then drop to its desired uid. There is a new 206 mechanism through fs\_config that allows device manufacturers to add 207 Linux capabilities to specific binaries on a file system that should 208 be used instead. This mechanism is described on 209 <http://source.android.com/devices/tech/config/filesystem.html>. When 210 using this new mechanism, processes can use the user option to 211 select their desired uid without ever running as root. 212 As of Android O, processes can also request capabilities directly in their .rc 213 files. See the "capabilities" option below. 214 215`group <groupname> [ <groupname>\* ]` 216> Change to 'groupname' before exec'ing this service. Additional 217 groupnames beyond the (required) first one are used to set the 218 supplemental groups of the process (via setgroups()). 219 Currently defaults to root. (??? probably should default to nobody) 220 221`capabilities <capability> [ <capability>\* ]` 222> Set capabilities when exec'ing this service. 'capability' should be a Linux 223 capability without the "CAP\_" prefix, like "NET\_ADMIN" or "SETPCAP". See 224 http://man7.org/linux/man-pages/man7/capabilities.7.html for a list of Linux 225 capabilities. 226 227`setrlimit <resource> <cur> <max>` 228> This applies the given rlimit to the service. rlimits are inherited by child 229 processes, so this effectively applies the given rlimit to the process tree 230 started by this service. 231 It is parsed similarly to the setrlimit command specified below. 232 233`seclabel <seclabel>` 234> Change to 'seclabel' before exec'ing this service. 235 Primarily for use by services run from the rootfs, e.g. ueventd, adbd. 236 Services on the system partition can instead use policy-defined transitions 237 based on their file security context. 238 If not specified and no transition is defined in policy, defaults to the init context. 239 240`oneshot` 241> Do not restart the service when it exits. 242 243`class <name> [ <name>\* ]` 244> Specify class names for the service. All services in a 245 named class may be started or stopped together. A service 246 is in the class "default" if one is not specified via the 247 class option. Additional classnames beyond the (required) first 248 one are used to group services. 249`animation class` 250> 'animation' class should include all services necessary for both 251 boot animation and shutdown animation. As these services can be 252 launched very early during bootup and can run until the last stage 253 of shutdown, access to /data partition is not guaranteed. These 254 services can check files under /data but it should not keep files opened 255 and should work when /data is not available. 256 257`onrestart` 258> Execute a Command (see below) when service restarts. 259 260`writepid <file> [ <file>\* ]` 261> Write the child's pid to the given files when it forks. Meant for 262 cgroup/cpuset usage. If no files under /dev/cpuset/ are specified, but the 263 system property 'ro.cpuset.default' is set to a non-empty cpuset name (e.g. 264 '/foreground'), then the pid is written to file /dev/cpuset/_cpuset\_name_/tasks. 265 266`priority <priority>` 267> Scheduling priority of the service process. This value has to be in range 268 -20 to 19. Default priority is 0. Priority is set via setpriority(). 269 270`namespace <pid|mnt>` 271> Enter a new PID or mount namespace when forking the service. 272 273`oom_score_adjust <value>` 274> Sets the child's /proc/self/oom\_score\_adj to the specified value, 275 which must range from -1000 to 1000. 276 277`memcg.swappiness <value>` 278> Sets the child's memory.swappiness to the specified value (only if memcg is mounted), 279 which must be equal or greater than 0. 280 281`memcg.soft_limit_in_bytes <value>` 282> Sets the child's memory.soft_limit_in_bytes to the specified value (only if memcg is mounted), 283 which must be equal or greater than 0. 284 285`memcg.limit_in_bytes <value>` 286> Sets the child's memory.limit_in_bytes to the specified value (only if memcg is mounted), 287 which must be equal or greater than 0. 288 289`shutdown <shutdown_behavior>` 290> Set shutdown behavior of the service process. When this is not specified, 291 the service is killed during shutdown process by using SIGTERM and SIGKILL. 292 The service with shutdown_behavior of "critical" is not killed during shutdown 293 until shutdown times out. When shutdown times out, even services tagged with 294 "shutdown critical" will be killed. When the service tagged with "shutdown critical" 295 is not running when shut down starts, it will be started. 296 297 298Triggers 299-------- 300Triggers are strings which can be used to match certain kinds of 301events and used to cause an action to occur. 302 303Triggers are subdivided into event triggers and property triggers. 304 305Event triggers are strings triggered by the 'trigger' command or by 306the QueueEventTrigger() function within the init executable. These 307take the form of a simple string such as 'boot' or 'late-init'. 308 309Property triggers are strings triggered when a named property changes 310value to a given new value or when a named property changes value to 311any new value. These take the form of 'property:<name>=<value>' and 312'property:<name>=\*' respectively. Property triggers are additionally 313evaluated and triggered accordingly during the initial boot phase of 314init. 315 316An Action can have multiple property triggers but may only have one 317event trigger. 318 319For example: 320`on boot && property:a=b` defines an action that is only executed when 321the 'boot' event trigger happens and the property a equals b. 322 323`on property:a=b && property:c=d` defines an action that is executed 324at three times: 325 326 1. During initial boot if property a=b and property c=d. 327 2. Any time that property a transitions to value b, while property c already equals d. 328 3. Any time that property c transitions to value d, while property a already equals b. 329 330 331Commands 332-------- 333 334`bootchart [start|stop]` 335> Start/stop bootcharting. These are present in the default init.rc files, 336 but bootcharting is only active if the file /data/bootchart/enabled exists; 337 otherwise bootchart start/stop are no-ops. 338 339`chmod <octal-mode> <path>` 340> Change file access permissions. 341 342`chown <owner> <group> <path>` 343> Change file owner and group. 344 345`class_start <serviceclass>` 346> Start all services of the specified class if they are 347 not already running. See the start entry for more information on 348 starting services. 349 350`class_stop <serviceclass>` 351> Stop and disable all services of the specified class if they are 352 currently running. 353 354`class_reset <serviceclass>` 355> Stop all services of the specified class if they are 356 currently running, without disabling them. They can be restarted 357 later using `class_start`. 358 359`class_restart <serviceclass>` 360> Restarts all services of the specified class. 361 362`copy <src> <dst>` 363> Copies a file. Similar to write, but useful for binary/large 364 amounts of data. 365 Regarding to the src file, copying from symbolic link file and world-writable 366 or group-writable files are not allowed. 367 Regarding to the dst file, the default mode created is 0600 if it does not 368 exist. And it will be truncated if dst file is a normal regular file and 369 already exists. 370 371`domainname <name>` 372> Set the domain name. 373 374`enable <servicename>` 375> Turns a disabled service into an enabled one as if the service did not 376 specify disabled. 377 If the service is supposed to be running, it will be started now. 378 Typically used when the bootloader sets a variable that indicates a specific 379 service should be started when needed. E.g. 380 381 on property:ro.boot.myfancyhardware=1 382 enable my_fancy_service_for_my_fancy_hardware 383 384`exec [ <seclabel> [ <user> [ <group>\* ] ] ] -- <command> [ <argument>\* ]` 385> Fork and execute command with the given arguments. The command starts 386 after "--" so that an optional security context, user, and supplementary 387 groups can be provided. No other commands will be run until this one 388 finishes. _seclabel_ can be a - to denote default. Properties are expanded 389 within _argument_. 390 Init halts executing commands until the forked process exits. 391 392`exec_background [ <seclabel> [ <user> [ <group>\* ] ] ] -- <command> [ <argument>\* ]` 393> Fork and execute command with the given arguments. This is handled similarly 394 to the `exec` command. The difference is that init does not halt executing 395 commands until the process exits for `exec_background`. 396 397`exec_start <service>` 398> Start a given service and halt the processing of additional init commands 399 until it returns. The command functions similarly to the `exec` command, 400 but uses an existing service definition in place of the exec argument vector. 401 402`export <name> <value>` 403> Set the environment variable _name_ equal to _value_ in the 404 global environment (which will be inherited by all processes 405 started after this command is executed) 406 407`hostname <name>` 408> Set the host name. 409 410`ifup <interface>` 411> Bring the network interface _interface_ online. 412 413`insmod [-f] <path> [<options>]` 414> Install the module at _path_ with the specified options. 415 -f: force installation of the module even if the version of the running kernel 416 and the version of the kernel for which the module was compiled do not match. 417 418`load_all_props` 419> Loads properties from /system, /vendor, et cetera. 420 This is included in the default init.rc. 421 422`load_persist_props` 423> Loads persistent properties when /data has been decrypted. 424 This is included in the default init.rc. 425 426`loglevel <level>` 427> Sets the kernel log level to level. Properties are expanded within _level_. 428 429`mkdir <path> [mode] [owner] [group]` 430> Create a directory at _path_, optionally with the given mode, owner, and 431 group. If not provided, the directory is created with permissions 755 and 432 owned by the root user and root group. If provided, the mode, owner and group 433 will be updated if the directory exists already. 434 435`mount_all <fstab> [ <path> ]\* [--<option>]` 436> Calls fs\_mgr\_mount\_all on the given fs\_mgr-format fstab and imports .rc files 437 at the specified paths (e.g., on the partitions just mounted) with optional 438 options "early" and "late". 439 Refer to the section of "Init .rc Files" for detail. 440 441`mount <type> <device> <dir> [ <flag>\* ] [<options>]` 442> Attempt to mount the named device at the directory _dir_ 443 _flag_s include "ro", "rw", "remount", "noatime", ... 444 _options_ include "barrier=1", "noauto\_da\_alloc", "discard", ... as 445 a comma separated string, eg: barrier=1,noauto\_da\_alloc 446 447`restart <service>` 448> Stops and restarts a running service, does nothing if the service is currently 449 restarting, otherwise, it just starts the service. 450 451`restorecon <path> [ <path>\* ]` 452> Restore the file named by _path_ to the security context specified 453 in the file\_contexts configuration. 454 Not required for directories created by the init.rc as these are 455 automatically labeled correctly by init. 456 457`restorecon_recursive <path> [ <path>\* ]` 458> Recursively restore the directory tree named by _path_ to the 459 security contexts specified in the file\_contexts configuration. 460 461`rm <path>` 462> Calls unlink(2) on the given path. You might want to 463 use "exec -- rm ..." instead (provided the system partition is 464 already mounted). 465 466`rmdir <path>` 467> Calls rmdir(2) on the given path. 468 469`readahead <file|dir> [--fully]` 470> Calls readahead(2) on the file or files within given directory. 471 Use option --fully to read the full file content. 472 473`setprop <name> <value>` 474> Set system property _name_ to _value_. Properties are expanded 475 within _value_. 476 477`setrlimit <resource> <cur> <max>` 478> Set the rlimit for a resource. This applies to all processes launched after 479 the limit is set. It is intended to be set early in init and applied globally. 480 _resource_ is best specified using its text representation ('cpu', 'rtio', etc 481 or 'RLIM_CPU', 'RLIM_RTIO', etc). It also may be specified as the int value 482 that the resource enum corresponds to. 483 484`start <service>` 485> Start a service running if it is not already running. 486 Note that this is _not_ synchronous, and even if it were, there is 487 no guarantee that the operating system's scheduler will execute the 488 service sufficiently to guarantee anything about the service's status. 489 490> This creates an important consequence that if the service offers 491 functionality to other services, such as providing a 492 communication channel, simply starting this service before those 493 services is _not_ sufficient to guarantee that the channel has 494 been set up before those services ask for it. There must be a 495 separate mechanism to make any such guarantees. 496 497`stop <service>` 498> Stop a service from running if it is currently running. 499 500`swapon_all <fstab>` 501> Calls fs\_mgr\_swapon\_all on the given fstab file. 502 503`symlink <target> <path>` 504> Create a symbolic link at _path_ with the value _target_ 505 506`sysclktz <mins_west_of_gmt>` 507> Set the system clock base (0 if system clock ticks in GMT) 508 509`trigger <event>` 510> Trigger an event. Used to queue an action from another 511 action. 512 513`umount <path>` 514> Unmount the filesystem mounted at that path. 515 516`verity_load_state` 517> Internal implementation detail used to load dm-verity state. 518 519`verity_update_state <mount-point>` 520> Internal implementation detail used to update dm-verity state and 521 set the partition._mount-point_.verified properties used by adb remount 522 because fs\_mgr can't set them directly itself. 523 524`wait <path> [ <timeout> ]` 525> Poll for the existence of the given file and return when found, 526 or the timeout has been reached. If timeout is not specified it 527 currently defaults to five seconds. 528 529`wait_for_prop <name> <value>` 530> Wait for system property _name_ to be _value_. Properties are expanded 531 within _value_. If property _name_ is already set to _value_, continue 532 immediately. 533 534`write <path> <content>` 535> Open the file at _path_ and write a string to it with write(2). 536 If the file does not exist, it will be created. If it does exist, 537 it will be truncated. Properties are expanded within _content_. 538 539 540Imports 541------- 542`import <path>` 543> Parse an init config file, extending the current configuration. 544 If _path_ is a directory, each file in the directory is parsed as 545 a config file. It is not recursive, nested directories will 546 not be parsed. 547 548The import keyword is not a command, but rather its own section, 549meaning that it does not happen as part of an Action, but rather, 550imports are handled as a file is being parsed and follow the below logic. 551 552There are only three times where the init executable imports .rc files: 553 554 1. When it imports /init.rc or the script indicated by the property 555 `ro.boot.init_rc` during initial boot. 556 2. When it imports /{system,vendor,odm}/etc/init/ for first stage mount 557 devices immediately after importing /init.rc. 558 3. When it imports /{system,vendor,odm}/etc/init/ or .rc files at specified 559 paths during mount_all. 560 561The order that files are imported is a bit complex for legacy reasons 562and to keep backwards compatibility. It is not strictly guaranteed. 563 564The only correct way to guarantee that a command has been run before a 565different command is to either 1) place it in an Action with an 566earlier executed trigger, or 2) place it in an Action with the same 567trigger within the same file at an earlier line. 568 569Nonetheless, the defacto order for first stage mount devices is: 5701. /init.rc is parsed then recursively each of its imports are 571 parsed. 5722. The contents of /system/etc/init/ are alphabetized and parsed 573 sequentially, with imports happening recursively after each file is 574 parsed. 5753. Step 2 is repeated for /vendor/etc/init then /odm/etc/init 576 577The below pseudocode may explain this more clearly: 578 579 fn Import(file) 580 Parse(file) 581 for (import : file.imports) 582 Import(import) 583 584 Import(/init.rc) 585 Directories = [/system/etc/init, /vendor/etc/init, /odm/etc/init] 586 for (directory : Directories) 587 files = <Alphabetical order of directory's contents> 588 for (file : files) 589 Import(file) 590 591 592Properties 593---------- 594Init provides information about the services that it is responsible 595for via the below properties. 596 597`init.svc.<name>` 598> State of a named service ("stopped", "stopping", "running", "restarting") 599 600 601Boot timing 602----------- 603Init records some boot timing information in system properties. 604 605`ro.boottime.init` 606> Time after boot in ns (via the CLOCK\_BOOTTIME clock) at which the first 607 stage of init started. 608 609`ro.boottime.init.selinux` 610> How long it took the first stage to initialize SELinux. 611 612`ro.boottime.init.cold_boot_wait` 613> How long init waited for ueventd's coldboot phase to end. 614 615`ro.boottime.<service-name>` 616> Time after boot in ns (via the CLOCK\_BOOTTIME clock) that the service was 617 first started. 618 619 620Bootcharting 621------------ 622This version of init contains code to perform "bootcharting": generating log 623files that can be later processed by the tools provided by <http://www.bootchart.org/>. 624 625On the emulator, use the -bootchart _timeout_ option to boot with bootcharting 626activated for _timeout_ seconds. 627 628On a device: 629 630 adb shell 'touch /data/bootchart/enabled' 631 632Don't forget to delete this file when you're done collecting data! 633 634The log files are written to /data/bootchart/. A script is provided to 635retrieve them and create a bootchart.tgz file that can be used with the 636bootchart command-line utility: 637 638 sudo apt-get install pybootchartgui 639 # grab-bootchart.sh uses $ANDROID_SERIAL. 640 $ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh 641 642One thing to watch for is that the bootchart will show init as if it started 643running at 0s. You'll have to look at dmesg to work out when the kernel 644actually started init. 645 646 647Comparing two bootcharts 648------------------------ 649A handy script named compare-bootcharts.py can be used to compare the 650start/end time of selected processes. The aforementioned grab-bootchart.sh 651will leave a bootchart tarball named bootchart.tgz at /tmp/android-bootchart. 652If two such barballs are preserved on the host machine under different 653directories, the script can list the timestamps differences. For example: 654 655Usage: system/core/init/compare-bootcharts.py _base-bootchart-dir_ _exp-bootchart-dir_ 656 657 process: baseline experiment (delta) - Unit is ms (a jiffy is 10 ms on the system) 658 ------------------------------------ 659 /init: 50 40 (-10) 660 /system/bin/surfaceflinger: 4320 4470 (+150) 661 /system/bin/bootanimation: 6980 6990 (+10) 662 zygote64: 10410 10640 (+230) 663 zygote: 10410 10640 (+230) 664 system_server: 15350 15150 (-200) 665 bootanimation ends at: 33790 31230 (-2560) 666 667 668Systrace 669-------- 670Systrace (<http://developer.android.com/tools/help/systrace.html>) can be 671used for obtaining performance analysis reports during boot 672time on userdebug or eng builds. 673 674Here is an example of trace events of "wm" and "am" categories: 675 676 $ANDROID_BUILD_TOP/external/chromium-trace/systrace.py \ 677 wm am --boot 678 679This command will cause the device to reboot. After the device is rebooted and 680the boot sequence has finished, the trace report is obtained from the device 681and written as trace.html on the host by hitting Ctrl+C. 682 683Limitation: recording trace events is started after persistent properties are loaded, so 684the trace events that are emitted before that are not recorded. Several 685services such as vold, surfaceflinger, and servicemanager are affected by this 686limitation since they are started before persistent properties are loaded. 687Zygote initialization and the processes that are forked from the zygote are not 688affected. 689 690 691Debugging init 692-------------- 693By default, programs executed by init will drop stdout and stderr into 694/dev/null. To help with debugging, you can execute your program via the 695Android program logwrapper. This will redirect stdout/stderr into the 696Android logging system (accessed via logcat). 697 698For example 699service akmd /system/bin/logwrapper /sbin/akmd 700 701For quicker turnaround when working on init itself, use: 702 703 mm -j && 704 m ramdisk-nodeps && 705 m bootimage-nodeps && 706 adb reboot bootloader && 707 fastboot boot $ANDROID_PRODUCT_OUT/boot.img 708 709Alternatively, use the emulator: 710 711 emulator -partition-size 1024 \ 712 -verbose -show-kernel -no-window 713