vendor_available modules were available to product modules.
However, not all vendor_available modules are required to be
available to product modules. Some modules want to be available only
to product modules but not vendor modules.
To cover the requirement, we separate product_available from
vendor_available.
vendor_available will not provide product available module.
Rename libcutils/include_vndk to libcutils/include_outside_system as
it provides the headers to the modules outside the system partition
including /product.
Bug: 150902910
Test: build
Change-Id: I791b5a6a1dc99442065debfce6fa0f54a335fcea
Migrate the freezer controller as an attribute for the uid/pid hierarchy
Bug: 168907513
Test: manually verified that the freezer behavior was as expected after
applying the enablers in ActivityManager
Signed-off-by: Marco Ballesio <balejs@google.com>
Change-Id: Ica2c4bfd20190fb2f2dc0a530eb47e1a8427c522
Current per-API level task profiles replace the latest task profiles
rather than overriding the diffs. This poses an issue when a new
feature is added which is applicable to older devices as well we
have to change all per-API level profiles. Change the per-API task
profile support to load the latest task profiles first and then override
with per-API task profiles, similar to how vendor task profiles override
system task profiles. This minimizes the changes we need to do to the
per-API level task profiles going forward and is more consistent with
how vendor task profiles work.
Bug: 170507876
Test: boot with per-API task profiles
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I08cc4b374cede7363cf96a30ac96971d49bb7847
Enable the uid/pid hierarchy for all groups when using cgroup v2. Mount
the hierarchy under the cgroup v2 root. Make sure that all files under
the hierarchy are accessible by the system user.
Test: booted the device, tested the freezer cgroup, manually verified
the working of the freezer from logs and by checking statuses of
processes.
Bug: 168907513
Test: Booted the device, verified no regressions on process group access
Change-Id: I73f3e767d377902af6e12facb503b9136fb39e08
This is happening accidentally because of a bug in Soong. In the
meantime, add a separate snapuserd.vendor_ramdisk that does not have an
init_rc section.
Bug: N/A
Test: manual test
Change-Id: I9dcafb681f209932fa13c5c55478f0e486e53306
camera-daemon is referred in task-profiles.json so the hierarchy should
be created in aosp's init.rc.
Bug: 170507876
Bug: 171740453
Test: boot and check cgroup
Change-Id: I0e6722b88922abf4ccae3b19623d8b889a6e3cb6
Kernel will batch the merge operations only when
block numbers of source and cow device are contiguous.
Daemon will read the COW file and post-process
the operations so that kernel can batch merge the potential
operations.
There are two key changes done in post-processing:
1: COW file contains all the copy operations at the
beginning of the file. We cannot allow batch
merging of COPY operations as a crash in between
the overlapping copies can result in a corrupted state.
Hence, allow copying individual blocks at a time.
2: Replace and Zero operations can be batch merged.
However, reading our existing COW format as-is
will not allow kernel to batch merge. Hence,
process the operations in such a way that kernel can batch
merge them.
Furthermore, it is observed that sync() after every
merge is a overhead. Hence, we will only sync()
for copy operations only. For replace and zero
operations, we will not explicitly sync. This is ok as
crash in between replace/zero merge operations can
redo those operations. However for copy, we have
to make sure that sync is completed before next copy
operation is initiated.
Merge time of a full OTA on bramble is around ~60
seconds as compared to ~10+ minutes prior to this
optimization.
Note that we still have copy operations which are not
batch merged. Hence, OTA with significant number of
copy operations can still have overhead on merge timings.
Bug: 174112589
Test: vts_libsnapshot, cow_snapuserd_test
Full OTA on bramble.
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I1dc286067a26ea399fa5d4e8e826e5622ce3fa58
Refact cow_snapuserd unit test. This will
test code changes in daemon in isolation. Currently it tests
1: Reading snapshot device and validate data
2: Merge and validate data.
More tests related to merge will be added later; but this
should provide a baseline unit test for daemon.
BUG: 168311203
Test: cow_snapuserd_test
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I4d77c435a9f045204a4ff3ece524c857f9fba50f
* changes:
trusty: provide coverage to gatekeeper fuzzer
trusty: fuzz: Example TA fuzzer
trusty: fuzz: Helper lib for libFuzzer extra counters
trusty: coverage: Coverage client library
In task_profiles.json, camera-daemon is referred for both cpu and
cpuset controller, so create them in init.rc officially.
Test: build pass
Bug: 170507876
Change-Id: I655154ab739ffde6fdfd2d499cbaa974597d3ee7
Remove provide libs of system image from file, and generate it at build
time instead
Bug: 172889962
Test: Build cuttlefish and confirmed list is generated in
/system/etc/linker.config.pb
Change-Id: I365252dcb2e8735fd8f6345c9ec2c985b0489d64
Restrucures this fuzzer to be far more robust and less brittle.
Fix: 163727995
Fix: 163449137
Test: libutils_fuzz_refbase clusterfuzz-testcase-minimized-libutils_fuzz_refbase-5674315436261376
Test: libutils_fuzz_refbase clusterfuzz-testcase-minimized-libutils_fuzz_refbase-5731662044069888
Test: libutils_fuzz_refbase clusterfuzz-testcase-minimized-libutils_fuzz_refbase-5081777218256896
Signed-off-by: Dylan Katz <dylan.katz@leviathansecurity.com>
Change-Id: I239298dc2895a06af5a126e9ca2ae452579e5cc0
Note: We need to add Confirmationui TA into
TRUSTY_BUILTIN_USER_TASKS to run the fuzzer.
Bug: 174402999
Bug: 171750250
Test: /data/fuzz/arm64/trusty_confirmationui_fuzzer/trusty_confirmationui_fuzzer
Change-Id: I22769782ded05eeedeb111f7537b5ba76e98ce73
When task profiles changes happen, devices released under older API
levels might have to use the same profiles as before. This might be
due to for missing kernel features or some other reasons. Add support
for per-API task profiles to accommodate this scenario. With this
mechanism when ro.product.first_api_level is non-empty, the system
looks for /system/etc/profiles/task_profiles_<api level>.json file
and uses it if it exists. If ro.product.first_api_level is not defined
or per-API task profiles file does not exist the system falls back to
the default /system/etc/profiles/task_profiles.json file.
As before, these task profiles can be competely overwritten using
/vendor/etc/task_profiles.json if needed.
Bug: 172066799
Test: boot with per-API task profiles
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I1671b341b3a0fb5e99d0b0788315c61088326b09
