This CL was merged earlier (ag/13484966) and then reverted due to the
new behaviour breaking D2D transfers.
Merge it again with all changes being controlled by a flag (default
off), see UserBackupManagerService:getOperationTypeFromTransport in this
CL. View the diff between patchsets 1 and 2 to only see what's changed
between the earlier reverted code and the fixed version of it (i.e. with
the flag).
The flag can be changed via adb for now, we will set it to true by
default once other components are ready.
Bug: 174216309
Test: atest UserBackupManagerServiceTest
Change-Id: I7473c9b4f8d0c4d20155be76930279184ffb17c4
This reverts commit f81af9df21be3f01d4364571085048e668510d9c.
Reason for revert: DroidMonitor: Potential culprit for Bug 180089773 - verifying through Forrest before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: I80d3f3233e40ade3bfa89b236ba114966a137c23
Earlier we introduced versions of BackupManager#requestBackup() and
BackupManager#beginRestoreSession() that take @OperationType as a
parameter (i.e. backup or device-to-device migration). Change the logic
to determine the operation type from the properties of the transport
(BackupTransport#getTransportFlags()). This will help avoid introducing
unnecessary APIs and save us from having to ensure consitency between
@OperationType passed through to BackupManager and properties of the
transport used for that operation.
Bug: 174216309
Test: atest UserBackupManagerServiceTest
Change-Id: I04a6014087c98efdeb8710fadc620b0856d7554b
Extracts large parts of the GNSS HAL into a central GnssNative class,
which can be faked for testing. This is a large step towards making all
GNSS code unit testable, and allows for more modular HAL configurations.
Begins to break up the GnssLocationProvider god object and pull
functionality out into other classes. Changes include:
-Making GnssCapabilities parcelable so it can be part of the API
-Splitting out the NMEA listener from status listeners, which
substantially reduces the burden of supported NMEA listeners as well as
the amount of GNSS<->AP communication.
-All GNSS listeners now respond properly to HAL restarts.
-Partially extract out emergency call detection.
Bug: 153129152
Test: manual
Change-Id: Idee0d548f38c6adf921cd6c28b5d815bbd366f8a
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
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
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
-Moves batching APIs from SystemApi to Public, and makes them
multi-client safe.
-Adds equals/hashcode to Location.
Bug: 171512333
Test: manual + presubmit
Change-Id: I6ee28f8229fdf49386cd370ea785de63b97e7cde
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)
This change is motivated by b/161248425 where the restore times out before all
call logs can be restored by CallLogBackupAgent. The CL increases
restore time limit for agents running in the system process. See the
linked bug below for rationale as to why the change is limited to system
agents only.
Changes in the CL:
* Split timeouts for restore session and agent restore into 2 separate
values in BackupAgentTimeoutParameters, so that the latter can be
changed independently.
* Pass application UID to #getRestoreSessionTimeoutMillis() so that we
adjust the return value based on whether the agent is part of the system.
Bug: 170076589
Test: 1. atest BackupAgentTimeoutParametersTest
2. Populate 7000 call log entries; run backup; clear call history;
run restore and verify it fails without the change and succeeds
with the change.
Change-Id: Id32e34973be380f7206cb9000ca95e6b76bbf8c0
This is a transitional step towards truth 1.0.1, where these APIs have
been completely removed.
Bug: 168765701
Test: m checkbuild
Change-Id: I26ab5ab82bb939bbd9553c05387ac8641eb468b4
Log a much wider variety of important events in memory for bugreports
and dumpsys. This will make debugging much easier, hopefully at a
minimal memory cost. Memory cost could be improved in the future as
well.
Test: manual + presubmits
Change-Id: Iab867575f783f1c5f41a405da66f72d5f52691bf
This method was added to operate as an internal variant of the
public getPackageUid method since pmInternal#getPackageUid already
exist. However, pmInternal#getPackageUid method just called to the
public interface, and enforcing permissions and visibility checks.
Since we don't expect any UID/permission checks in a local service,
any callers to this method requiring permission checks should be
migrated onto the PackageManager public method. Remove the original
pmInternal#getPackageUid and rename #getPackageUidInternal to take
its place.
Bug: 148235092
Test: Build pass and boot
Change-Id: Ibd4aa8a6a7743ff378a23e21c68efc52692580c7
Add an API to BackupManager to start restore in migration mode.
Bug: 160407842
Test: atest PerformUnifiedRestoreTaskTest BackupManagerServiceTest
UserBackupManagerServiceTest
Change-Id: I75fdb1c99edc3d11d1264d69e1f20c682d588479
This is just a plain refactoring: the removed methods in the changed
classes were called by default by the new methods in the superclass
(SystemService).
Test: m
Test: atest NotificationManagerServiceTest BackupManagerServiceRoboTest
Fixes: 161943081
Exempt-From-Owner-Approval: refactoring without side-effects
Change-Id: Ifd8df592eb4494cc0922b7e0b2ff20187b8a8b3e
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
After refactoring AppBackupUtils into BackupEligibilityRules (see the
other linked CL), update the usages throughout the code.
Bug: 161241479
Test: atest UserBackupManagerServiceTest
atest TarBackupReaderTest
atest BackupHandlerTest
atest PerformUnifiedRestoreTaskTest
Change-Id: I2a90c4f5b951fa3e3c564a1065ad10a88cc16273
Add an override of BackupManager#requestBackup where type of the
operation (a regular backup or a migration) can be specified.
Bug: 160407842
Test: atest UserBackupManagerServiceTest
Change-Id: Ia54fa26b040c3ec3612672585561794ff831afef
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
Exempt-From-Owner-Approval: Large scale refactor
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
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
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
