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
Normally 'writepid' is used to add a process to a particular cpuset. However
certain systems with big/small cores might need to specify a default cpuset for
system processes which do not explicitly specify one. Add an option to use
'ro.cpuset.default' system property to specify default cpuset for system processes
which do not explicitly write to /dev/cpuset/... with 'writepid' option.
The cpuset name specified in ro.cpuset.default is just the cpuset name, e.g.
'/system-background', '/foreground', or simply '/' for the "root" cpuset.
Bug: 28550814
Test: `m -j32` succeeds for aosp_sailfish-eng. Phone boots successfully.
Also tested manually with debug trace messages on emulator with different
combinations of values for 'ro.cpuset.default'.
Change-Id: I501727fa5ee3f4bb7a938fa104b81a404b616633
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
Comply with clang-format. Adjust some comments.
Test: full build and install smoke test and inspection
Bug: 36071012
Change-Id: I459a08b4dc4333ab3d75207621a27587849386a5
read_file() does not close its fd if either stat() fails or the file
has group/world writable permissions.
Use unique_fd to ensure that all return paths close the fd and make
the same change to write_file() for consistency.
Replace PLOG() with LOG() after a simple if conditional, that does not
set errno.
Old:
init: skipping insecure file '/data/bootchart/header': No such device or address
New:
init: skipping insecure file '/data/bootchart/header'
Test: Cause an invalid file read and check the error log
Test: Ensure non-error read_file() and write_file() work
Change-Id: Ib15d94e38362e335d671d30b36aa5605254ec7ab
Recent changes to OTA updates started "blaming" network usage on the
system UID, which makes it difficult to triage incoming bugreports
that claim heavy network usage. Instead, this change gives OTA
updates an explicit UID to make triage easier.
Test: builds, boots
Bug: 36130264
Change-Id: I0a0cc009f3d891b19b419bc12cd237ef8ac64519
Switch the jdwp control socket to SOCK_SEQPACKET so we don't have to
worry about short reads for the PID.
Bug: http://b/36411868
Test: adb jdwp
Change-Id: I908b88e93b1e0ca2895eb8e777d8438a7bbfa92a
Also fixed InvalidNumberArgs that broke when usage() was moved out from
bugreport.cpp.
Fixes: 26354314
Bug: 28054087
Test: m -j32 adb_test && ./out/host/linux-x86/nativetest64/adb_test/adb_test --gtest_filter=BugreportTest.*
Change-Id: I7be5ef7de0fb0d339dc80a2abc816e1c905deb22
If a process opens a JDWP socket, but crashes before writing the full
PID, adbd will spin forever.
Bug: http://b/36411868
Test: none
Change-Id: I1811759e15c3d9c819685c5fc159a566bd4bc842
Some classes referenced in comments in libcore.tzdata.update2 have
moved to libcore.tzdata.shared2.
Bug: 31008728
Test: mmm system/core/tzdatacheck
Change-Id: I390b375ab8fefbb46e69f4534000ff43ffcceae8
Force assignment to read the old pointer value twice, and check
that it didn't change in the interim. Previous experience with
Skia suggests that this has a high probability of correctly detecting
a data race when it occurs, instead of potentially letting the
count associated with the old pointer value get decremented twice,
and corrupting the heap.
This does increase the size of sp assignments, which seem to
commonly get inlined. For the general case, we add a third
comparison and function call.
Some code reformatting to make this consistent with modern conventions
and pass automated checks.
Test: Booted aosp build. Ran libutils tests. Looked at generated code.
Bug: 31227650
Change-Id: Id93a05c6bf10f01ee15ff1bb409611f2058f988f
Move last reboot reason file to new directory data/misc/reboot/ to
require only SELinux permissions specific to this new file.
Bug: 30994946
Test: manual: reboot command, setprop sys.powerctl
Change-Id: I1e067235aa4b06391cff8ab0741a9d317ba5b7da
Save a string identifying the reason for last Android reboot or power
off in file /data/misc/recovery/last_reboot_reason . This file may
be used for informing users of reboot or shutdown reasons at next
boot, and for other diagnostic purposes.
Bug: 30994946
Test: Manual: reboot, setprop sys.powerctl
Change-Id: I01e44473fdd21b33e9e4dced77aba9a66b6d3755
A recent change to the is_first_stage conditionals created a unneeded
else { } block as both the code in the else { } block and any code
that runs after it are both in the second stage of init. A first step
to clean this up is to remove this else block.
Secondly, given the above confusion, it makes sense to simplify the two
if (is_first_stage) conditions into one, which only now requires
duplicating one line to initialize logging and the actual "init
first/second stage started!" logs.
Lastly, there are a few commands ran at the beginning of both init
stages that do not need to be,
* boot_clock::time_point start_time = boot_clock::now();
This is only used in the first stage so keep it there
* umask(0);
umasks are preserved across execve() so it only needs to be set in the
first stage
* chmod("/proc/cmdline", 0440);
This needs to be moved until after /proc is mounted in the first
stage, but otherwise only needs to be done once
Test: Boot bullhead, check umask, check cmdline permissions, check
boot time property
Change-Id: Idb7df1d4330960ce282d9609f5c62281ee2638b9
The qtaguid_tagSocket() function tags a network socket by passing a
reference to the given socket to the qtaguid kernel module. The module
will keep the socket alive even if the process calls close() on said
socket. In this scenario, the socket object would not be destroyed
even if all the file descriptor.
While this is at least a memory leak, it plays bad with epoll(7)
if you also didn't remove the socket from the epoll fd before closing
since epoll will not notice that the socket was closed and there is no
way to remove the socket from epoll after it was closed.
This patch updates the documentation to explicitly mention that the
socket must be untag before closing or bad things happen.
Bug: 36264049
Test: None.
Change-Id: I564a9b6d11d22b43a6c12312524386c0338b42ed
We would experience failures as test runs interfere with each other.
Create a unique tag for each test run signature. Switch from using
TEST_PREFIX to TEST_LOGGER to identify the logger transport being
inspected and make that part of the signature. Make sure 32 bit and
64 bit tests do not interfere.
Test: gTest liblog-unit-tests
cts-tradefed run cts -m CtsLiblogTestCases
Bug: 36232924
Change-Id: I4d58242e5ef8e68e2d4b27cecf538938e17acf3f
Upon opening, qemu pipe (a.k.a. goldfish pipe) requires a purpose
string so that emulator can route the content to the right channel
on the host.
This CL will ask emulator to send the content to pipe based 'logcat'
service on the host.
Change-Id: Icc71f81d5b95b64ea315fe10da82ff704416e449
- __security test to allow 20ms resting time after setting ro.device_owner
- enoent test resort to using "su" command if we are not root to start
and stop the logger.
- Add some instrumentation to guide us in the future if issues.
Test: gTest liblog-unit-tests
cts-tradefed run cts -m CtsLiblogTestCases
Bug: 36232924
Change-Id: I6b926a1913497f7e6204493fc744ee6c454a5ce4
