qemu.sf.lcd_density is rerefenced by surfaceflinger
and zygote.
Bug: 178144237
Test: presubmit
Signed-off-by: Roman Kiryanov <rkir@google.com>
Change-Id: Iede75d1170aeac9d020d60a3a66a1f69cee46abf
Merged-In: Iede75d1170aeac9d020d60a3a66a1f69cee46abf
Vendor boot hal, init, and vold processes all require permission.
Test: build and boot aosp_cf_x86_64_phone
Bug: 173815685
Change-Id: I15692dcd39dfc9c3a3b7d8c12d03eff0a7c96f72
System files in recovery are labelled as rootfs, so we need an explicit
transition to snapuserd. Without this, factory data resets will fail
with a VABC OTA pending, with the following denial:
avc: denied { entrypoint } for pid=522 comm="init" path="/system/bin/snapuserd"
dev="rootfs" ino=1491 scontext=u:r:snapuserd:s0 tcontext=u:object_r:rootfs:s0
tclass=file permissive=0
Bug: 179336104
Test: factory data reset with VABC OTA pending
Change-Id: Ia839d84a48f2ac8ccb37d6ae3b1f8a8f7e619931
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
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
