Since developers can use a BluetoothDevice object can make remote
calls, it needs to have an accurate AttributionSource. Previous CLs
had updated many places where these BluetoothDevice instances were
passed across Binder interfaces, but this change updates several
remaining locations which had been missed.
Introduces new "Attributable" marker interface to offer consistent
tooling when applying AttributionSource updates.
Bug: 187097694
Test: atest BluetoothInstrumentationTests
Change-Id: Icad3b9726591f0fbad58a493cefa5a0af7648280
The method is used in ClasspathDeviceTest to filter out native .so
files, as it only cares about java classes.
Bug: 189347015
Bug: 187823488
Test: m
Change-Id: Id4d41ddef1cddbecd7f7028e28da4040cdfd5c26
Some devices may not have certain partitions available and the
OverlayConfigTests use hardcoded paths to test OverlayConfig
functionality. This change ensures that the temporary directory
created to test OverlayConfig has all of the partitions defined in
PackagePartitions#SYSTEM_PARTITIONS within it.
Bug: 187020117
Bug: 187020675
Test: atest OverlayConfigTest
Change-Id: I511e24b7ccfe82e6e89ceea7107457439793ef77
Attribution source is the abstraction to capture the data
flows for private data across apps. Checking permissions
for an attribution source does this for all apps in the
chain that would receive the data as well as the relevant
app ops are checked/noted/started as needed.
Teach speech recognition service about attribution
chains. If an implementation does nothing the OS
would enforce permisisons and do blame as always.
This apporach leads to double blaming and doesn't
support attribition chains where app calls into
the default recognizer which calls into the on
device recognizer (this nests recursively). If the
implementer takes advantage of the attribution chain
mechanims the permissions for the entire chain are
checked at mic access time and all apps are blamed
only once.
Fixed a few bugs around finishing ops for attribution
chains. Also ensured that any app death in a started
attribution chain would lead to finishing the op for
this app
bug: 158792096
Test: (added tests for speech reco)
atest CtsMediaTestCases
atest CtsPermissionTestCases
atest CtsPermission2TestCases
atest CtsPermission3TestCases
atest CtsPermission4TestCases
atest CtsPermission5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Merged-In: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
Change-Id: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
Attribution source is the abstraction to capture the data
flows for private data across apps. Checking permissions
for an attribution source does this for all apps in the
chain that would receive the data as well as the relevant
app ops are checked/noted/started as needed.
Teach speech recognition service about attribution
chains. If an implementation does nothing the OS
would enforce permisisons and do blame as always.
This apporach leads to double blaming and doesn't
support attribition chains where app calls into
the default recognizer which calls into the on
device recognizer (this nests recursively). If the
implementer takes advantage of the attribution chain
mechanims the permissions for the entire chain are
checked at mic access time and all apps are blamed
only once.
Fixed a few bugs around finishing ops for attribution
chains. Also ensured that any app death in a started
attribution chain would lead to finishing the op for
this app
bug: 158792096
Test: ((added tests for speech reco))
atest CtsMediaTestCases
atest CtsPermissionTestCases
atest CtsPermission2TestCases
atest CtsPermission3TestCases
atest CtsPermission4TestCases
atest CtsPermission5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Change-Id: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
Replace PackageParser.NewPermissionInfo by the independent one in
order to move away from PackageParser.
Bug: 174723245
Test: atest -p core/java/android/content/pm/parsing \
services/core/java/com/android/server/pm/permission \
services/tests/servicestests/src/com/android/server/pm/permission
Change-Id: I2398ee87516c813a86f5e9308ae43434b841fae5
When an application is incrementally installed, and a resources
operation fails due to the resources not being fully present,
the app should crash instead of swallowing the error and
returning default values to not alter the experience of
using the application.
Disable IncFsFileMap protections on ApkAssets that are a part of the
application that is running (base and splits).
Bug: 187220960
Test: atest ResourcesHardeningTest
Change-Id: Ibc67aca688720f983c7c656f404593285a54999b
Previous resolve had a weird behavior where a specific IntentFilter
configured cross profile filter configuration (as opposed to a general
configuration requiring allow_parent_profile_app_linking to be toggled)
would be added into the candidate set, which the code assumed was only
for the user ID being queried.
Instead, this specific cross profile resolution needs to be kept
separate as a different user, and applied if when the general
resolution is unavailable.
This makes both specific and general branchs assign the same
CrossProfileDomainInfo that domain verification was already checking,
and so should allow the logic to work in cases where the specific info
was previously dropped.
Bug: 189222753
Test: CtsDomainVerificationDeviceMultiUserTestCases
Change-Id: I0ac12d7125a7c5a9d4b9b35692d13928cbeb84e3
When a string cannot be retrieved from a StringBlock due to pages of
the StringPool missing, rather than throwing an
IndexOutOfBoundsException, compute a default value rather that
abides by the API contacts of the functions that use the StringBlock.
IndexOutOfBoundsExceptions are not really documented as a possible
exception that can be thrown from APIs that use StringBlock because
it indicates that the binary resource table was built incorrectly.
Returning default values is much less likely to break applications
that fetch the resources of incrementally installed applications than
throwing IndexOutOfBoundsExceptions where they would normally not be
expected.
Bug: 188174746
Test: atest ResourcesHardeningTest
Change-Id: I58fe754fb446fefc031ddba19e290830fdd6d015
We ended up defaulting to this behavior, so we no longer need this flag.
Bug: 189235490
Bug: 188057823
Test: Build
Change-Id: I62e383978d9b168657f2eac2e6bf4337a91b909b
