Currently, if init crashes, the kernel panics. During development, we
would like to catch this crash before the kernel panics and reboot
into bootloader. This will prevent boot looping bad configurations,
particularly desired in test labs where manual intervention would
otherwise be required to reset the devices.
Keep the existing behavior for user builds, as init crashes should be
rare for production builds and rebooting the device is the correct
behavior for end users.
Bug: 34147472
Test: Boot bullhead userdebug, force init to crash, check that the
device is in bootloader
Test: Boot bullhead user, force init to crash, check that the kernel
panics and the device reboots as it did previously
Change-Id: Iab3d45ed0d1f82ffaad2a0835d9ca537c0516421
Add reading of vendor file-system config files
/oem/etc/fs_config_dirs and /oem/etc/fs_config_files.
Order of interpretation (for dirs and files respectively):
- /system/etc/fs_config_dirs or /system/etc/fs_config_files
- /vendor/etc/fs_config_dirs or /vendor/etc/fs_config_files
- /oem/etc/fs_config_dirs or /oem/etc/fs_config_files
- internal android_dirs[] or android_files[] structures.
No restrictions are placed on the oem file-system config files,
although the developer is advised to restrict the scope to the /oem
file-system since the intent is to provide support only for
customized portions of oem.img.
Test: full build and install smoke test and inspection
Bug: 36071012
Change-Id: I56f3fed5efa44d622a9a110937dbc949083d44ae
Add reading of vendor file-system config files
/vendor/etc/fs_config_dirs and /vendor/etc/fs_config_files.
Order of interpretation (for dirs and files respectively):
- /system/etc/fs_config_dirs or /system/etc/fs_config_files
- /vendor/etc/fs_config_dirs or /vendor/etc/fs_config_files
- internal android_dirs[] or android_files[] structures.
No restrictions are placed on the vendor file-system config files,
although the developer is advised to restrict the scope to the /vendor
file-system since the intent is to provide support only for
customized portions of vendor.img.
Test: full build and install smoke test and inspection
Bug: 36071012
Change-Id: I4077bd6afcda2ee16189b2eb3c322af15205bbb9
Sort android_files[] first by requirements, grouping, specificity and
finally by alphanumeric order.
Test: full build and install smoke test and inspection
Bug: 36071012
Change-Id: I92c4090eac0067e0327ac7c8dde229747893d585
Sort android_dirs[] first by requirements, grouping, specificity and
finally by alphanumeric order.
Test: full build and install smoke test and inspection
Bug: 36071012
Change-Id: Iff579600b05d7b2a0b9fc7d9e9d897e0bb69aebd
We have seen cases when threads in this cgroup not scheduled for more than
a few seconds in heavy workload situation and causing device freeze.
In Linux, multiple threads placed in ROOT cgroup cause the CPU resource to
be split per thread, rather than per group.
Currently we have many threads in ROOT cgroup, which makes threads in
bg_non_interactive cgroup to have "tiny" CPU resource other than 5%
quota defined.
Bug: 34193533
Test: on marlin
Change-Id: I7721f6196560fbedf6265e8b6db130cec9edefd7
Tom Cherry