There is documentation for how AIDL works with ctl commands or
interface_start commands, however it seems we were missing documentation
on declaration of interfaces.
Bug: N/A
Test: N/A
Change-Id: I0e5d2350b6b847a870eafbc69828e75f1f6ca4f0
Load sysprops from /vendor_dlkm/build.prop. Note that
no property contexts are loaded from vendor_dlkm.
Test: getprop | grep vendor_dlkm
Bug: 156020364
Change-Id: Ib0e8ba1791e1d2c11d055ef496208993e11d9b0f
This restriction is only added for devices launching with R or later.
Bug: 160663765
Test: this test runs when appropriate
Change-Id: I2353bfa7f598bd19ba57498cc5bbad7a3ed34707
This allows init to easily ensure misc devices other than device-mapper
are present.
Bug: 154536437
Test: manual test
Change-Id: I49495684edee322f9787ce7ab7f79d0e8060171d
Now we have more things e.g. loading kernel modules, initialize
selinux. And before all these, system cannot make further progress. It
should be beneficial to boost this critical peroid in init.
Benchmark on a Pixel device shows this saves 100+ms on early boot
ToT release + This CL (P15538587)
D/BaseBootTest: init_stage_second_START_TIME_avg : 1563.4
D/BaseBootTest: ueventd_Coldboot_avg : 219.0
D/BaseBootTest: action_init_/system/etc/init/hw/init.rc:114_START_TIME_avg : 2103.7
ToT release (6654154)
D/BaseBootTest: init_stage_second_START_TIME_avg : 1639.0
D/BaseBootTest: ueventd_Coldboot_avg : 238.2
D/BaseBootTest: action_init_/system/etc/init/hw/init.rc:114_START_TIME_avg : 2226.0
Bug: 143857500
Bug: 147997403
Bug: 160271169
Bug: 160696502
Test: Boottime
Signed-off-by: Wei Wang <wvw@google.com>
Change-Id: I21c9e051f4ae3e953d991c031f151b2779702548
build.prop files under system_ext, product, and odm partitions are moved
to the ./etc subdirectory. This is to be in-line with the established
practice of having all configuration files under ./etc subdir.
build.prop doesn't need to be an exception.
However, system/build.prop and vendor/build.prop were not moved because
there are a lot of apps and tools that depend on the path.
Bug: 158735147
Test: device has build.prop under ./etc and is bootable
Change-Id: I26300574c23c78cc4e5bc20f98fc9702838465e1
If a device doesn't support unflattened APEXes, init activates flattened
APEXes instead of apexd.
Because apexd dumps apex-info-list.xml after it activates all APEXes,
init should do the same thing.
Bug: 159585065
Test: lunch aosp_cf_x86_phone_noapex & m & boot
adb more /apex/apex-info-list.xml
adb shell ls -lZ /apex/apex-info-list.xml
-> -rw-rw-rw- 1 root root u:object_r:apex_info_file:s0 ..
Change-Id: I74a4d0ee363761564225097c5949e5ce335ac6dc
AMBA specification from Arm is a freely available open
standard for the connection and management of functional
blocks in a system-on-chip.
AMBA devices create a device kernel object in /sys/devices/platform
and a kernel object of the bus for the respective device in
/sys/bus/amba. For e.g. for pl180 mmc:
device: /sys/devices/platform/1c050000.mmci
bus: /sys/bus/amba/devices/1c050000.mmci
In first stage init, android creates a symlink from /sys/devices/platform/...
to /dev/block/platform/... for all partitions and then to
/dev/block/by-name for the boot_device used. However this is only done
for devices that "attach" to bus/platform. This patch adds support for
platform devices that attach to bus/amba.
Signed-off-by: Usama Arif <usama.arif@arm.com>
Change-Id: I9da7456407c4f62335c959502d8b2d16026fddfc
Having mounted apexes with loop back devices backing files on /data
partition will prevent clean unmount of it. Unmounting them and tearing
down loop devices should minimize the risk of that.
Note that it won't fix the issue completely, as there are a few (~2-3)
processes that keep restarting even after SIGKILL is sent. Which means
that they can still hold references to apexes on /data partition. But
in practice probability of this is quite low.
Test: adb reboot
Test: put tzdata apex in /data/apex/active && adb reboot
Bug: 158152940
Change-Id: I4624567b3d0f304dba4c6e37b77abd89e57411de
Regardless of whether a system property is "ro." or not, it can be
overridden by build.prop from the more specific partition. i.e.
foo.bar=true in system/build.prop can be overridden by
foo.bar=false in vendor/build.prop. However, the warning message
was referring the overridden property as "ro." causing confusion
when reading the log. Fix it by not mentioning "ro.".
Bug: 117892318
Test: N/A
Change-Id: I13014522d0c6b507b30c8754e2087fd71cc39971
Init starts ueventd in the default mount namespace to support loading
firmware from APEXes.
Bug: 155023652
Test: devices boots
adb$ nsenter -t (pid of ueventd) -m ls /apex
=> shows all APEXes
Change-Id: Ibb8b33a07eb014752275e3bca4541b8b694dc64b
While mount_all and umount_all were updated to use ro.boot.fstab_suffix,
I neglected to update swapon_all. Trivially copied from umount_all.
Bug: 142424832
Change-Id: Icd706fe7a1fe16c687cd2811b0a3158d7d2e224e
Merged-In: Icd706fe7a1fe16c687cd2811b0a3158d7d2e224e
While mount_all and umount_all were updated to use ro.boot.fstab_suffix,
I neglected to update swapon_all. Trivially copied from umount_all.
Bug: 142424832
Change-Id: Icd706fe7a1fe16c687cd2811b0a3158d7d2e224e
The mount_all and swapon_all commands are documented, but umount_all
is not. Add some documentation.
Bug: 142424832
Change-Id: I7e4dcb4d222b787350a79c9e312062cac9eeb4d8
The mount_all and swapon_all commands are documented, but umount_all
is not. Add some documentation.
Bug: 142424832
Change-Id: I7e4dcb4d222b787350a79c9e312062cac9eeb4d8
Kernel modules may be located within directories in /lib/modules.
Attempt to load kernel modules from each directory that has a name starting with
the major and minor version of the currently running kernel. If a single
kernel module is successfully loaded from a directory, that directory is
treated as the correct kernel module directory for the system. No other
kernel module directories are searched and any kernel module load errors
in that directory are fatal. If the attempt to load the first kernel
module from a directory fails, or if there are no kernel modules in a
directory, then the search proceeds to the next directory.
If no kernel module is successfully loaded from any directory as above,
an attempt is made to load kernel modules from the top level at
/lib/modules/.
Bug: 157645635
Change-Id: I92eadd8617f03a645da460ccb776bc04fa541f00
Merged-In: I92eadd8617f03a645da460ccb776bc04fa541f00
Kernel modules may be located within directories in /lib/modules.
Attempt to load kernel modules from each directory that has a name starting with
the major and minor version of the currently running kernel. If a single
kernel module is successfully loaded from a directory, that directory is
treated as the correct kernel module directory for the system. No other
kernel module directories are searched and any kernel module load errors
in that directory are fatal. If the attempt to load the first kernel
module from a directory fails, or if there are no kernel modules in a
directory, then the search proceeds to the next directory.
If no kernel module is successfully loaded from any directory as above,
an attempt is made to load kernel modules from the top level at
/lib/modules/.
Bug: 157645635
Change-Id: I92eadd8617f03a645da460ccb776bc04fa541f00
To ensure we can shutdown cleanly, and don't hang an outstanding
requests to a FUSE host daemon that has already exited.
Bug: 153411204
Test: inspect logs during shutdown
Change-Id: I8e6479bd54dbc1fc85b087617aa6b16be9f15a3b
Currently the ReadDefaultFstab function, which calls GetFstabPath,
makes some assumptions about what the fstab will be called and where
it is located. This is being used by vold to set up userdata encryption
and for gsid, and is even used in the default boot control HAL, so it
has become quite baked.
The original way for a board to specify things to mount was to use the
"mount_all /path/to/fstab" command in init.rc. However, due to the
above functionality, the path after mount_all is no longer very useful,
as it cannot differ from the inferred path, or userdata encryption and
other features will be broken.
On Cuttlefish, we have an interest in being able to test alternative
userdata configurations (ext4 vs f2fs, encryption on/off, etc.) and
currently the only way to achieve this is to either a) modify the
ro.hardware or ro.hardware.platform properties, which breaks a bunch
of things like default HAL filenames, or regenerate our odm.img or
vendor.img filesystems. We can't simply install another fstab and
point to it with "mount_all".
This change allows the fstab path to be omitted from "mount_all", and
adds another property which overrides the existing checks for
fstab.${ro.hardware} and fstab.${ro.hardware.platform}. Specifying
${ro.boot.fstab_suffix} will cause fstab.${ro.boot.fstab_suffix}
to be checked first.
Bug: 142424832
Test: booted cuttlefish with 'mount_all ${ro.hardware} --late'
Test: booted cuttlefish with 'mount_all --late'
Test: booted cuttlefish with 'mount_all --late' and fstab_suffix=f2fs
Test: partially booted cuttlefish with 'mount_all ${ro.hardware}'
Test: partially booted cuttlefish with 'mount_all'
Change-Id: I3e10f66aecfcd48bdb9ebf1d304b7aae745cbd3c
Merged-In: I3e10f66aecfcd48bdb9ebf1d304b7aae745cbd3c
Currently the ReadDefaultFstab function, which calls GetFstabPath,
makes some assumptions about what the fstab will be called and where
it is located. This is being used by vold to set up userdata encryption
and for gsid, and is even used in the default boot control HAL, so it
has become quite baked.
The original way for a board to specify things to mount was to use the
"mount_all /path/to/fstab" command in init.rc. However, due to the
above functionality, the path after mount_all is no longer very useful,
as it cannot differ from the inferred path, or userdata encryption and
other features will be broken.
On Cuttlefish, we have an interest in being able to test alternative
userdata configurations (ext4 vs f2fs, encryption on/off, etc.) and
currently the only way to achieve this is to either a) modify the
ro.hardware or ro.hardware.platform properties, which breaks a bunch
of things like default HAL filenames, or regenerate our odm.img or
vendor.img filesystems. We can't simply install another fstab and
point to it with "mount_all".
This change allows the fstab path to be omitted from "mount_all", and
adds another property which overrides the existing checks for
fstab.${ro.hardware} and fstab.${ro.hardware.platform}. Specifying
${ro.boot.fstab_suffix} will cause fstab.${ro.boot.fstab_suffix}
to be checked first.
Bug: 142424832
Test: booted cuttlefish with 'mount_all ${ro.hardware} --late'
Test: booted cuttlefish with 'mount_all --late'
Test: booted cuttlefish with 'mount_all --late' and fstab_suffix=f2fs
Test: partially booted cuttlefish with 'mount_all ${ro.hardware}'
Test: partially booted cuttlefish with 'mount_all'
Change-Id: I3e10f66aecfcd48bdb9ebf1d304b7aae745cbd3c
A one second timeout is so coarse and can affect boot time when
the possibility that the file does not exist. Switch to accepting
a floating point number for seconds for the wait for file command.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 151950334
Test: wait_for_file sleep 0.05 reports an appropriate delay
Change-Id: I8d8ed386519ab54270b05ce91663d0add30f12e7
A one second timeout is so coarse and can affect boot time when
the possibility that the file does not exist. Switch to accepting
a floating point number for seconds for the wait for file command.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 151950334
Test: wait_for_file sleep 0.05 reports an appropriate delay
Change-Id: I8d8ed386519ab54270b05ce91663d0add30f12e7
