Start the serial console at the 'init' trigger instead of much later
when property triggers happen. This will help debugging early boot
issues.
Test: serial console starts early for a userdebug build
Test: serial console still doesn't start on a user build
Change-Id: I7112a8e7171c9fa865c8787c9a3d14515bc59478
Init sets the encryption policy on these directores when created.
Bug: b/139193659
Test: Boot device without this, then try to boot with it without wiping.
Cherrypicked-From: 7bf42f148a
Change-Id: I6b26710674b51d62fa4a07b06e06c539571fb7ac
Merged-In: I6b26710674b51d62fa4a07b06e06c539571fb7ac
This directory is intended to be used by boringssl
(through the bssl_self_test{,64} binaries) to create /
check for the existence of marker files indicating that
the self test has successfully run.
It appears that because this is an .rc script for init
rather than a shell,
mkdir -p /dev/boringssl/selftest 0755 root root
wouldn't work.
Bug: 139348610
Bug: 136262690
Test: Checked that after booting, /dev/boringssl/selftest
exists:
$ su root ls -l /dev/boringssl
total 0
drwxr-xr-x 2 root root 40 1972-02-11 03:27 selftest
Test: Checked that if I instead try:
mkdir -p /dev/boringssl/selftest 0755 root root
in init.rc then the directory isn't created (there is
no error message in logcat because logd is only
started in line 311).
Change-Id: I12fdd08c8ead152ac4e62cbd0a2099a9d6170ddb
This change is part of enabling upcoming platform changes that are
described in the bug linked below.
Bug: 135341433
Test: builds, boots successfully and external storage remains
an sdcardfs mount by default and works correctly
Test: cat /proc/1/mountinfo is unchanged
Change-Id: Idf851b3a42910e0ce8fdd75daea1cce91dd1aa98
This CL implements some of the libsnapshot internals necessary to work
with update_engine. In particular it implements snapshot and update
state, as well as creating and mapping snapshot devices. It does not
implement anything related to merging, nor does it implement the full
update_engine flow.
Update state is stored in /metadata/ota/state. To synchronize callers of
libsnapshot, we always flock() this file at the top of public functions
in SnapshotManager. Internal functions are only called while the lock is
held, and a "LockedFile" guard object is always passed through to
indicate proof-of-lock.
Low-level functions, such as snapshot management, have been moved to
private methods. Higher-level methods designed for update_engine will
ultimately call into these.
This CL also adds some functional tests for SnapshotManager. Test state
is stored in /metadata/ota/test to avoid conflicts with the rest of the
system.
Bug: 136678799
Test: libsnapshot_test gtest
Change-Id: I78c769ed33b307d5214ee386bb13648e35db6cc6
/metadata/ota will store the update state ("none", "applying",
"booting", "merging") for each dynamic partition. The data will be
managed by libsnapshot, whose primary consumer will be update_engine
but will also be available to recovery/fastbootd.
Bug: 136678799
Test: /metadata/ota exists
Change-Id: I3e06484cafeb363904914767abc8984adaa37021
system_suspend need to be an early_hal as it's required before storage
encryption can get unlock on FDE devices.
/sys/power/wake_lock is a dependency of system_suspend (only in Q and
earlier). Permissions on this file need to be set early enough.
Bug: 136777986
Bug: 133175847
Test: boot blueline
Change-Id: I8a9d3374b327e451fb98d2279d1bac9477a9560d
This reverts commit 997a2d93d7.
Reason for revert: This revert is needed, just also need some selinux rules for changes to the script that runs if this folder is present.
Bug: 136199978
Change-Id: Ie0544954965e3c90abc2f833c41949976c3bea65
(cherry picked from commit 35708b9d7b)
Create linkerconfig tmpfs mount and create ld.config.txt using
linkerconfig during init
Bug: 135004088
Test: m -j & tested from device
Change-Id: Iea30259871ef26d6c04beebf42b17ba7b494db0d
We need vold on early-fs so we can handle userdata checkpointing.
Without this, devices will take an extra minute or two as checkpointing
related vdc calls attempt to reach vold before it is available.
Bug: 134114000
Test: Boot, see vold has started before vdc checkpointing tries to call
out to vold.
Merged-In: Idfdb304503a163fbb91f9317949eb98c06fecce1
Change-Id: Idfdb304503a163fbb91f9317949eb98c06fecce1
We need vold on early-fs so we can handle userdata checkpointing.
Without this, devices will take an extra minute or two as checkpointing
related vdc calls attempt to reach vold before it is available.
Bug: 134114000
Test: Boot, see vold has started before vdc checkpointing tries to call
out to vold.
Change-Id: Idfdb304503a163fbb91f9317949eb98c06fecce1
The old "time zone updates via APK" feature installs time zone data
files in /data. tzdatacheck is run during boot to guard against an
OTA leaving the data in /data older, or in a different format, than the
files that exist elsewhere on device. If such files existed the system
could use old versions of tzdb (and related) data or even end up
unstable.
Soon, the time zone data mainline module will be made "functionally
mandatory" by the removal of most time zone data files from the
runtime module APEX, i.e. the time zone data module cannot be absent,
and the runtime module won't have files to compare against.
This change modifies the command line args for tzdatacheck to reference
the contents of time zone data module instead of the runtime module.
Bug: 132168458
Test: Build / boot / inspect logcat
Change-Id: Iac8023b7cbb72213df344d603c121caa867a196f
There is no reason that rlimits cannot be set earlier than they are,
and apexd-bootstrap may want to set the priority service option, which
would require that these rlimits have been set, so we move these to
the beginning of early-init.
Bug: 134668377
Test: apexd-bootstrap can set the priorty service option
Change-Id: I8040190cd4dc5e141784496ae65cfab80d9cad53
This directory is no longer used. OBB content is
placed in /data/media/$user/Android.
Test: make
Test: manually verify the path doesn't exist.
Bug: 129167772
Change-Id: I8549826586b9a68c8cfa3fe2e51295363f9b4e11
We used to start update_verifier after mounting userdata (post-fs-data),
as part of zygote-start. This leads to issues in practice for security
updates, where an A/B device falls back into the old slot (for any
reason, which unrelates to this change) but failing to boot due to
upgraded key blob. It essentially breaks the fallback capability offered
by A/B OTA.
This CL mitigates the issue by starting update_verifier early, before
mounting userdata. This avoids the device from falling back to the old
slot with an already-upgraded key blob. update_verifier loses the
opportunity of verifying _all_ the updated blocks based on the info
that's stored in userdata. Instead it will only trigger the minimal
read to finish the work of marking a successful boot. This is a
trade-off in P to avoid putting the device in a bad state after
fallback, which will be improved in Q by better handling the fallback
path in vold.
Bug: 131176531
Test: Flash and boot crosshatch. Check the start of update_verifier and
it marks a successful boot.
Change-Id: I3f4c4333ff38772a9a93c9d027d497db11de1d63
(cherry picked from commit 79cfc7d5a8)
On devices that use FDE and APEX at the same time, we need to bring up a
minimal framework to be able to mount the /data partition. During this
period, a tmpfs /data filesystem is created, which doesn't contain any
of the updated APEXEs. As a consequence, all those processes will be
using the APEXes from the /system partition.
This is obviously not desired, as APEXes in /system may be old and/or
contain security issues. Additionally, it would create a difference
between FBE and FDE devices at runtime.
Ideally, we restart all processes that have started after we created the
tmpfs /data. We can't (re)start based on class names alone, because some
classes (eg 'hal') contain services that are required to start apexd
itself and that shouldn't be killed (eg the graphics HAL).
To address this, keep track of which processes are started after /data
is mounted, with a new 'mark_post_data' keyword. Additionally, create
'class_reset_post_data', which resets all services in the class that
were created after the initial /data mount, and 'class_start_post_data',
which starts all services in the class that were started after /data was
mounted.
On a device with FBE, these keywords wouldn't be used; on a device with
FDE, we'd use them to bring down the right processes after the user has
entered the correct secret, and restart them.
Bug: 118485723
Test: manually verified process list
Change-Id: I16adb776dacf1dd1feeaff9e60639b99899905eb
On devices that use FDE and APEX at the same time, we need to bring up a
minimal framework to be able to mount the /data partition. During this
period, a tmpfs /data filesystem is created, which doesn't contain any
of the updated APEXEs. As a consequence, all those processes will be
using the APEXes from the /system partition.
This is obviously not desired, as APEXes in /system may be old and/or
contain security issues. Additionally, it would create a difference
between FBE and FDE devices at runtime.
Ideally, we restart all processes that have started after we created the
tmpfs /data. We can't (re)start based on class names alone, because some
classes (eg 'hal') contain services that are required to start apexd
itself and that shouldn't be killed (eg the graphics HAL).
To address this, keep track of which processes are started after /data
is mounted, with a new 'mark_post_data' keyword. Additionally, create
'class_reset_post_data', which resets all services in the class that
were created after the initial /data mount, and 'class_start_post_data',
which starts all services in the class that were started after /data was
mounted.
On a device with FBE, these keywords wouldn't be used; on a device with
FDE, we'd use them to bring down the right processes after the user has
entered the correct secret, and restart them.
Bug: 118485723
Test: manually verified process list
Change-Id: I16adb776dacf1dd1feeaff9e60639b99899905eb
right now vendor_init is forked before we set oom_adj for init which
leaves a chance vendor_init could be killed in heavy memory pressure.
this CL set the oom_adj before forking everything to ensure all native
have correct oom_adj settings.
Fixes: 130824864
Test: procrank -o
(cherry picked from commit 45d8174fe7)
Change-Id: I68c18f9db24d55239f7f0608592fcc702f04542e
right now vendor_init is forked before we set oom_adj for init which
leaves a chance vendor_init could be killed in heavy memory pressure.
this CL set the oom_adj before forking everything to ensure all native
have correct oom_adj settings.
Fixes: 130824864
Test: procrank -o
Change-Id: I8af129076c3efa29f7b781459449f8f2dc853c98
