We've seen at least one incident in the field that suggests we
used the same identifying token in back to back operations, which
breaks certain invariants in the asynchronous-completion bookkeeping.
Harden against this by making sure that we don't reuse tokens in
nearby proximity. This is done by making the low 8 bits a sequence
count, i.e. guaranteed unique within the last 256 operations, while
keeping the upper bits random so that apps can't guess at correct
tokens.
Fix 63691912
Fix 63553575
Test: CTS backup pass to completion plus manual inspection
Change-Id: I321c3a2b3f4203836800bb72db7332bd82e54aaf
We were failing to tear down a full-backup target process in several
error situations (preflight, quota exceeded, unforeseen), leaving the
app in an incoherent execution state for general operation. Now we
properly tear down the target in all full-backup early exits.
Fix#63540605
Test: run cts -m CtsBackupTestCases -t android.backup.cts.BackupQuotaTest
Change-Id: Id8f6fe0381e85a8d8e4015fc6fd34bb840859e7a
Calling finalizeBackup() the second time will most probably lead to underholding
the wakelock and system crash.
Bug: 63156509
Test: manual
Change-Id: Ic995ba4a65d749b80bf1f1d226d35a279a0d1b25
Existing instances don't know that the file has changed out from
under them, so they continue to return stale values from reads, and
risk overwriting restored data with stale content if writes are
performed. We now tell the backing cache system to induce a
reload after restore (i.e. after we might have written a relevant
file out from under it).
Along the way we shook out an irregularity in the way we were
setting up the context topology of non-lifecycle instances of
the metadata-handling BackupAgent subclass, so that's fixed
now too.
Bug 12061817
Test: cts-tradefed run cts -m CtsBackupHostTestCases
Change-Id: I401fe9297235b55d8a8f041e430d122dc6e24129
Also fixes the problem where it could through IndexOutOfBoundsException
instead of more natuarl EOFExcpetion in case there is not enough data in
the chunk.
Bug: 38081946
Bug: 37983441
Test: runtest -p com.android.server.backup frameworks-services
Change-Id: Icac575a76b752922b9c2d9cc0b3cad50f4273241
This keeps the install flow fast, and also happens to mean that
there is feature parity in this regard between pre-O and O+
instant app handling.
Fix#38263351
Test: manual
Change-Id: I8eb08c12d800f5288583e792621920c9876efdfc
Switching to buffered streams saved up to 50% of
BackupManagerService.onUnlockUser time:
Before:
SystemServiceManager: Service com.android.server.backup.BackupManagerService$Lifecycle took 389 ms in onUnlockUser
SystemServiceManager: Service com.android.server.backup.BackupManagerService$Lifecycle took 380 ms in onUnlockUser
After:
SystemServiceManager: Service com.android.server.backup.BackupManagerService$Lifecycle took 178 ms in onUnlockUser
SystemServiceManager: Service com.android.server.backup.BackupManagerService$Lifecycle took 155 ms in onUnlockUser
Test: manual
Bug: 37686433
Change-Id: I41185a88e8377b434fab6a3bf1fd7086758127cd
... and PerformAdbRestoreTask.
Involves some refactoring, splitting readAppManifest() into two methods.
Also a bit of cleanup: make private field actually private and use
static imports for some constants.
Bug: 38090803
Bug: 37619463
Test: runtest -p com.android.server.backup frameworks-services
Change-Id: Ic30a6c5a515da1efb67caaae6eb75f4313797d5c
Also add missing javadocs to some new classes.
Bug: 37939902
Test: runtest -p com.android.server.backup frameworks-services
Change-Id: I7c24cec754af9ea6caee7791a11085b8c174c427
It previously used a backup timeout of 5 min, and restore timeout of 1
min, that would always timeout if the files on shared storage were big.
Now increase both to 60 minutes.
Bug: 37201952
Test: adb backup -shared && adb restore backup.ab
Merged-In: Ice6648554933baf76e96fd151b506564487c91c6
Change-Id: I99095249e960fd47fc742154bc513347bf506548
Fix: 37304539
Test: runtest -x frameworks/base/services/tests/servicestests/src/com/android/server/backup/TrampolineTest.java
Test: setup device owner, then set up profile.
Ensure tapping Settings->Google->Work->Security -> Verify app
is working
Change-Id: I393308857ea6082dca167e3e417b946615a83c20
Previously, one could poison the current-dataset tracking by
inopportunely-timed use of the local (aka development) transport.
Now you can't: we reset the 'current dataset token?' tracking
whenever the user changes the active transport.
Also don't double-allocate return values sometimes.
Bug 37694618
Test: manual
Change-Id: I2cf5d42774522af830aecb99e65f43c4d0b5ce76
Moved more common classes and methods to utilities (automated).
Prepared for deduplication of restoreOneFile() method.
Bug: 37519282
Test: gts
Change-Id: Ibc3de8f7c6675f64c636aafe51a885cfbd162e3a
This was done for FullRestoreEngine but not for PerformAdbRestoreTask by
mistake.
Bug: 37519282
Test: it compiles
Change-Id: I17be3f07d3eed9113c36bbb47db6146fa7e76d64
This moves rest of common methods in FullRestoreEngine and
PerformAdbRestoreTask to TarBackupReader and FileMetadata.
Bug: 37519282
Test: gts
Change-Id: Iff1f95e87721e74c9c5764ab98c64026604eee9b
thread to another thread
The system_server process was being killed by Watchdog, as the main
thread was waiting for the mCancelLock for over a minute.
Bug: 35968123
Test: make gts -j40 && gts-tradefed run gts -m GtsGmscoreHostTestCases -t com.google.android.gts.backup.BackupManagerHostTest
Change-Id: Ia146569d2c741b35a6f6c9bfc4c5ddf8539b6242
This moves part of the common code for reading tar files from
PerformAdbRestoreTask and FullRestoreEngine to it's own class.
Change is mostly automated, but with some manual intervention which
doesn't change behaviour.
Bug: 37519282
Test: cts,gts,pts
Change-Id: I669b848e16196ae76fb9e820b786bbe248985e47
This is an automated change which moves all public static methods
from RefactoredBackupManagerService to respective utility classes.
Bug: 37519282
Test: it compiles.
Change-Id: I2f5765e430da3bd9a05e255dbd2656d5e667bf4d
This encapsulates back the fields which were decapsulated when splitting
out internal classes.
Bug: 37520921
Test: adb shell settings put global backup_refactored_service_disabled 0
&& adb reboot && adb shell bmgr backupnow --all
Change-Id: I9caa75b2f688de96bd5b245f43e0ae66cd9d023c
Only remove messages of types OP_TYPE_BACKUP_WAIT and OP_TYPE_RESTORE_WAIT, since OP_TYPE_BACKUP cannot time out and doesn't require cancellation.
This will prevent some unncecessary (false) warnings in logcat.
Bug: 36570881
Test: manual
Change-Id: I72ecf98438fff18616354b04638b7db5c943aa61
This is added because only logging before doRestore was previously
shown, which meant that if the doRestoreFinished timed out, it would
in the logs look like it was the doRestore timing out.
Test: adb shell bmgr restore com.android.calllogbackup
Bug: 36507762
Change-Id: I2bd6e59ed0c5b0128eaca41b627356d459000065
Also a bit of refactoring on TrampolineTestable and enable it for
presubmits.
Bug: 37520021
Test: manually ran the unit test.
Change-Id: I20214b70d3eb35017d50983bd8bebef93b66e839
Before it was returning null in case the service was not initialized,
but as the method signature has int as the return type, this was boxed
and unboxed which would cause NPE.
Now it will return BackupManager.ERROR_BACKUP_NOT_ALLOWED instead.
This doesn't include fix for the test, because it's going to be
cherry-picked into oc-dev, which doesn't have the tests.
Test: manually ran unit tests
Bug: 37535747
Change-Id: I186cf812a4ec67be943b5c4334c82e9af5320b7a
