Delegate the resetting of the INTERACT_ACROSS_PROFILES app-op to
DevicePolicyManager, which knows whether it should be pre-granted and
knows to apply it equally across all users in the profile group.
Further unit tests for DevicePolicyManagerInternal will be added in
b/175440570 when we have the better infra for that.
The CrossProfileAppsServiceImpl changes look more complex than they are.
They consist of the following:
- Inclusive language changes to 'allowlist'
- Static imports of permissions to improve readability
- Previously, the setInteractAcrossProfilesAppOp method would set the
app-op for every user within the profile group of the 'calling user'.
However, given that we are now exposing this as a server-side internal
API where we need to pass in a user ID (from AppOpsService), we don't
necessarily have the guarantee that the 'calling user' is in the same
profile group. So we split it up: the client-side API and AIDL API still
set the app-op for the calling profile group, whereas the internal API
sets the app-op for every user within the profile group of the provided
user. The changes simply abstract away references to the 'calling user
ID'.
Fixes: 166561076
Bug: 175440570
Test: atest services/robotests/src/com/android/server/pm/CrossProfileAppsServiceImplRoboTest.java --verbose -c
Test: manual
Change-Id: I2181fe66022aaf6c3e6d784c0569d2f41ab66537
(cherry picked from commit d004f41188ba39afd2c75e4e7dede6b755a9d752)
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script that
identifies relevant "include" directives.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
Change-Id: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
This is a transitional step towards truth 1.0.1, where these APIs have
been completely removed.
Bug: 168765701
Test: m checkbuild
Exempt-From-Owner-Approval: Cherry-pick of no-op refactor into another branch
Merged-In: I26ab5ab82bb939bbd9553c05387ac8641eb468b4
Change-Id: I26ab5ab82bb939bbd9553c05387ac8641eb468b4
(cherry picked from commit 4697f76edd28cc9363c5ca099a6f9c311c1aee50)
android_robolectric_test is having some implicit deps removed
from it, so add in what we depend on directly.
Test: m RunFrameworksServicesRoboTests
Change-Id: Ice2abeb3f4d031cfe15ce919b750d6de59316c1f
Merged-In: Ice2abeb3f4d031cfe15ce919b750d6de59316c1f
android_robolectric_test is having some implicit deps removed
from it, so add in what we depend on directly.
Test: m RunFrameworksServicesRoboTests
Change-Id: Ice2abeb3f4d031cfe15ce919b750d6de59316c1f
Since Android 10, backupPm() includes sendDataToTransport(), which was
not previously the case. This means that error handling logic that
deletes the backup state file (causing initialize_device() on the next
attempt, which deletes any existing backup) will now also be triggered
upon errors during sendDataToTransport(), which wasn't previously
(Android <= 9) the case.
This has the potential of making an existing temporary outage much
worse:
1. A few devices might run into temporary issues, e.g. a B&R server
returning HTTP 503 Service Unavailable (treated as a
TransientHttpStatusException instanceof NetworkException, which
is mapped to TRANSPORT_ERROR during handleTransportStatus(),
which results in a TaskException with stateCompromised==false
but which backupPm() wraps in another TaskException that forces
stateCompromised=true).
2. On their next backup attempt, those devices throw away any
existing backup and start from scratch (initialize_device()),
increasing the load on the server.
3. This leads to a positive-feedback loop where more devices than
before run into HTTP 503 Service Unavailable.
4. As a result, masses of devices delete their backups and then
hammer the B&R server with attempts to upload new backups.
5. Backups are unavailable to any users who would otherwise rely
on them during this outage.
To improve on this dangerous situation, this CL changes the code to
force stateCompromised=true only for TaskExceptions thrown
specifically during extractPmAgentData(), and (as before) for all
AgentExceptions.
Note that the code is still quite brittle. It still seems like we
are probably forcing stateCompromised=true in too many situations,
but it's hard to say so this CL is being conservative about the
changes. Changing back to the old behavior could be done through
a local change around KeyValueBackupTask.java:676; a future CL may
do this to have a safety hatch in case we want to cherry-pick this
CL into an upcoming Android release late in the release cycle.
[1] https://android.googlesource.com/platform/frameworks/base/+/refs/heads/pie-dev/services/backup/java/com/android/server/backup/internal/PerformBackupTask.java#1035
[2] https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/services/backup/java/com/android/server/backup/keyvalue/KeyValueBackupTask.java#1040
[3] https://source.corp.google.com/piper///depot/google3/java/com/google/android/gmscore/integ/modules/backup/transport/src/com/google/android/gms/backup/transport/GmsBackupTransport.java;l=770;rcl=281845876
Bug: 144030477
Test: Checked that the following passes after this CL, but
testRunTask_whenTransportReturnsErrorForPm_updatesFilesAndCleansUp()
fails if I revert the state of KeyValueBackupTask.java to before this CL:
ROBOTEST_FILTER=KeyValueBackupTaskTest make \
RunBackupFrameworksServicesRoboTests
Change-Id: I6c622c55fbd804ec0a12e0bea7ade1308f7a3877
(cherry picked from commit 819ed81faaa295d9e1096f13f599cb43d48cda88)
Creating a new Throwable (and filling in the stack trace) can take
up to 150us. Since we do this on the critical path when sending
over SurfaceControl via binder multiple times, this is too much.
Instead, add an option to pass in callsite manually.
Bug: 159056748
Change-Id: I46c339c15a07192d61c4c546e46f260684a47120
Merged-In: I46c339c15a07192d61c4c546e46f260684a47120
Exempt-From-Owner-Approval: Large scale refactor
When the cross profile app op gets revoked, we need to
kill the app then send an app op changed broadcast to
the app. The problem with using killApplication is that
it is async and does not guarantee that the app is killed
before the broadcast is sent.
It also fixes an unrelated issue when
CrossProfileApps#clearInteractAcrossProfilesAppOps is called
from managed provisioning which is non system process, this
causes a security exception if killApplication is used.
Fixes: 156995567
Fixes: 157318765
Test: atest ManagedProfileCrossProfileTest
Test: atest ManagedProfileProvisioningTest
Change-Id: Iceedd57baeb64daccef072bc787b1e1cb1bfe814
Kill the app in both profiles if user/admin revokes
the cross profile app op permission, this is to ensure
that any cross profile bound services gets unbound as
soon as the app op is revoked.
Fixes: 154693902
Test: atest ManagedProfileCrossProfileTest
Test: atest FrameworksServicesTests:com.android.server.pm.CrossProfileAppsServiceImplTest
Test: atest CrossProfileAppsServiceImplRoboTest
Change-Id: Iaa3b9196468149c1cec51e9101989f1877374cc5
Most apps that declare the INTERACT_ACROSS_PROFILES permission do
not have it granted, but get the app-op instead. We do not
normally want platform-signed apps that are actually given the
permission to appear in the user-configurable section in Settings,
so we remove them from the return value of
canUserAttemptToConfigureInteractAcrossProfiles in this CL.
Note that OEM can choose to allow some platform-signed apps to be
user-configurable by including them in their OEM whitelist file.
This CL respects that and allows these apps to be configured by the user,
despite being granted the permission. If the user rejects the app-op,
PermissionChecker correctly returns false.
Bug: 149742043
Test: atest CrossProfileAppsServiceImplRoboTest
Change-Id: I693338507eec9cdc0ba10a3584e994a58d2d113c
Reset the INTERACT_ACROSS_PROFILES app-op for all apps on the device
when creating a new work profile. This ensures that user grants for
previous work profiles (perhaps with a different admin) are not saved
and also not restored with backup-and-restore.
Also, clear the shared preference storing which oem-whitelisted apps the
user has granted. This ensures that the user sees them all again
during work profile provisioning.
Fixes: 151145623
Test: atest com.android.managedprovisioning.task.CreateManagedProfileTaskRoboTest
Change-Id: I5f5c5aea1c36bd17a74c02e1b6fa9b4047f15003
* Added a new hidden API canUserAttemptToConfigureInteractAcrossProfiles
to be used in settings.
* Changed canRequestToInteractAcrossProfiles to return true when app is
not whitelisted by the admin or installed in the other profile, this
enables the app to navigate the user to the cross profile settings page
were more information about why they can't grant the permission will be
provided.
Bug: 149742043
Test: atest CrossProfileAppsServiceImplRoboTest
Test: atest CrossProfileAppsPermissionHostSideTest
Test: CrossProfileAppsTest
Change-Id: I9c7734d7ab0c7436d84a27604146ff539e1cb26a
Add the user ID so it's easier to see which user log messages refer to.
There's a bit of churn around conditionals in this to ensure that the
code complies with the style guidelines.
Fixes: 148376687
Test: make RunBackupFrameworksServicesRoboTests
Change-Id: I3ca92d21492fae4b89cb73fb39db1a490c796f5d
Stub jars should not be in statically linked except for inside
other stub jars.
Bug: 145995723
Test: build, flash and reboot
Test: FrameworksIkeTests, FrameworksNetTests
Change-Id: I503616de0143cc39dd189ae689de3e8d77c345da
Merged-In: I503616de0143cc39dd189ae689de3e8d77c345da
(cherry picked from commit 5fc0bbaae70508ebb9355387403d91e23fa64e73)
Stub jars should not be in statically linked except for inside
other stub jars.
Bug: 145995723
Test: build, flash and reboot
Test: FrameworksIkeTests, FrameworksNetTests
Change-Id: I503616de0143cc39dd189ae689de3e8d77c345da
This reverts commit 27c64a3bed785f1bd4bda4896b4df0807d0804d2.
Reason for revert: The GMSCore code to handle the flag will be part of DP2 and so we can remove the flag ahead of the cut.
GMSCore CL Status; https://cl-status.corp.google.com/#/summary/gmscore_prod/291378558
GMSCore Calendar; http://go/gms-schedule
Bug: 147481066
Test: m -j RunBackupFrameworksServicesRoboTests
Change-Id: I4159e064e739c6f366063c7fadd7cca40a7f07d9
Part of the Parsing/ParsedPackage split into core/server.
Moves core tests that are should now be in services,
and cleans up/migrates test code. Import changes, moving
classes into the server, and general small cleanup.
This is the final commit in the Parsing/ParsedPackage split.
Bug: 135203078
Test: enumerated in first commit of change ID
Ib4fe51d729a56bfb0ea1316e577358ba0dfceccf
Change-Id: I694da372feda070815e05b450807a18d71ec9b9d
This is required for the provisioning cross-profile consent screen which
is used to take some apps off INTERACT_ACROSS_USERS.
Hidden API CrossProfileApps#setInteractAcrossProfilesAppOp is changed
from requiring the broad app-op permissions to requiring
CONFIGURE_INTERACT_ACROSS_PROFILES. It then clears identity before
calling into AppOpsManager. For convenience, we also allow apps (such as
Settings) with the broader app-op permissions to continue to call this
method; in that case, we simply don't clear the identity and let
AppOpsManager check the permissions (so we allow AppOpsManager to set
the requirements if you don't have the new
CONFIGURE_INTERACT_ACROSS_PROFILES).
The CL also adds 'withCleanCallingIdentity' support to
CrossProfileAppsServiceImpl and moves over existing calls.
Bug: 136249261
Bug: 140728653
Test: atest --verbose com.android.managedprovisioning.provisioning.crossprofile.CrossProfileConsentActivityRoboTest
Change-Id: Ibd304563dd1ef5f16784e3502be5ef1ec4675b63
fef9247572bdb84b91f469ed9b7cc3995bf41609
Test: End to end test: run "atest GnssAntennaInfoRegistrationTest" on cuttlefish and watch "adb logcat | grep -i GnssAntennaInfo". Other tests: atest GnssAntennaInfoTest, atest GnssAntennaInfoProviderTest, atest GnssManagerServiceTest, atest VtsHalGnssV2_1TargetTest, atest LocationManagerFineTest.
Bug: 124556515
Change-Id: Ie1a8a60b9d7b9b95335bc84118639e33e0784ca1
Test: End to end test: run "atest GnssAntennaInfoRegistrationTest" on cuttlefish and watch "adb logcat | grep -i GnssAntennaInfo". Other tests: atest GnssAntennaInfoTest, atest GnssAntennaInfoProviderTest, atest GnssManagerServiceTest, atest VtsHalGnssV2_1TargetTest, atest LocationManagerFineTest.
Bug:124556515
Change-Id: I70e4014dd3959b0570c35bd2aa8bb839ef167d70
Bug: 145126096
Test: atest KeyValueRestoreExclusionHostSideTest
atest PerformUnifiedRestoreHostSideTest
atest UserBackupPreferencesTest
Currently PerformUnifiedRestoreTask gets the list of blocked restore
keys at construction. However, at that point the list might not be fully
constructed yet. We should get the keys through the getter avaialble in
UserBMS when we need them.
Change-Id: I62ad34138ba7a893e66d6af05d2e242c9c964a44
This will allow us to turn off the new functionality while the
transport implementations are updated.
Bug: 147481066
Test: m -j RunBackupFrameworksServicesRoboTests
Change-Id: I8c0019ff80d94dd8d94299a7b03b78e3081f2b8e
When the admin unsets cross-profile packages, reset the
INTERACT_ACROSS_PROFILES app-op back to the default if it is no longer
configurable by the user.
Other minor changes:
- Remove the explicit app-op permission check from
setInteractAcrossProfilesAppOp, since AppOpManager performs that check
when required.
- Fix the broadcasting logic in CrossProfileAppsServiceImpl to correctly
set the component and flags.
Bug: 136249261
Bug: 148010178
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.ManagedProfileCrossProfileTest
Change-Id: Ib8b5f331fb92fc475bc95ad039adf93fac04da37
Use hasPermissionOrAppOpForPreflight to check for
INTERACT_ACROSS_PROFILES permission or appop rather than only
checking for the permission.
BUG: 140728653
BUG: 136249261
Test: atest CrossProfileAppsPermissionHostSideTest
Test: atest CrossProfileAppsHostSideTest
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Test: atest ContextCrossProfileHostTest
Change-Id: I81d428d47afd54f294ef9bb44133004762840d09
In order to allow transports to know when a K/V backup would have
been performed, but was not due to no data changes being reported,
we need to introduce some code to find the K/V backup participants,
remove any which are backed up in this sweep or are currently failing
to back up due to an error, and then inform the transport of the
remaing set.
This CL introduces the code to do that.
We use a state file to determine if a package backed up without an
error on the last run, if the backup fails we remove the file for
that package. When all packages with changed data have been backed
up we get a list of all packages which have the file set (i.e. were
successful), remove the set of packages backed up on this run, and
inform the transport the rest had no data changes.
Bug:147481066
Test: m -j RunBackupFrameworksServicesRoboTests
Change-Id: I5c9f94c925096faf7b65307c0be1a7aba48c1cfb
