Lines Matching refs:init
17 required, such as `import /init.recovery.${ro.hardware}.rc`.
30 The init language is used in plain text files that take the .rc file
34 `/system/etc/init/hw/init.rc` is the primary .rc file and is loaded by the init executable at the
38 `/{system,system_ext,vendor,odm,product}/etc/init/` directories immediately after loading
39 the primary `/system/etc/init/hw/init.rc`. This is explained in more details in the
43 able to import init scripts during mount_all, however that is deprecated
48 1. /system/etc/init/ is for core system items such as
50 2. /vendor/etc/init/ is for SoC vendor items such as actions or
52 3. /odm/etc/init/ is for device manufacturer items such as
58 corresponding init .rc file, located in the /etc/init/
61 init .rc file should additionally contain any actions associated with
66 Android.mk file places logcatd.rc in /system/etc/init/ during the
71 This break up of init .rc files according to their daemon is preferred
72 to the previously used monolithic init .rc files. This approach
73 ensures that the only service entries that init reads and the only
74 actions that init performs correspond to services whose binaries are in
76 monolithic init .rc files. This additionally will aid in merge
84 modules carry their own init.rc files within their boundaries. Init
90 the SDK version information in the name of the init file. The suffix
92 RC 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
98 1. init.rc
99 2. init.32rc
100 4. init.35rc
107 process init.rc. When installed on a device running SDK 32, 33, or 34,
108 it will use init.32rc. When installed on a device running SDKs >= 35,
109 it will choose init.35rc
111 This versioning scheme is used only for the init files within APEX
112 modules; it does not apply to the init files stored in /system/etc/init,
113 /vendor/etc/init, or other directories.
190 Services are programs which init launches and (optionally) restarts
201 Options are modifiers to services. They affect how and when init
243 `init.svc_debug.no_fatal.<service-name>` to `true` for specified critical service.
293 to "123,124,125". Since keycodes are handled very early in init,
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,
364 If not specified and no transition is defined in policy, defaults to the init context.
449 the QueueEventTrigger() function within the init executable. These
450 take the form of a simple string such as 'boot' or 'late-init'.
457 init.
480 built-in triggers defined in init.cpp.
482 1. `early-init` - The first in the sequence, triggered after cgroups has been configured
484 2. `init` - Triggered after coldboot is complete.
486 4. `late-init` - Triggered if `ro.bootmode != "charger"`, or via healthd triggering a boot
489 Remaining triggers are configured in `init.rc` and are not built-in. The default sequence for
490 these is specified under the "on late-init" event in `init.rc`. Actions internal to `init.rc`
498 reformatted here if it couldn't mount in first-stage init.
507 > Start/stop bootcharting. These are present in the default init.rc files,
571 to the `exec` command. The difference is that init does not halt executing
575 > Start a given service and halt the processing of additional init commands
624 This is included in the default init.rc.
627 > Sets init's log level to the integer level, from 7 (all logging) to 0
660 With "--early" set, the init executable will skip mounting entries with
662 init executable will only mount entries with "latemount" flag. By default,
688 Not required for directories created by the init.rc as these are
689 automatically labeled correctly by init.
713 the limit is set. It is intended to be set early in init and applied globally.
789 > Parse an init config file, extending the current configuration.
798 There are only three times where the init executable imports .rc files:
800 1. When it imports `/system/etc/init/hw/init.rc` or the script indicated by the property
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
810 1. `/system/etc/init/hw/init.rc` is parsed then recursively each of its imports are
812 2. The contents of `/system/etc/init/` are alphabetized and parsed sequentially, with imports
814 3. Step 2 is repeated for `/system_ext/etc/init`, `/vendor/etc/init`, `/odm/etc/init`,
815 `/product/etc/init`
824 Import(/system/etc/init/hw/init.rc)
825 …Directories = [/system/etc/init, /system_ext/etc/init, /vendor/etc/init, /odm/etc/init, /product/e…
832 in `/system/etc/init/hw/init.rc` are always the first `post-fs-data` action(s) to be executed in
834 `/system/etc/init/hw/init.rc` in the order that they're imported, etc.
840 `init.svc.<name>`
893 `ro.boottime.init`
895 stage of init started.
897 `ro.boottime.init.first_stage`
900 `ro.boottime.init.selinux`
903 `ro.boottime.init.modules`
906 `ro.boottime.init.cold_boot_wait`
907 > How long init waited for ueventd's coldboot phase to end.
916 This version of init contains code to perform "bootcharting": generating log
934 $ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh
936 One thing to watch for is that the bootchart will show init as if it started
938 actually started init.
949 Usage: system/core/init/compare-bootcharts.py _base-bootchart-dir_ _exp-bootchart-dir_
953 /init: 50 40 (-10)
985 Debugging init
987 When a service starts from init, it may fail to `execv()` the service. This is not typical, and may
993 Launching init services without init is not recommended as init sets up a significant amount of
1008 > logd 4343 1 18156 1684 do_signal_stop 538280 T init
1022 > logd 4343 1 18156 1684 do_signal_stop 538280 T init
1041 There are other parts of init scripts that are only parsed at runtime and therefore not checked
1047 3) No checking if a service has not been previously defined in a different init script.
1051 The early init boot sequence is broken up into three stages: first stage init, SELinux setup, and
1052 second stage init.
1054 First stage init is responsible for setting up the bare minimum requirements to load the rest of the
1060 time first stage init finishes. Android Q will also require dynamic partitions and therefore will
1064 First stage init has three variations depending on the device configuration:
1065 1) For system-as-root devices, first stage init is part of /system/bin/init and a symlink at /init
1066 points to /system/bin/init for backwards compatibility. These devices do not need to do anything to
1069 2) For devices with a ramdisk, first stage init is a static executable located at /init. These
1073 3) For devices that use recovery as a ramdisk, first stage init it contained within the shared init
1074 located at /init within the recovery ramdisk. These devices first switch root to
1080 Once first stage init finishes it execs /system/bin/init with the "selinux_setup" argument. This
1084 Lastly once that phase finishes, it execs /system/bin/init again with the "second_stage"
1085 argument. At this point the main phase of init runs and continues the boot process via the init.rc