Without enabling the encryption on this folder, we will not be able to
rename files from this folder to /data/app folder, since /data/app
folder is encrypted. Trying to rename files between unencrypted folder
to encrypted folder throws EXDEV error.
Turning on encryption for /data/app-staging has the following concerns:
1. Turning on the encryption will erase all of its content. But this is fine
since during OTA we fail all staged sessions anyway.
2. We need to create hardlinks from /data/app-staging to
/data/apex/active. This is also fine since we will be creating link from
encrypted folder (/data/app-staging) to non-encrypted folder and this
does not throw EXDEV error.
Bug: 163037460
Test: atest StagedInstallTest
Change-Id: Ie78f6df0c0e08de54a39c5e406957ad0a56b7727
Since Android R, the FUSE prop is always on and FUSE-off is no longer
supported
Test: m
Bug: 160159282
Change-Id: I6db20fe8cbf8d260ba21fed5da289eacd4e53ef5
Create directories under /data/local/tests at boot for atest to use
to execute tests on the device.
Bug: 138450837
Test: atest binderVendorDoubleLoadTest memunreachable_unit_test memunreachable_binder_test
Change-Id: Ic8e5031ad8701a063be14b6db760feb78f3eb412
Store pertinent information about userspace reboot events in the case
of failure. This information is any services which failed to stop
cleanly, the output of the default fstab and /proc/mounts, and
a list of mounts which failed to unmount. This information is only
stored as necessary (i.e. mount information will not be stored if
everything unmounted, even if some services failed to stop).
Added new /metadata/userspacereboot directory to persist this
information. Information older than 3 days will be deleted.
Test: adb reboot userspace with sigterm/sigkill timeouts set to
very low values
Test: Manual test of storing all other information
Bug: 151820675
Change-Id: I6cfbfae92a7fc6f6c984475cad2c50c559924866
https://r.android.com/c/1324649/5 moves the cgroup folder to its sysfs
path. Directory access rights are defined by kernel code and sepolicy,
so remove the initialization lines from init.rc.
Test: manually booted the device and verified access rights for
/sys/fs/cgroup
Bug: 154548692
Change-Id: I67284dc651ed529cae69e413b66c6e1292a2d970
remove cgroup v1 freezer entries from init.rc, add a new cgroup v2
controller and modify plists to properly interact with it.
Bug: 154548692
Test: manually verified the the cgroup v1 freezer controller isn't
created and a new controller for cgroup v2 is created under the correct
sysfs directory.
Change-Id: I1b811300ade486f88fdbd157255a7f37750cc54d
create new profiles to allowing thawing and freezing back the freezer
cgroup
Bug: 151225245
Test: Manually verified that using the SetTaskProfiles method on the
profiles thaws and freezes back the freezer cgroup.
Change-Id: I7f3e193ebe79b49c1f6ac52b6138ff4ec26fc570
On some devices we see a weird in which /metadata/apex will have a wrong
selinux label. This will effectively prevent such devices from getting
any apex updates. Since we haven't figured out a root cause for this
bug, it's safer to explicitly call restorecon on /metadata/apex to make
sure it's correct.
This change shouldn't affect a normal boot flow, since /metadata/apex
will already have a correct label and restorecon_recursive will be a
no-op.
Test: rm -Rf /metadata/apex && \
mkdir /metadata/apex &&
mkdir /metadata/apex/sessions
Bug: 149317789
Merged-In: I971ffe35c93bb79d9e71106c24515ec0ee70333a
Change-Id: I971ffe35c93bb79d9e71106c24515ec0ee70333a
(cherry picked from commit cf7b6bad55)
- zygote needs statsd for logging boot time event.
- statsd starting later leads into stats logging failure which
is reported by all child processes of zygote later.
This brings lots of noise in statsd error.
Bug: 159664734
Test: reboot and check if error log does not show up
E statsd : Found dropped events: 1 error -19 last atom tag 240 from uid 10169
Change-Id: Ie585febb50a9668671c8fda41a872595baae8385
Test: built and booted
Bug: 150040815
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Merged-In: If80758b3d7bf499d428880efa5ed555076bfc291
Change-Id: If80758b3d7bf499d428880efa5ed555076bfc291
On some devices we see a weird in which /metadata/apex will have a wrong
selinux label. This will effectively prevent such devices from getting
any apex updates. Since we haven't figured out a root cause for this
bug, it's safer to explicitly call restorecon on /metadata/apex to make
sure it's correct.
This change shouldn't affect a normal boot flow, since /metadata/apex
will already have a correct label and restorecon_recursive will be a
no-op.
Test: rm -Rf /metadata/apex && \
mkdir /metadata/apex &&
mkdir /metadata/apex/sessions
Bug: 149317789
Change-Id: I971ffe35c93bb79d9e71106c24515ec0ee70333a
Bug: 153849221
Test: build and try to capture the trace by perfetto and systrace
Change-Id: Ie8a13e12038bd66afcd264079a2c5f25daaa20ee
Merged-In: Ie8a13e12038bd66afcd264079a2c5f25daaa20ee
(cherry picked from commit 9d19a05422)
This will allow Phonesky to read APEXes under /data/apex/active.
Test: adb shell su 10114 dd if=/data/apex/active/com.android.tzdata@300000000.apex of=/dev/null
Bug: 154635217
Merged-In: I5278897413ca0e32aed9d1c7f82e48138bc51404
Change-Id: I5278897413ca0e32aed9d1c7f82e48138bc51404
- Cherry pick of aosp/1228482
As of aosp/1224611, there is a new step in the preparation of APEXes
where init calls back into apexd after DE user data is unencrypted to
allow DE apex data to be snapshotted or restored.
aosp/1228581 introduces a new apexd.status value of "activated" that
is set once APEXes are activated but before this snapshot has occurred.
init may execute "perform_apex_config" once this has occurred, so this
CL changes init to wait for "activated" rather than "ready" before
doing this.
Bug: 148672144
Test: build & flash, check boot completes and check in logs that init
waits on the correct status value.
Merged-In: I339580bf593d3b09a5dff749ac2a5d1952bcb210
Change-Id: I71b62c9dd2f7951811606002f38612784d3d9086
This will allow Phonesky to read APEXes under /data/apex/active.
Test: adb shell su 10114 dd if=/data/apex/active/com.android.tzdata@300000000.apex of=/dev/null
Bug: 154635217
Change-Id: I5278897413ca0e32aed9d1c7f82e48138bc51404