The deviceIsEncrypted() methods in BackupRestoreConfirmation.java and
UserBackupManagerService.java only return true if the device is using
FDE (Full Disk Encryption), for which support has been removed in favor
of FBE (File Based Encryption). Therefore, the logic to require a
backup password no longer applies to any device.
Remove this logic to simplify the code.
It is possible that this was actually a bug, and this logic should have
applied to FBE devices too. But given that the code has worked this way
for years, and there isn't necessarily a logical connection between
whether the device is encrypted and whether a backup *must* be
encrypted, I decided not to change the current behavior.
Bug: 208476087
Test: 'adb backup' and 'adb restore' still work.
Change-Id: Idc72d2a4c3e8bfa10a32cdc57884159b37635e81
(cherry picked from commit d5b040ed64)
Merged-In: Idc72d2a4c3e8bfa10a32cdc57884159b37635e81
This reverts commit 461ffb80e6.
Reason for revert: Breaking master, revert needs to be more targeted.
Change-Id: I8fe96ab08d3f82abd9edd3360e9e57d78a0bf6ce
Currently trying to restore a read-only directory results in only the
directory being restored but not its contents. This causes problems for
some apps (see the associated bug). Skip restore of read-only directories
while we evaluate the priority of proper suport for this use case.
Bug: 194894879
Test: Manual:
1. Populate a read-only directory in an app's folder
(/data/user/0/<package-name>)
2. Run backup for the app
3. Clear app data (adb shell pm clear <package-name>
4. Run restore for the app
5. Inspect app folder to ensure all writable content is
restored.
Merged-In: I644a5784fb42352ba28ac944d3aa3564b0215a78
Change-Id: I644a5784fb42352ba28ac944d3aa3564b0215a78
This change annotates dump/debug methods in services.odex that are
larger than 10000 bytes with NeverCompile so that they will not be
compiled. This results in an overall ~1% decrease in the size of
services.odex.
Bug: 215417388
Test: Build and check that these methods are not called during boot or
app startup.
Change-Id: Idf1417b0157fe8a42b9c9c1874806a7a81dd45cb
(This CL was already merged into sc-v2-dev but has to be manually
cherry-picked into master due to a conflict.)
Currently we create a new transport client in
UserBackupManagerService#beginRestoreSession but don't dispose of it
properly which leaves us bound to the transport service. The client can
eventually be garbage collected triggering the finalize() method which
will unbind the transport but there're no guarantees as to whne it will
happen.
Explicitly dispose of the transport client like it's done in other
places in the code.
Bug: 196377372
Test: 1. Manual:
1.1. Run restore for any package via 'adb shell bmgr'
1.2. Check logcat for TransportClientManager to make sure the
transport client created in beginRestoreSession() has been
cleaned up.
Change-Id: I9304768330ab796fccf67b544766d87461d977d7
(cherry picked from commit 4428e22d67)
This is to fix a bug where, if an app crashes in restricted mode,
when the user restarts the app, it would be launched still in
restricted mode. That happens because ActivityManager still has
a BackupRecord indicating that the app should be in restricted
mode, so next time the app launches, attachApplicationLocked()
calls IApplicationThread.bindApplication() with the restricted
mode flag set.
To avoid this we must complete the clean up actions done when
backup agents report errors. UserBackupManagerService has a
call-back method agentDisconnected() that is notified if an
agent dies. In that method we call handleCancel() on all
outstanding operations that are linked to the package name,
according to OperationStorage. The result is a call to the
Activity Manager's unbindBackupAgent() which then removes the
obsolete BackupRecord.
Two new tests for agentDisconnected() verify that appropriate
calls are made to OperationStore.
BUG: 161089758
Test: atest FrameworksServicesTests:com.android.server.backup
atest BackupFrameworksServicesRoboTests
atest CtsBackupHostTestCases
atest CtsBackupTestCases
atest GtsBackupTestCase
Also, manual testing with an app that deliberately dies
during full backup: the lifecycle operation storage is
used to cancel the backup; the app restarts in normal
and not restricted mode.
Change-Id: Ic4cf3875d59e3580b026340e884093f3aa1b09b9
Several other related classes are also updated to have a
dependency on OperationStorage, which removes a number of
tight bindings on UserBackupManagerService.
BUG: 161089758
Test: atest BackupFrameworksServicesRoboTests
atest CtsBackupHostTestCases
atest CtsBackupTestCases
atest GtsBackupTestCases
Change-Id: I644ef2cd1a3e8d8c35a269c140df8cc5f3654e16
This is preparatory work to fix bug b/161089758 where
it's possible for an app's BackupAgent to crash and leave
the app in 'restricted mode' when subsequently relaunched.
The bug fix involves storing new associations between
package name and operation tokens. Rather than further
extend UserBackupManagerService, this change introduces a
new LifecycleOperationStorage class, and interface
OperationStorage, which takes the responsibility for
storing Operations by token, the associated locking, and
adds the new mapping from package name to operation tokens.
Later changes will refactor UserBackupManagerService to
use LifecycleOperationStorage, and several related classes
to use OperationStorage.
BUG: 161089758
Test: atest FrameworksServicesTests:OperationStoreTest
Change-Id: I689d36cdf84504d7710f05f5abcd12fe4bb1b6d8
Currently we create a new transport client in
UserBackupManagerService#beginRestoreSession but don't dispose of it
properly which leaves us bound to the transport service. The client can
eventually be garbage collected triggering the finalize() method which
will unbind the transport but there're no guarantees as to whne it will
happen.
Explicitly dispose of the transport client like it's done in other
places in the code.
Bug: 196377372
Test: 1. Manual:
1.1. Run restore for any package via 'adb shell bmgr'
1.2. Check logcat for TransportClientManager to make sure the
transport client created in beginRestoreSession() has been
cleaned up.
Change-Id: I9304768330ab796fccf67b544766d87461d977d7
The change is auto-generated through IDE rename function and makes the
following naming changes:
1. TransportClient -> TransportConnection
2. TransportClientManager -> TransportConnectionManager
3. + corresponding test files
TransportConnection is a more appropriate name for the class as it's
exactly what it does - manages the connection to the remote
BackupTransport service implementation.
This is a preparatory change to making the BackupTransport AIDL async.
TransportClient name will later be used more appropriately for a class
that wraps the actual communication with the transport.
Bug: 202716271
Test: m -j
Change-Id: I76a98edc7102c8fcffdb050208e9e65543e6e10c
As part of widget restore, we need to notify participants (hosts &
providers) of the mapping between ancestral and new widget ids.
Prior to this change, this was done at the end of system restore
and after each restore-at-install of unbundled apps.
There were two issues with this:
1) We would try to notify not-yet-installed participants at the end of
system restore and then *not* try again when they were installed.
2) We relied on PACKAGE_ADDED broadcasts to know which participants were
installed, but these are delivered asynchronously and not guaranteed
to be processed before the restoreFinished call.
After this change, we:
1) Only notify participants that are actually installed
2) Use receipt of the PACKAGE_ADDED / CHANGED broadcast to trigger
notification of any restore participants that are added or changed
*after* system restore completes.
2 is safe because by the time PackageManager sends the package
added / changed broadcasts, the app data restore has been completed,
and the app has been killed if needed.
Bug: 162057170
Test: Manual restore of Keep widget via cloud and d2d
Change-Id: I51dec33d09b62faba6d7c7daacd718a3c0682f7d
The result from Binder.clearCallingIdentity() should be final in order
to prevent it from being overwritten before calling
Binder.restoreCallingIdentity(), which can cause security problems when
restoring the identity.
Bug: 157626959
Test: m checkbuild
Change-Id: I45e0e29fcefc35afa70d50dabfb79ada1579eae8
Mark app compat changes guarding the new opt-out rules for D2D transfers
as @Overridable. This allows enabdling / disabling the behaviour without
code changes.
Bug: 186833084
Test: m -j
Change-Id: I97396bd2a27c86ffccffec364cf57d9647bb760d
1. Remove unused appIgnoresIncludeExcludeRules() and associated tests
2. Remove logic for enforcing full backup for apps with k/v agents and
associated tests
3. Only ignore allowBackup for non-system apps in D2D and guard the
behavior by target SDK
Bug: 183147249
Test: atest BackupEligibilityRulesTest
Change-Id: Id8b0862dae492de69c553858e27859970278d7db
Determining the operation type (e.g. cloud backup or device transfer)
through transport flags doesn't work during restore. A cloud transport
can still be responsible for restore of D2D data. Instead, determine the
operation type for each restore set individually.
Bug: 182986784
Test: atest FullBackupRulesHostSideTest
Change-Id: I8109b99a712e6a60a15164416751d45e632264d6
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 f81af9df21.
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
Fall back to using the legacy android:allowBackup flag for apps that
don't specify the new ALLOW_ADB_BACKUP property. This is done to not
break GTS tests that rely on adb backup since corresponding apps can't
use ALLOW_ADB_BACKUP yet (ag/13205188 is blocked with some failure that
I'm currently investigating).
Bug: 175250895
Test: atest CtsBackupHostTestCases
Change-Id: Id40b2ae6b677afca18011077f57926518b28960f
http://ag/12885739 introduced a enforceCallingPermission(BACKUP) check
but callers of this API do not hold that permission. This CL fixes
this by changing the check to enforceCallingOrSelfPermission(BACKUP),
and clearing the binder identity in DevicePolicyManagerService, which
makes the system server process the owner of that call.
Bug: 158482162
Bug: 172466964
Test: atest com.android.cts.devicepolicy.{Device,Profile}OwnerTest#testBackupServiceEnabling
Change-Id: I11d863229c4d62a058aaf37446a694b9c73ae5b8
1. Adb backup is enabled by default for "android" package that corresponds to SystemBackupAgent (no change from current behavior)
2. System and privileged apps can use android.backup.ALLOW_ADB_BACKUP manifest property to enable / disable adb backup. Disabled by default.
3. Other apps can only use adb backup when running in debuggable mode.
Bug: 171032338
Test: 1. atest BackupEligibilityRulesTest
2.1. Run adb backup / restore for SystemBackupAgent and verify
success (running in system_server)
2.2. Run adb backup / restore for NexusLauncher with
"allowAdbBackup=true" and verify success (privileged app)
2.3. Run adb backup / restore for a non-privileged debuggable app
and verify success.
Change-Id: Ifefe6d888377d3ac9482928b27c86b2e562ad8fa
Base CL ag/12885739 introduced unconditional enforcement of the BACKUP
permission for callers of BackupManagerService.isBackupServiceActive()
in the service, but dropped the enforcement on the app process side
(BackupManager).
This CL makes the behavior change conditional on a compat ChangeId.
Bug: 158482162
Test: Manually checked that an app similar to the code sample from
http://b/158482162#comment1 can reproduce the behavior.
This is true both before the base CL and after this CL, when
the app targets an old SDK version (26).
Test: Checked that both (a) before this CL, (b) after this CL where
the change is manually enabled for the app via the below commands,
the app runs into a SecurityException instead:
$ adb shell am compat enable 158482162 com.example.tester
$ adb shell dumpsys platform_compat | grep 158482162
ChangeId(158482162; name=IS_BACKUP_SERVICE_ACTIVE_ENFORCE_PERMISSION_IN_SERVICE; enableSinceTargetSdk=31; packageOverrides={com.example.tester=true})
Change-Id: I58e5d2a0b438296137fd76720636c8fdce740ded
BackupManager runs in the client process, whereas BackupManagerService
runs in the system server process. Therefore, apps permissions need should
be enforced on the service side.
Bug: 158482162
Test: Manually checked that a sample app encounters SecurityException
after but not before this CL, when running code similar to the
sample in http://b/158482162#comment1 to figure out whether
isBackupServiceActive() for its own uid.
Change-Id: I59693819542a80a065a9c88373393b0ba0dbef65
No production code relies on the mutability. Code in fakeandroid's
AlarmManager added in http://ag/3826144 relies on the mutability,
and backup/internal/PerformInitializeTask sets a (now immutable)
PendingIntent, but fakeandroid uses a different AlarmManager instance
that the real system so these should be unrelated (I think - reviewer,
please double-check my thinking).
Fixes: 170163281
Test: Treehugger
Change-Id: I3dd45cc270c2fd8ab9d4b3402edc6cc5d765fd5a
* changes:
Upgrade AndroidFrameworkBinderIdentity to fatal.
Tighten up Binder.clearCallingIdentity() usage.
Tighten up Binder.clearCallingIdentity() usage.
Tighten up Binder.clearCallingIdentity() usage.
This is a third CL in a chain that adjusts existing malformed code
to follow AndroidFrameworkBinderIdentity best-practices.
Specifically, if a thread clears an identity they need to restore it
to avoid obscure security vulnerabilities. In addition, the relevant
"try" block must start immediately after the identity is cleared to
ensure that its restored if/when any exceptions are thrown.
Bug: 155703208
Test: make
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: I74cb958b68d55a647547aae21baff6ddc364859b
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
The recently added AndroidFrameworkBinderIdentity Error Prone checker
examines code to ensure that any cleared identities are restored to
avoid obscure security vulnerabilities.
This change is a purely mechanical refactoring that adds the "final"
keyword to the cleared identity to ensure that it's not accidentally
modified before eventually being cleared. Here's the exact command
used to generate this CL:
$ find . -name "*.java" -exec sed -Ei \
's/ (long \w+ = .+?clearCallingIdentity)/ final \1/' \
{} \;
Bug: 155703208
Test: make
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: I832c9d70c3dfcd8d669cf71939d97837becc973a
Context: KeyValueBackupTask's ctor takes a DataChangedJournal instance.
KeyValueBackupTaskTest uses a mock instance to check that remove() is
called. http://ag/12218310 made DataChangedJournal final, breaking the
test. This CL fixes the failure cause by making the class nonfinal.
Note that the test still fails because at least one unrelated failure
cause remains - see http://b/162022005#comment11
In the longer term, we may want to consider splitting DataChangedJournal
into an interface/abstract class + a concrete implementation; there's no
good reason why KeyValueBackupTask and KeyValueBackupReporter need to
depend on specifically the implementation class, when all they're calling
is remove() and toString(). However, the change to make the class final
wasn't important, and reverting it is the easiest / fasted way to unbreak
the test.
Bug: 162022005
Test: atest KeyValueBackupTaskTest
Change-Id: I22b2a5d65f03c4ccdcc718ed3866d37ba9441385
System server should not directly called Settings method such as Settings.Secure.getString()
instead of Settings.Secure.getStringForUser(). The "ForUser" methods allow us to properly
enforce the user's restrictions and it prevents issues like b/163571398.
This CL is part of the effort that changes existing usage of non "ForUser" methods
to using "ForUser" methods. It is supposed to act as a no-op.
BUG: 166312046
Test: builds
Change-Id: I632a243ec916a95437bcd32e5c480ab947eebb4e
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
See https://source.android.com/setup/contribute/respectful-code for reference
PerformAdb{Backup,Restore}Task handles backing up to and restoring from
a file. The backup data is encrypted with a randomly generated
encryption key. The encryption key is encrypted with a key that is
derived from a user supplied passphrase.
The key that was used to encrypt and decrypt the backup data used to be
called the "master key", I've renamed it to "encryption key" which
better describes its purpose.
Bug: 161896447
Test: `atest PerformAdbRestoreTaskTest`, `atest TarBackupReaderTest`
and manually tested using adb with the following commands:
`adb backup -all -apk -shared -f backup.ab` and
`adb restore backup.ab`.
Change-Id: I8e6b22a06b2a583440839994f0626d370bdb2e19
