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
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
Add an API to BackupManager to start restore in migration mode.
Bug: 160407842
Test: atest PerformUnifiedRestoreTaskTest BackupManagerServiceTest
UserBackupManagerServiceTest
Change-Id: I75fdb1c99edc3d11d1264d69e1f20c682d588479
Differentiate between
1. when the service is null
2. the service is not activated
3. there is a remote exception
4. we cant get a restore session from the service
Bug: 137156961
Test: atest -v CtsBackupTestCases CtsBackupHostTestCases
Test: atest -v BmgrTest
Change-Id: I63f1005f43d8e3e23bbd629b183f128fa02bbac1
when user is removed.
For non system users, backup state is stored in both the user's own dir and the system dir.
When the user is removed, the user's own dir gets removed by the OS. This code change ensures
that the part of the user backup state which is in the system dir also gets removed.
Bug: 127650374
Test: atest -v CtsBackupHostTestCases:android.cts.backup.MultiUserBackupStateTest
Change-Id: I4ea252e8e6da608e36ec3ac335666923d88a8748
See build/soong/README.md for more information.
Also converts the rest of frameworks/base/tools/streaming_proto.
Bug: 122332340
Test: m checkbuild
Change-Id: I87c500c5464fb1722b4b518d89065f5e1ee29a97
Merged-In: Ieb54feb3902bddfd5a571369fbf50161ae646647
See build/soong/README.md for more information.
Bug: 122332340
Test: m media
Test: m RunBackupFrameworksServicesRoboTests
Change-Id: Ieb54feb3902bddfd5a571369fbf50161ae646647
Key changes in this CL:
- Backup is now disabled by default in non-system users unless DPM
activates backup for this user AND the system user is activated. This
provides gating for the multi-user B&R feature.
- Activation is done via an 'activate' file that is per-user (but lives
in the system user directory to account for locked users).
- isBackupServiceActive() handles both locked and unlocked users.
- Added a bmgr command to expose isBackupServiceActive() for testing
purposes and enforce appropriate permissions.
Future CLs:
- Handle future migration to backup on by default for non-system users
- Change CTS tests to use the new bmgr command
Bug: 121306407
Test: 1) atest TrampolineTest
2) Start system user -> service started; run backup and restore
successfully
3) Start non-system user -> ignored;
4) adb shell bmgr --user 0 activate true -> security exception;
adb shell bmgr --user 10 activate true -> security exception (work
profile);
adb shell bmgr --user 11 activate true/false -> creates/deletes activate
file and starts/stops the service
Change-Id: Ic77db9b8b2e5170dcf89bef863dac4713730797a
Bug: 118480337
Test: 1) atest RunFrameworksServicesRoboTests
2) atest BmgrTest
3) atest CtsBackupTestCases
4) atest CtsBackupHostTestCases
5) atest GtsBackupTestCases
6) atest GtsBackupHostTestCases
UsageStatsRestoreHostSideTest fails. I verified locally that this test
fails without this change too.
7) flashed device and ran:adb shell bmgr --user 10 backupnow --all
Logs and output are as expected since backupservice isnt active for user 10
log: Bmgr : Running backupnow for user:10
output: Error: Could not access the Backup Manager. Is the system running
8) flashed device and ran:adb shell bmgr backupnow --all
log: Bmgr : Running backupnow for user:0
output:
Running incremental backup for all packages.
Package @pm@ with result: Success
....
Backup finished with result: Success
Change-Id: Icfebe26f36276ea687d15c9f9c361c409313ae9d
Also put comment on RestoreSession saying that it doesn't kill the app
in the end.
Bug: 29255593
Test: Builds
adb shell bmgr help, verify usage
adb shell bmgr restore android, verify no-op
Change-Id: I89304149ea6c03a80937e321cf3a46fd173308e2
If BMS is not running, we should not run any bmgr commands and print an
error. This can occur after a device with a lockscreen reboots and has
not unlocked yet, as the backup service is not active before unlocking.
Bug: 80691476
Test: 1) Device with lock + adb reboot -> run any 'adb shell bmgr'
command -> prints error
2) Device with no lock + adb reboot -> run any 'adb shell bmgr' command
-> success
Change-Id: I101b61d18a637cdb945ffc4a5e989a5dd270ee32
Says that backups can be canceled if one already running. Put message
for running backups in dumpsys for checking.
Bug: 72484277
Test: Triggered backup, checked dumpsys and bmgr backupnow
Change-Id: I028cf663858e374389f50175aaf5a3e8c9d45e42
Migrate usages of the transport binder to binding on-demand:
* getDestinationString()
* isAppEligibleForBackup()
* dump()
For getDestinationString() we'll be introducing an invisible bug for
people that haven't updated GMSCore to include the usage of
updateTransportAttributes() API introduced in earlier CL. The bug is
that that text won't change, it'll remain constant. It's invisible
because currently only place that uses that method is Settings in some
circumstances that depend on the transport, and those circunstances
don't happen with our transports. Check http://ag/1831025.
For isAppEligibleForBackup(), a new filterAppsEligibleForBackup() is
created and there we bind on-demand.
Change-Id: Idc9e31f0e8eda8531e204c05a84fafdaf0247d08
Ref: http://go/br-binding-on-demand
Bug: 17140907
Test: adb shell dumpsys backup, observe destination of transports
Test: adb shell bmgr backupnow --all, observe only eligible apps got backed-up
Test: Force-loaded settings screen and observed destination string
Test: m -j RunFrameworksServicesRoboTests
Without this, exec()ing these fails.
Found with `grep -L bin/sh $(grep -Rl Script)`
Bug: None
Test: exec()ed each of these scripts; I no longer get "exec format
error" for any of them.
Change-Id: I47db5007e5cc14ab91eb846b7bffecb925d37874
bmgr init TRANSPORT [...]
will run an init operation on each named transport, blocking
until the operations have all completed.
Bug 62253989
Test: manual
Change-Id: I7dbd94293738d5ecf195764f5b28905253819791
This CL adds more instumentation to
backup/restore operation in the BackupManager. For more details please
point to:
https://docs.google.com/document/d/1sUboR28LjkT1wRXOwVOV3tLo0qisiCvzxIGmzCVEjbI/edit#
This first Cl introduces 3 events that we sent to the monitor.
The base cl is ag/1835775
Test: TODO
BUG: 34873525
Change-Id: I127fe739a7522078eecce2ae689a4607203a98da
This is the first CL of many that will add instumentation to
backup/restore operation in the BackupManager. For more details please
point to:
https://docs.google.com/document/d/1sUboR28LjkT1wRXOwVOV3tLo0qisiCvzxIGmzCVEjbI/edit#
This first Cl introduces 3 events that we sent to the monitor.
Test: ag/1858962 (same topic)
BUG: 34873525
Change-Id: I6c338b6fd9f4d7c8670dac201897250b6b170677
This cl adds an API to select a backup
transport by its component name and
receive a callback when BackupManager
is bound to the transport. Calling this API
will make BackupManager bind to the transport
if it isn't already bound to it.
Also fixes the issue where BackupManager would
detect only one transport per package.
Ref: go/backup-transport-switching
Bug: 33616220
Test: Manually tested. GTS tests will be put up shortly.
Change-Id: I8c23bdbb84ceb05eb1fad9b3a8b9c4441cb06c74
This cl adds a new requestBackup API to
BackupManager that takes in an int flag
to indicate whether the caller wants the
entire key value set to be passed to the
transport and not just a diff.
Change-Id: Ia225797a58c4431fe742f2f116b257d006b30cd1
Bug: 33749084
Ref: go/request-backup-api-changes
Test: GTS Test at ag/1774002
Replace some custom rules with BUILD_PREBUILT.
Move tools from ALL_PREBUILTS to BUILD_PREBUILT. All of them are already
in PRODUCT_PACKAGES in build/target/product/base.mk.
Remove uses of ACP and replace with core build system macros or 'cp'
Change-Id: I529e7c6c50fc64ad36b75bb47142f6bde909d141
Add support to QUOTA_EXCEEDED error output.
Command "backupnow --all" without parameters now starts backup of all eligible packages.
Change-Id: I563be35d575346d3dfb45a6dd254b387053c7ab7
(cherry picked from commit d5d68528bc)
The new command works as "bmgr backupnow [list of packages]"
This change should be submitted after ag/834173
Change-Id: Ie1cdd18a38653dd71a1d499620dd2afec3cbbb24
Also make it handle the list of packages to be backed up as a single
multiple-app argument to fullTransportBackup() rather than N calls
each backing up one app.
Change-Id: I9fe4d5caca54fafef70ffe9af4c26e3941dc5d26
Currently no timed/scheduled full-data backup operations are
performed by the OS, but the plumbing is now in place and can
be tested using 'adb shell bmgr fullbackup pkg [pkg2 pkg3 ...]'.
The LocalTransport test transport implementation has been augmented
to support the new full-data backup API as well.
In addition, 'adb backup' now takes the -compress/-nocompress
command line options to control whether the resulting archive is
compressed before leaving the device. Previously the archive was
always compressed. (The default is still to compress, as it will
usually reduce the archive size considerably.)
Internally, the core implementation of gathering the full backup
data stream from the target application has been refactored into
an "engine" component that is shared by both 'adb backup' and the
transport-oriented full backup task. The archive file header
generation, encryption, and compression logic are now factored out
of the engine itself instead of being hardwired into the data
handling.
Bug 15329632
Change-Id: I4a044faa4070d684ef457bd3e11771198cdf557c
The init & clear operations are particularly important to ensure
delivery when at all possible, so we retry those periodically
if the transport is unavailable when we first attempt them.
Now with 100% less build break.
Bug 11716868
Change-Id: I2af4e93788068cfac97c0a48d3568c561eefa23d
The init & clear operations are particularly important to ensure
delivery when at all possible, so we retry those periodically
if the transport is unavailable when we first attempt them.
Bug 11716868
Change-Id: I4860fe3d4e99618b2cd194c83162bd7cbd5a83a9
