The updated font files will be stored to /data/fonts/files and
all application will read it for drawing text.
Thus, /data/fonts/files needs to be readable by apps and only writable
by system_server (and init).
Bug: 173517579
Test: atest CtsGraphicsTestCases
Test: Manually done
Change-Id: Ia76b109704f6214eb3f1798e8d21260343eda231
This is a shared part that all NN HAL users otherwise would have to
define themselves.
Bug: 172922059
Test: m
Test: VtsHalNeuralnetworksTest on master (locally)
Change-Id: I3616d0afbb115bc0feaed00488855646633da915
IncFS in S adds a bunch of new ioctls, and requires the users
to read its features in sysfs directory. This change adds
all the features, maps them into the processes that need to
call into them, and allows any incfs user to query the features
Bug: 170231230
Test: incremental unit tests
Change-Id: Ieea6dca38ae9829230bc17d0c73f50c93c407d35
The interaface now provided by IKeystoreAuthorization AIDL interface was
previously provided by Keystore AIDL interface.
This CL adds policy to allow Keystore2 to register
IKeystoreAuthorization aidl service and to allow service manager to
look up and connect to the service.
Bug: 159475191
Test: Needs to be tested in runtime
Change-Id: I56829a8764e0efe55efdc92b75d7a3d918a20dae
odrefresh is the process responsible for checking and creating ART
compilation artifacts that live in the ART APEX data
directory (/data/misc/apexdata/com.android.art).
There are two types of change here:
1) enabling odrefresh to run dex2oat and write updated boot class path
and system server AOT artifacts into the ART APEX data directory.
2) enabling the zygote and assorted diagnostic tools to use the
updated AOT artifacts.
odrefresh uses two file contexts: apex_art_data_file and
apex_art_staging_data_file. When odrefresh invokes dex2oat, the
generated files have the apex_art_staging_data_file label (which allows
writing). odrefresh then moves these files from the staging area to
their installation area and gives them the apex_art_data_file label.
Bug: 160683548
Test: adb root && adb shell /apex/com.android.art/bin/odrefresh
Change-Id: I9fa290e0c9c1b7b82be4dacb9f2f8cb8c11e4895
Access to /proc/locks is necessary to activity manager to determine
wheter a process holds a lock or not prior freezing it.
Test: verified access of /proc/locks while testing other CLs in the same
topic.
Bug: 176928302
Change-Id: I14a65da126ff26c6528edae137d3ee85d3611509
Feature description: if a background trace is happening at the
time dumpstate is invoked, the tracing daemon will snapshot
the trace into a fixed path (/data/misc/perfetto-traces/bugreport/).
Dumpstate will attach the trace, if present, to the bugreport.
From a SELinux viewpoint this involves the following permissions:
- Allow dumpstate to exec+trans perfetto --save-for-bugreport
(this will just send an IPC to traced, which will save the trace).
- Allow dumpstate to list, read and unlink the trace file.
- Create a dedicated label for bugreport traces, to prevent that
dumpstate gets access to other traces not meant for bug reporting.
Note that this does NOT allow dumpstate to serialze arbitary traces.
Traces must be marked as "eligible for bugreport" upfront in the
trace config (which is not under dumpstate control), by
setting bugreport_score > 0.
Design doc: go/perfetto-betterbug
Bug: 170334305
Test: manual:
1. start a perfetto trace with bugreport_score > 0
2. adb shell dumpstate
3. check that the bugreport zip contains the trace
Change-Id: I259c3ee9d5be08d6b22c796b32875d7de703a230
- Update policy for new system service, used for AiAi/Apps to
present data in their UI.
Bug: 173243538
Bug: 176208267
Test: manual. Can boot to home and get manager successfully.
Change-Id: Ie88c6fa7ed80c0d695daaa7a9c92e11ce0fed229
These flags should be writeable to the shell for both root and non-root
users. They should be readable everywhere, as they're read in libc
during initialization (and there's nothing secret to hide). We just
don't want to allow apps to set these properties.
These properties are non-persistent, are for local developer debugging
only.
Bug: 135772972
Bug: 172365548
Test: `adb shell setprop memtag.123 0` in non-root shell succeeds.
Change-Id: If9ad7123829b0be27c29050f10081d2aecdef670
See go/rescue-party-reboot for more context.
One integer will be stored in a file in this
directory, which will be read and then deleted at the
next boot. No userdata is stored.
Test: Write and read from file from PackageWatchdog
Bug: 171951174
Change-Id: I18f59bd9ad324a0513b1184b2f4fe78c592640db
ConnectivityService is going to become mainline and can not
access hidden APIs. Telephony and Settings were both accessing
the hidden API ConnectivityManager#getMobileProvisioningUrl.
Moving #getMobileProvisioningUrl method into telephony means
that there is one less access to a hidden API within the overall
framework since the Connectivity stack never needed this value.
Thus, move getMobileProvisioningUrl parsing to telephony surface
and provide the corresponding sepolicy permission for its access.
The exsting radio_data_file is an app data type and may allow
more permission than necessary. Thus create a new type and give
the necessary read access only.
Bug: 175177794
Test: verify that the radio process could read
/data/misc/radio/provisioning_urls.xml successfully
Change-Id: I191261a57667dc7936c22786d75da971f94710ef
One of the advantages of the DMA-BUF heaps framework over
ION is that each heap is a separate char device and hence
it is possible to create separate sepolicy permissions to restrict
access to each heap.
In the case of ION, allocation in every heap had to be done through
/dev/ion which meant that there was no away to restrict allocations in
a specific heap.
This patch intends to restrict coredomain access to only approved
categories of vendor heaps. Currently, the only identified category
as per partner feedback is the system-secure heap which is defined
as a heap that allocates from protected memory.
Test: Build, video playback works on CF with ION disabled and
without sepolicy denials
Bug: 175697666
Change-Id: I923d2931c631d05d569e97f6e49145ef71324f3b
Revert "Add android.hardware.memtrack-unstable-ndk_platform"
Revert submission 1518702-memtrack-aidl
Reason for revert: Broken tests and boot time regressions
Reverted Changes:
Ic4dd70e2c:Add android.hardware.memtrack-unstable-ndk_platfor...
Iaf99d0ca4:Add stable aidl memtrack HAL to product packages
Iac54ae2ba:Add stable aidl memtrack hal to vndk list
If310210a3:libmemtrack: Add support for AIDL memtrack HAL
Ib6c634def:Memtrack HAL: Add stable AIDL implementation
I5e1d0e006:Memtrack HAL stable aidl sepolicy
Change-Id: I0c55ee100c7fd8d09a5b188a39b17c95c8a43c39
This service manager is registered by Keystore 2.0 to lookup legacy
wrapper services.
Keystore 2.0 is now written in rust. We have AIDL binding for rust but
no HIDL binding. Keystore 2.0 has to support legacy HIDL based
interfaces. So we implement the AIDL KeyMint interface in terms of the
legacy HIDL Keymaster <= V4.1 devices in C++. This wrapper is linked
into the Keystore 2.0 process but it cannot be called directly but must
be treated like a remote binder instead. However, we cannot register
these wrappers directly, because a) we are not a vendor component, and
b) it would conflict with genuine KeyMint devices on newer devices. So
Instead we register Keystore 2.0 itself as a legacy service provider.
Which it can query itself for the legacy wrappers if it does not find
a genuine KeyMint implementation to connect to.
Bug: 171351607
Test: Keystore 2.0 can register this Service and lookup legacy wrapper
services.
Change-Id: I935f23837721ce126531236f4920dba469a47be4
16d61d0383
Bug: 175345910
Bug: 171429297
Exempt-From-Owner-Approval: re-landing topic with no changes in this CL.
Change-Id: I1352c6b46b007dba3448b3c9cbdf454d7862a176
user_profile_data_file is mlstrustedobject. And it needs to be,
because we want untrusted apps to be able to write to their profile
files, but they do not have levels.
But now we want to apply levels in the parent directories that have
the same label, and we want them to work so they need to not be
MLS-exempt. To resolve that we introduce a new label,
user_profile_root_file, which is applied to those directories (but no
files). We grant mostly the same access to the new label as
directories with the existing label.
Apart from appdomain, almost every domain which accesses
user_profile_data_file, and now user_profile_root_file, is already
mlstrustedsubject and so can't be affected by this change. The
exception is postinstall_dexopt which we now make mlstrustedobject.
Bug: 141677108
Bug: 175311045
Test: Manual: flash with wipe
Test: Manual: flash on top of older version
Test: Manual: install & uninstall apps
Test: Manual: create & remove user
Test: Presubmits.
Change-Id: I4e0def3d513b129d6c292f7edb076db341b4a2b3
