Name |
Date |
Size |
#Lines |
LOC |
||
---|---|---|---|---|---|---|
.. | - | - | ||||
parser/ | 03-May-2024 | - | 435 | 301 | ||
Android.mk | D | 03-May-2024 | 2.7 KiB | 132 | 102 | |
MODULE_LICENSE_APACHE2 | D | 03-May-2024 | 0 | |||
NOTICE | D | 03-May-2024 | 10.4 KiB | 191 | 158 | |
action.cpp | D | 03-May-2024 | 12.5 KiB | 429 | 334 | |
action.h | D | 03-May-2024 | 4.2 KiB | 134 | 98 | |
bootchart.cpp | D | 03-May-2024 | 8.1 KiB | 275 | 201 | |
bootchart.h | D | 03-May-2024 | 826 | 27 | 7 | |
builtins.cpp | D | 03-May-2024 | 32.2 KiB | 1,041 | 791 | |
builtins.h | D | 03-May-2024 | 978 | 36 | 15 | |
compare-bootcharts.py | D | 03-May-2024 | 5.3 KiB | 147 | 89 | |
devices.cpp | D | 03-May-2024 | 26.7 KiB | 1,004 | 789 | |
devices.h | D | 03-May-2024 | 1 KiB | 31 | 11 | |
grab-bootchart.sh | D | 03-May-2024 | 636 | 23 | 13 | |
import_parser.cpp | D | 03-May-2024 | 1.6 KiB | 56 | 32 | |
import_parser.h | D | 03-May-2024 | 1.3 KiB | 44 | 23 | |
init.cpp | D | 03-May-2024 | 22.8 KiB | 756 | 549 | |
init.h | D | 03-May-2024 | 1.2 KiB | 45 | 18 | |
init_parser.cpp | D | 03-May-2024 | 4.6 KiB | 155 | 117 | |
init_parser.h | D | 03-May-2024 | 1.7 KiB | 56 | 32 | |
init_parser_test.cpp | D | 03-May-2024 | 4.2 KiB | 136 | 100 | |
keychords.cpp | D | 03-May-2024 | 3.4 KiB | 116 | 81 | |
keychords.h | D | 03-May-2024 | 760 | 26 | 6 | |
keyword_map.h | D | 03-May-2024 | 2.6 KiB | 78 | 47 | |
log.cpp | D | 03-May-2024 | 2.1 KiB | 70 | 40 | |
log.h | D | 03-May-2024 | 1.2 KiB | 33 | 12 | |
parser.cpp | D | 03-May-2024 | 3.1 KiB | 142 | 127 | |
parser.h | D | 03-May-2024 | 1.1 KiB | 41 | 20 | |
perfboot.py | D | 03-May-2024 | 15.8 KiB | 463 | 352 | |
property_service.cpp | D | 03-May-2024 | 15.9 KiB | 539 | 398 | |
property_service.h | D | 03-May-2024 | 1.1 KiB | 40 | 18 | |
readme.txt | D | 03-May-2024 | 19 KiB | 520 | 399 | |
service.cpp | D | 03-May-2024 | 26.3 KiB | 863 | 694 | |
service.h | D | 03-May-2024 | 7.5 KiB | 209 | 154 | |
signal_handler.cpp | D | 03-May-2024 | 2.1 KiB | 76 | 45 | |
signal_handler.h | D | 03-May-2024 | 726 | 23 | 4 | |
ueventd.cpp | D | 03-May-2024 | 4.1 KiB | 173 | 120 | |
ueventd.h | D | 03-May-2024 | 1,013 | 40 | 17 | |
ueventd_keywords.h | D | 03-May-2024 | 356 | 16 | 15 | |
ueventd_parser.cpp | D | 03-May-2024 | 6 KiB | 242 | 194 | |
ueventd_parser.h | D | 03-May-2024 | 925 | 29 | 8 | |
util.cpp | D | 03-May-2024 | 14.8 KiB | 580 | 444 | |
util.h | D | 03-May-2024 | 2.1 KiB | 71 | 42 | |
util_test.cpp | D | 03-May-2024 | 1.2 KiB | 44 | 23 | |
watchdogd.cpp | D | 03-May-2024 | 2 KiB | 73 | 46 | |
watchdogd.h | D | 03-May-2024 | 727 | 23 | 4 |
readme.txt
1Android Init Language 2--------------------- 3 4The Android Init Language consists of five broad classes of statements, 5which are Actions, 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 15Actions and Services implicitly declare a new section. All commands 16or options belong to the section most recently declared. Commands 17or options before the first section are ignored. 18 19Actions and Services have unique names. If a second Action is defined 20with the same name as an existing one, its commands are appended to 21the commands of the existing action. If a second Service is defined 22with the same name as an existing one, it is ignored and an error 23message is logged. 24 25 26Init .rc Files 27-------------- 28The init language is used in plaintext files that take the .rc file 29extension. These are typically multiple of these in multiple 30locations on the system, described below. 31 32/init.rc is the primary .rc file and is loaded by the init executable 33at the beginning of its execution. It is responsible for the initial 34set up of the system. It imports /init.${ro.hardware}.rc which is the 35primary vendor supplied .rc file. 36 37During the mount_all command, the init executable loads all of the 38files contained within the /{system,vendor,odm}/etc/init/ directories. 39These directories are intended for all Actions and Services used after 40file system mounting. 41 42One may specify paths in the mount_all command line to have it import 43.rc files at the specified paths instead of the default ones listed above. 44This is primarily for supporting factory mode and other non-standard boot 45modes. The three default paths should be used for the normal boot process. 46 47The intention of these directories is as follows 48 1) /system/etc/init/ is for core system items such as 49 SurfaceFlinger, MediaService, and logcatd. 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 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 80There are two options "early" and "late" in mount_all command 81which can be set after optional paths. With "--early" set, the 82init executable will skip mounting entries with "latemount" flag 83and triggering fs encryption state event. With "--late" set, 84init executable will only mount entries with "latemount" flag but skip 85importing rc files. By default, no option is set, and mount_all will 86mount_all will process all entries in the given fstab. 87 88Actions 89------- 90Actions are named sequences of commands. Actions have a trigger which 91is used to determine when the action should occur. When an event 92occurs which matches an action's trigger, that action is added to 93the tail of a to-be-executed queue (unless it is already on the 94queue). 95 96Each action in the queue is dequeued in sequence and each command in 97that action is executed in sequence. Init handles other activities 98(device creation/destruction, property setting, process restarting) 99"between" the execution of the commands in activities. 100 101Actions take the form of: 102 103on <trigger> [&& <trigger>]* 104 <command> 105 <command> 106 <command> 107 108 109Services 110-------- 111Services are programs which init launches and (optionally) restarts 112when they exit. Services take the form of: 113 114service <name> <pathname> [ <argument> ]* 115 <option> 116 <option> 117 ... 118 119 120Options 121------- 122Options are modifiers to services. They affect how and when init 123runs the service. 124 125critical 126 This is a device-critical service. If it exits more than four times in 127 four minutes, the device will reboot into recovery mode. 128 129disabled 130 This service will not automatically start with its class. 131 It must be explicitly started by name. 132 133setenv <name> <value> 134 Set the environment variable <name> to <value> in the launched process. 135 136socket <name> <type> <perm> [ <user> [ <group> [ <seclabel> ] ] ] 137 Create a unix domain socket named /dev/socket/<name> and pass 138 its fd to the launched process. <type> must be "dgram", "stream" or "seqpacket". 139 User and group default to 0. 140 'seclabel' is the SELinux security context for the socket. 141 It defaults to the service security context, as specified by seclabel or 142 computed based on the service executable file security context. 143 144user <username> 145 Change to username before exec'ing this service. 146 Currently defaults to root. (??? probably should default to nobody) 147 As of Android M, processes should use this option even if they 148 require linux capabilities. Previously, to acquire linux 149 capabilities, a process would need to run as root, request the 150 capabilities, then drop to its desired uid. There is a new 151 mechanism through fs_config that allows device manufacturers to add 152 linux capabilities to specific binaries on a file system that should 153 be used instead. This mechanism is described on 154 http://source.android.com/devices/tech/config/filesystem.html. When 155 using this new mechanism, processes can use the user option to 156 select their desired uid without ever running as root. 157 158group <groupname> [ <groupname> ]* 159 Change to groupname before exec'ing this service. Additional 160 groupnames beyond the (required) first one are used to set the 161 supplemental groups of the process (via setgroups()). 162 Currently defaults to root. (??? probably should default to nobody) 163 164seclabel <seclabel> 165 Change to 'seclabel' before exec'ing this service. 166 Primarily for use by services run from the rootfs, e.g. ueventd, adbd. 167 Services on the system partition can instead use policy-defined transitions 168 based on their file security context. 169 If not specified and no transition is defined in policy, defaults to the init context. 170 171oneshot 172 Do not restart the service when it exits. 173 174class <name> 175 Specify a class name for the service. All services in a 176 named class may be started or stopped together. A service 177 is in the class "default" if one is not specified via the 178 class option. 179 180onrestart 181 Execute a Command (see below) when service restarts. 182 183writepid <file...> 184 Write the child's pid to the given files when it forks. Meant for 185 cgroup/cpuset usage. 186 187 188Triggers 189-------- 190Triggers are strings which can be used to match certain kinds of 191events and used to cause an action to occur. 192 193Triggers are subdivided into event triggers and property triggers. 194 195Event triggers are strings triggered by the 'trigger' command or by 196the QueueEventTrigger() function within the init executable. These 197take the form of a simple string such as 'boot' or 'late-init'. 198 199Property triggers are strings triggered when a named property changes 200value to a given new value or when a named property changes value to 201any new value. These take the form of 'property:<name>=<value>' and 202'property:<name>=*' respectively. Property triggers are additionally 203evaluated and triggered accordingly during the initial boot phase of 204init. 205 206An Action can have multiple property triggers but may only have one 207event trigger. 208 209For example: 210'on boot && property:a=b' defines an action that is only executed when 211the 'boot' event trigger happens and the property a equals b. 212 213'on property:a=b && property:c=d' defines an action that is executed 214at three times, 215 1) During initial boot if property a=b and property c=d 216 2) Any time that property a transitions to value b, while property 217 c already equals d. 218 3) Any time that property c transitions to value d, while property 219 a already equals b. 220 221 222Commands 223-------- 224 225bootchart_init 226 Start bootcharting if configured (see below). 227 This is included in the default init.rc. 228 229chmod <octal-mode> <path> 230 Change file access permissions. 231 232chown <owner> <group> <path> 233 Change file owner and group. 234 235class_start <serviceclass> 236 Start all services of the specified class if they are 237 not already running. 238 239class_stop <serviceclass> 240 Stop and disable all services of the specified class if they are 241 currently running. 242 243class_reset <serviceclass> 244 Stop all services of the specified class if they are 245 currently running, without disabling them. They can be restarted 246 later using class_start. 247 248copy <src> <dst> 249 Copies a file. Similar to write, but useful for binary/large 250 amounts of data. 251 252domainname <name> 253 Set the domain name. 254 255enable <servicename> 256 Turns a disabled service into an enabled one as if the service did not 257 specify disabled. 258 If the service is supposed to be running, it will be started now. 259 Typically used when the bootloader sets a variable that indicates a specific 260 service should be started when needed. E.g. 261 on property:ro.boot.myfancyhardware=1 262 enable my_fancy_service_for_my_fancy_hardware 263 264exec [ <seclabel> [ <user> [ <group> ]* ] ] -- <command> [ <argument> ]* 265 Fork and execute command with the given arguments. The command starts 266 after "--" so that an optional security context, user, and supplementary 267 groups can be provided. No other commands will be run until this one 268 finishes. <seclabel> can be a - to denote default. 269 270export <name> <value> 271 Set the environment variable <name> equal to <value> in the 272 global environment (which will be inherited by all processes 273 started after this command is executed) 274 275hostname <name> 276 Set the host name. 277 278ifup <interface> 279 Bring the network interface <interface> online. 280 281insmod <path> 282 Install the module at <path> 283 284load_all_props 285 Loads properties from /system, /vendor, et cetera. 286 This is included in the default init.rc. 287 288load_persist_props 289 Loads persistent properties when /data has been decrypted. 290 This is included in the default init.rc. 291 292loglevel <level> 293 Sets the kernel log level to level. Properties are expanded within <level>. 294 295mkdir <path> [mode] [owner] [group] 296 Create a directory at <path>, optionally with the given mode, owner, and 297 group. If not provided, the directory is created with permissions 755 and 298 owned by the root user and root group. If provided, the mode, owner and group 299 will be updated if the directory exists already. 300 301mount_all <fstab> [ <path> ]* [--<option>] 302 Calls fs_mgr_mount_all on the given fs_mgr-format fstab and imports .rc files 303 at the specified paths (e.g., on the partitions just mounted) with optional 304 options "early" and "late". 305 Refer to the section of "Init .rc Files" for detail. 306 307mount <type> <device> <dir> [ <flag> ]* [<options>] 308 Attempt to mount the named device at the directory <dir> 309 <device> may be of the form mtd@name to specify a mtd block 310 device by name. 311 <flag>s include "ro", "rw", "remount", "noatime", ... 312 <options> include "barrier=1", "noauto_da_alloc", "discard", ... as 313 a comma separated string, eg: barrier=1,noauto_da_alloc 314 315powerctl 316 Internal implementation detail used to respond to changes to the 317 "sys.powerctl" system property, used to implement rebooting. 318 319restart <service> 320 Like stop, but doesn't disable the service. 321 322restorecon <path> [ <path> ]* 323 Restore the file named by <path> to the security context specified 324 in the file_contexts configuration. 325 Not required for directories created by the init.rc as these are 326 automatically labeled correctly by init. 327 328restorecon_recursive <path> [ <path> ]* 329 Recursively restore the directory tree named by <path> to the 330 security contexts specified in the file_contexts configuration. 331 332rm <path> 333 Calls unlink(2) on the given path. You might want to 334 use "exec -- rm ..." instead (provided the system partition is 335 already mounted). 336 337rmdir <path> 338 Calls rmdir(2) on the given path. 339 340setprop <name> <value> 341 Set system property <name> to <value>. Properties are expanded 342 within <value>. 343 344setrlimit <resource> <cur> <max> 345 Set the rlimit for a resource. 346 347start <service> 348 Start a service running if it is not already running. 349 350stop <service> 351 Stop a service from running if it is currently running. 352 353swapon_all <fstab> 354 Calls fs_mgr_swapon_all on the given fstab file. 355 356symlink <target> <path> 357 Create a symbolic link at <path> with the value <target> 358 359sysclktz <mins_west_of_gmt> 360 Set the system clock base (0 if system clock ticks in GMT) 361 362trigger <event> 363 Trigger an event. Used to queue an action from another 364 action. 365 366umount <path> 367 Unmount the filesystem mounted at that path. 368 369verity_load_state 370 Internal implementation detail used to load dm-verity state. 371 372verity_update_state <mount_point> 373 Internal implementation detail used to update dm-verity state and 374 set the partition.<mount_point>.verified properties used by adb remount 375 because fs_mgr can't set them directly itself. 376 377wait <path> [ <timeout> ] 378 Poll for the existence of the given file and return when found, 379 or the timeout has been reached. If timeout is not specified it 380 currently defaults to five seconds. 381 382write <path> <content> 383 Open the file at <path> and write a string to it with write(2). 384 If the file does not exist, it will be created. If it does exist, 385 it will be truncated. Properties are expanded within <content>. 386 387 388Imports 389------- 390The import keyword is not a command, but rather its own section and is 391handled immediately after the .rc file that contains it has finished 392being parsed. It takes the below form: 393 394import <path> 395 Parse an init config file, extending the current configuration. 396 If <path> is a directory, each file in the directory is parsed as 397 a config file. It is not recursive, nested directories will 398 not be parsed. 399 400There are only two times where the init executable imports .rc files, 401 1) When it imports /init.rc during initial boot 402 2) When it imports /{system,vendor,odm}/etc/init/ or .rc files at specified 403 paths during mount_all 404 405 406Properties 407---------- 408Init provides information about the services that it is responsible 409for via the below properties. 410 411init.svc.<name> 412 State of a named service ("stopped", "stopping", "running", "restarting") 413 414 415Bootcharting 416------------ 417This version of init contains code to perform "bootcharting": generating log 418files that can be later processed by the tools provided by www.bootchart.org. 419 420On the emulator, use the -bootchart <timeout> option to boot with bootcharting 421activated for <timeout> seconds. 422 423On a device, create /data/bootchart/start with a command like the following: 424 425 adb shell 'echo $TIMEOUT > /data/bootchart/start' 426 427Where the value of $TIMEOUT corresponds to the desired bootcharted period in 428seconds. Bootcharting will stop after that many seconds have elapsed. 429You can also stop the bootcharting at any moment by doing the following: 430 431 adb shell 'echo 1 > /data/bootchart/stop' 432 433Note that /data/bootchart/stop is deleted automatically by init at the end of 434the bootcharting. This is not the case with /data/bootchart/start, so don't 435forget to delete it when you're done collecting data. 436 437The log files are written to /data/bootchart/. A script is provided to 438retrieve them and create a bootchart.tgz file that can be used with the 439bootchart command-line utility: 440 441 sudo apt-get install pybootchartgui 442 # grab-bootchart.sh uses $ANDROID_SERIAL. 443 $ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh 444 445One thing to watch for is that the bootchart will show init as if it started 446running at 0s. You'll have to look at dmesg to work out when the kernel 447actually started init. 448 449 450Comparing two bootcharts 451------------------------ 452A handy script named compare-bootcharts.py can be used to compare the 453start/end time of selected processes. The aforementioned grab-bootchart.sh 454will leave a bootchart tarball named bootchart.tgz at /tmp/android-bootchart. 455If two such barballs are preserved on the host machine under different 456directories, the script can list the timestamps differences. For example: 457 458Usage: system/core/init/compare-bootcharts.py base_bootchart_dir 459 exp_bootchart_dir 460 461process: baseline experiment (delta) 462 - Unit is ms (a jiffy is 10 ms on the system) 463------------------------------------ 464/init: 50 40 (-10) 465/system/bin/surfaceflinger: 4320 4470 (+150) 466/system/bin/bootanimation: 6980 6990 (+10) 467zygote64: 10410 10640 (+230) 468zygote: 10410 10640 (+230) 469system_server: 15350 15150 (-200) 470bootanimation ends at: 33790 31230 (-2560) 471 472 473Systrace 474-------- 475Systrace [1] can be used for obtaining performance analysis reports during boot 476time on userdebug or eng builds. 477Here is an example of trace events of "wm" and "am" categories: 478 479 $ANDROID_BUILD_TOP/external/chromium-trace/systrace.py wm am --boot 480 481This command will cause the device to reboot. After the device is rebooted and 482the boot sequence has finished, the trace report is obtained from the device 483and written as trace.html on the host by hitting Ctrl+C. 484 485LIMITATION 486Recording trace events is started after persistent properties are loaded, so 487the trace events that are emitted before that are not recorded. Several 488services such as vold, surfaceflinger, and servicemanager are affected by this 489limitation since they are started before persistent properties are loaded. 490Zygote initialization and the processes that are forked from the zygote are not 491affected. 492 493[1] http://developer.android.com/tools/help/systrace.html 494 495 496Debugging init 497-------------- 498By default, programs executed by init will drop stdout and stderr into 499/dev/null. To help with debugging, you can execute your program via the 500Android program logwrapper. This will redirect stdout/stderr into the 501Android logging system (accessed via logcat). 502 503For example 504service akmd /system/bin/logwrapper /sbin/akmd 505 506For quicker turnaround when working on init itself, use: 507 508 mm -j 509 m ramdisk-nodeps 510 m bootimage-nodeps 511 adb reboot bootloader 512 fastboot boot $ANDROID_PRODUCT_OUT/boot.img 513 514Alternatively, use the emulator: 515 516 emulator -partition-size 1024 -verbose -show-kernel -no-window 517 518You might want to call klog_set_level(6) after the klog_init() call 519so you see the kernel logging in dmesg (or the emulator output). 520