This grants the shell app the SUGGEST_EXTERNAL_TIME permission needed
for the TimeManagerTest (CTS) to invoke the
TimeManager.suggestExternalTime() method during tests.
Bug: 184947690
Bug: 177079827
Test: See associated cts change
Merged-In: Ia1995ec9503dbd2b12e0b5b5f92a96e02f85beec
Change-Id: Ia1995ec9503dbd2b12e0b5b5f92a96e02f85beec
Added a new permission INSTALL_TEST_ONLY_PACKAGE
and granted it to shell, this will allow installing
testOnly apps from a testAPI.
Test: N/A
Bug: 183716601
Change-Id: I047a4013fb3462db3487eab2d1635ea75ae29264
isForeground is not a good approach to indentify current channel info
And add a permission for tuned info.
Bug: 180482268
Test: atest CtsPermission2TestCases
Test: atest TvInputManagerTest#testGetCurrentTunedInfos
Change-Id: Ib1c1f2da719336ae856684e843b06f8b9b442723
This permission is needed for uwb CTS ranging specific tests.
Is the minimally scoped permission that needs to be added?
- Yes, this only allows the app to range to uwb devices.
What options did you explore that did not need this permission?
- Without this permission, it would be impossible to test the raning
UwbManager API which is protected by UWB_RANGING + UWB_PRIVILEGED.
Bug: 183747097
Test: Compiles
Change-Id: I23fc60a111fd7d868e3982d71ffa354ea9957bfb
The shell *already had* the privileges granted by this permission due to
specific code in netd, and it lost those privileges when it gained the
CHANGE_NETWORK_STATE permission. Explicitly add
CONNECTIVITY_USE_RESTRICTED_NETWORKS so that it can obtain sufficient
permission in netd no matter CHANGE_NETWORK_STATE is set or not.
Remove a duplicate row by the way.
Bug: 185071689
Test: atest NetdClientTest#protectFromVpnTcp6
Change-Id: I64bc321de2c83378ce7bc8d9eb3044ae7772faca
As changing the permission for MediaRouter2 system APIs, this CL
changes the permission in shell accordingly.
The permission was added by ag/13959439.
Bug: 183428114
Test: Passed CTS tests
Change-Id: I3aee256a11db730dd786e69821f3bb8bd590074f
This permission is needed for uwb CTS tests.
Is the minimally scoped permission that needs to be added?
- Yes, this only allows the app to range to uwb devices.
What options did you explore that did not need this permission?
- Without this permission, it would be impossible to test any of the
UwbManager API's.
Bug: 183747097
Test: Compiles
Change-Id: Ie4264cdcd3f84c965da70f8f8fefe538378c47f6
Merged-In: Ie4264cdcd3f84c965da70f8f8fefe538378c47f6
This permission is needed for uwb CTS tests.
Is the minimally scoped permission that needs to be added?
- Yes, this only allows the app to range to uwb devices.
What options did you explore that did not need this permission?
- Without this permission, it would be impossible to test any of the
UwbManager API's.
Bug: 183747097
Test: Compiles
Change-Id: Ie4264cdcd3f84c965da70f8f8fefe538378c47f6
Granted shell the missing normal, dangerous, and
development permissions that can already be granted
to third party apps.
Test: N/A
Bug: 183716601
Merged-In: I11df0d753f830b6ba6ea2222f7d8a7d778161953
Change-Id: I11df0d753f830b6ba6ea2222f7d8a7d778161953
Granted shell the missing normal, dangerous, and
development permissions that can already be granted
to third party apps.
Test: N/A
Bug: 183716601
Change-Id: I11df0d753f830b6ba6ea2222f7d8a7d778161953
This change is part of defining a distinct BLUETOOTH_ADVERTISE
permission to guard the BluetoothLeAdvertiser APIs, since that's a
distinct enough of an operation from SCAN and CONNECT. It'll
continue to be covered under the general "Nearby devices" runtime
permission group.
Bug: 181813006
Test: atest CtsPermission2TestCases
Test: atest CtsPermission3TestCases
Change-Id: I8b62e4d625df1e201f12a73025cd29c431feea79
The activity recognition source may access activity
recognition in its operation as being the activity
recognition source. Accesses from an AR source
(for special tags it designates - the APK may contain
other components) for location and AR are tracked in
a dedicated app op.
bug: 182204957
Test: atest CtsActivityRecognitionTestCases
Change-Id: If29fba1c51d70a2806a0907a73a96d3d8d7a3100
Propagate renounced permissions from context params
to the context attribution source. Throw if one
tries to request at runtime a renounced permission.
Also make the AttributionSource take null for the
setters to ease usage, otherwise folks should always
check for null before calling a builder method.
Additionally, we allow apps that have UPDATE_APP_OPS_STATS
to register arbitrary trusted AttributionSource for
testing. Note that this permission allows abritrary app
op operations, thus we are not relaxing the security
model.
bug: 158792096
Test: atest CtsPermission5TestCases
Change-Id: I4330684bb8695fb998cf31e9363b94ad981ba2cc
Grant MODIFY_AUDIO_ROUTING permissions to the shell identity
for use within CTS tests.
Bug: 183428114
Test: CTS passed with the permission
Change-Id: I6e8c7553d7fe3263c0345adf0fe67340e5afcbe5
For testing a android.media.MediaPlayer.setOnRtpRxNoticeListener
Bug: 169965769
Change-Id: Ifff944ad85592adb3c132c86f123b36b60410643
Test: Built, flashed and booted a device
Adding SCHEDULE_PRIORITIZED_ALARM permission to Shell so the API can be
called from tests.
Test: Builds, boots.
atest CtsAlarmManagerTestCases:BasicApiTests
Bug: 183661625
Change-Id: I983b0d9d7a5ab417e74feae9dadf4d472d277b20
When an app is proxying access to runtime permission protected
data it needs to check whether the calling app has a permission
to the data it is about to proxy which leaves a trace in app ops
that the requesting app perofmed a data access. However, then the
app doing the work needs to get the protected data itself from the
OS which access gets attributed only to itself. As a result there
are two data accesses in app ops where only the first one is a
proxy one that app A got access to Foo through app B - that is the
one we want to show in the permission tracking UIs - and one
for the data access - that is the one we would want to blame on
the calling app, and in fact, these two accesses should be one -
that app A accessed Foo though B. This limitation requires fragile
one off workarounds where both accesses use the same attribution
tag and sys UI has hardcoded rules to dedupe. Since this is not
documented we cannot expect that the ecosystem would reliably
do this workaround in apps that that the workaround in the OS
would be respected by every OEM.
This change adds a mechaism to resolve this issue. It allows for
an app to create an attribution context for another app and then
any private data access thorugh this context would result in a
single app op blame that A accessed Foo though B, i.e. we no longer
have double accounting. Also this can be nested through apps, e.g.
app A asks app B which asks app C for contacts. In this case app
B creates an attribution context for app A and calls into app C
which creates an attribution context for app B. When app C gets
contacts the entire attribution chain would get a porper, single
blame: that C accessed the data, that B got the data from C, and
that A got the data form B. Furthermore, this mechanism ensures
that apps cannot forget to check permissions for the caller
before proxying private data. In our example B and C don't need
to check the permisisons for A and B, respectively, since the
permisisons for the entire attribution chain are checked before
data delivery. Attribution chains are not forgeable preventing
a bad actor to create an arbitrary one - each attribution is
created by the app it refers to and points to a chain of
attributions created by their corresponding apps.
This change also fixes a bug where all content provider accesses
were double counted in app ops due to double noting. While at
this it also fixes that apps can now access their own last ops.
There was a bug where one could not pass null getting the attributed
ops from a historical package ops while this is a valid use case
since if there is no attribution everything is mapped to the null
tag. There were some app op APIs not being piped thorough the app
ops delegate and by extension through the app ops policy. Also
now that we have nice way to express the permission chain in a
call we no longer need the special casing in activity manager to
handle content provider accesses through the OS. Fixed a bug
where we don't properly handle the android.os.shell calls with
an invlaid tag which was failing while the shell can do any tag.
Finally, to ensure the mechanims is validated and works end-to-end
we are adding support for a voice recognizer to blame the client
app for the mic access. The recognition service can create a blaming
context when opening the mic and if the mic is open, which would
do all permission checks, we would not do so again. Since changes
to PermissionChercker for handling attribution sources were made
the CL also hooks up renounced permissoins in the request permission
flow and in the permission checks.
bug:158792096
bug:180647319
Test:atest CtsPermissionsTestCases
atest CtsPermissions2TestCases
atest CtsPermissions3TestCases
atest CtsPermissions4TestCases
atest CtsPermissions5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Change-Id: Ib04585515d3dc3956966005ae9d94955b2f3ee08
This is needed to write CTS tests for the underlying changes.
Bug: 180396382
Test: atest CtsAppCompatHostTestCases
Change-Id: Id6b03f45ee1dcabc175e7536ac2675fce8effba8
Created a new permission to allow setting and verifying lock screen
credentials.
Test: N/A
Bug: 182260585
Merged-In: I3cf624f063ba582bc8d3b6aeeb11a46a2ab37636
Change-Id: I3cf624f063ba582bc8d3b6aeeb11a46a2ab37636
Created a new permission to allow access to device audio
state and granted it to shell.
Test: N/A
Bug: 182260585
Merged-In: If1bfcb1341402717fec74cc704caa7e1eb18fa2e
Change-Id: If1bfcb1341402717fec74cc704caa7e1eb18fa2e
Created the following new permissions and granted it to shell:
* FORCE_DEVICE_POLICY_MANAGER_LOG: will be used to expose
DPM#forceNetworkLogs and DPM#forceSecurityLogs as TestAPIs.
* CLEAR_FREEZE_PERIOD: will be used to expose
DPM#clearSystemUpdatePolicyFreezePeriodRecord as a TestAPI.
Bug: 180500227
Test: atest PermissionPolicyTest#platformPermissionPolicyIsUnaltered
Merged-In: I8a2a49aa45704d8991e9cf3689b5259442fb1db3
Change-Id: I8a2a49aa45704d8991e9cf3689b5259442fb1db3
Tooling run with the shell needs to be able to sample sensors above
200hz to facilitate with running tests.
Fixes: 183240340
Test: Run tool that requires the permission to sample at a high rate
Change-Id: Ic6782ea5afe750d3ec3167d11eef791881dceb53
An upcoming platform change is introducing a new "Nearby devices"
runtime permission which contains the new BLUETOOTH_CONNECT and
BLUETOOTH_SCAN permissions.
We have logic in place to use <split-permission> to translate the
older BLUETOOTH and BLUETOOTH_ADMIN permissions into these new
runtime permissions, but modern apps will need to pivot to
requesting them directly as part of targeting Android S.
This change requests both the old and new permissions to avoid
breakage while the new permission enforcement is being phased in.
Bug: 181813006
Test: atest CtsPermission2TestCases
Test: atest CtsPermission3TestCases
Test: atest CtsStatsdAtomHostTestCases
Change-Id: I39f45e7d22d132d44c84017cd98e6d9e98533c7f
