Now that we have proper API using which update_engine can ask apexd to
reserve space, we no longer need to allow update_engine access to
directories at /data/apex.
Instead, apexd should get those permission.
Bug: 172911822
Test: atest ApexHandlerAndroidTest
Change-Id: I3a575eead0ac2fef69e275077e5862e721dc0fbf
Contexts files, plat_sepolicy.cil, and 10000.0.cil are needed to boot.
This adds cil files to microdroid. But cil files are temporary and only
for testing. We'll need to migrate real cil files to Android.bp.
Bug: 178993690
Test: boot microdroid
Change-Id: I711b1db39c11d88bc1f9defeff5799e6f24756ab
When we serve compressed APEX via OTA, we need to ensure device has
enough space to decompress them during boot. In order to do that,
update_engine will need to pass metadata about the OTA to apexd so that
it can make calculation about space requirments. Update engine in return
will display warning to user if the space requirement can't be
fulfilled.
Bug: 172911822
Test: manual
Change-Id: Idff25ac8e5165da70c539edcf6b292e04299a5c6
odsign exec()'s odrefresh, which in turn exec()'s dexoptanalyzer.
Bug: 165630556
Test: No denials on boot
Change-Id: Ie97726cfbdbf09f75fa0b00d34ee10c9bdf5a5d7
Adding 'ro.surface_flinger.enable_layer_caching' to control
whether layer caching feature should be enabled or not.
Bug: 158790260
Change-Id: I3ceb84d2a9209b2c422ba93057e9323ca6816ca5
This primarily affects perfetto's traced_probes and shell-invoked
binaries like atrace, but also anyone with access to "debugfs_tracing".
These tracepoints are being actively collected in internal tracing, so
we would like to also make them available on release builds, as they
should be a source of useful system information there as well.
The ones we definitely need:
* sched_waking, sched_wakeup_new: both are similar to the
already-allowed sched_wakeup. The first differs in which exact process
context it occurs in, and the latter is the wakeup events of only the
fresh tasks.
* oom/mark_victim: contains only the pid of the victim. Useful for
memory-related tracing and analysis.
The other events in this patch are of lesser importance, but also are
fairly straightforward - clocks and priority for frequency/power tracing.
Small extra change: sched_process_free was only relabeled in the tracefs
block, so I've added it to debugfs to keep them in sync. (I wonder whether
debugfs is even necessary at this point... but that's outside of scope
here.)
See the attached bug for a longer explanation. There will also be a
separate patch for system/frameworks/native/atrace/atrace.rc for the
Unix file permissions of these files.
Bug: 179788446
Tested: I did not have access to a "user" build, but I've manually
checked the labels of events/.../enable tracefs files via ls -Z,
and strace'd traced_probes on a hacky debug build where I
commented out its SELinux allow-rule for debugfs_tracing_debug.
Change-Id: I15a9cb33950718757e3ecbd7c71de23b25f85f1d
Give it the u:object_r:ota_prop:s0 since the prop is only set
after an update.
Bug: 177625570
Test: boot the device, check the prop is written by update_engine
Change-Id: I4cf21d2a6af2a2083d4a5eba7751011cc6d0c522
For devices launching with Android Q or later, vendor_property_contexts
and odm_property_contexts should only contain vendor and odm properties.
This checks property_contexts files in build time.
To temporarily disable this check, users can set
BUILD_BROKEN_VENDOR_PROPERTY_NAMESPACE := true in BoardConfig.mk. But
VTS is still enforced, so users will have to fix the violations anyway.
Bug: 175526482
Test: m vendor_property_contexts after making violations
Change-Id: I99d6fff9033d78e1d276eed2682a2719dab84ae2
The fd shared here is the fast message queue descriptor of the Tuner
Filter MQ or DVR MQ, sent from the Tuner HAL HIDL interface to Tuner Service.
Tuner service would convert the hidl mq descriptor into an aidl one then
passed to the Tuner JNI. Tuner JNI would read/write data into fmq
through the shared fd when the third-party app calls corresponding APIs.
The fd won't be exposed through SDK APIs.
The same fd won't be shared among apps. Each app only has access to
their own Tuner java instance through Tuner SDK, and read/write their
own Filter/Dvr.
Test: atest TunerDvrTest#testDvrPlayback
Bug: 159067322
Bug: 174500129
Bug: 171378420
Bug: 158868205
Change-Id: I34c113a092673f8ea9bcb7428b5562101c4d35ec
Revert submission 1582845-qemu-prop
Reason for revert: aosp_hawk-userdebug is broken on an RVC branch
Reverted Changes:
Idfc2bffa5:Add qemu.hw.mainkeys to system property_contexts
If013ff33f:Remove qemu.hw.mainkeys from vendor_qemu_prop
Bug: 180412668
Change-Id: I335afb931eaeb019f66e3feedea80b0c8888f7a3
This SEPolicy change allows the hal_keymint domain to add
hal_remotelyprovisionedcomponent_service to hwservice_manager.
Test: The Keymint HAL can successfully start an instance of
IRemotelyProvisionedComponent
Change-Id: I15f34daf319e8de5b656bfacb8d050950bf8f250
system_server must be allowed to create process groups in behalf of
processes spawned by the app zygote
Bug: 62435375
Bug: 168907513
Test: verified that webview processes are migrated in their own process
group
Change-Id: Icd9cd53b759a79fe4dc46f7ffabc0cf248e6e4b8
We want to label /sys/fs/bpf/tethering/... with a new label distinct
from /sys/fs/bpf, as this will allow locking down the programs/maps
tighter then is currently possible with the existing system.
These programs and maps are provided via the tethering mainline module,
and as such their number, names, key/value types, etc. are all prone to
be changed by a tethering mainline module update.
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ifc4108d76a1106a936b941a3dda1abc5a65c05b0
