| e77c12ba37b7358ef6b6a6010e778926cc4194b8 |
29-Jan-2015 |
Christopher Tate <ctate@google.com> |
Don't run full-data backups when backup is disabled
If the scheduled job fires but backup is disabled or the device is
not yet provisioned (i.e. has not yet finished going through setup),
bow out gracefully without running any backup operations. Also, even
if a backup is directly invoked (e.g. via adb), verify again right
before we start collecting app data, and abandon the operation in
that path as well.
(This is redundant; having only the latter test would suffice, but
this lets us distinguish in the logging more easily.)
Finally, make sure that if we were waiting on setup before permitting
backup operations to begin, that we startup the full-data scheduling
as well as the [separate] key/value scheduling.
Bug 19197062
Change-Id: I3d8fb650c50f946d8ed7ac7170df361c707f2528
om/android/server/backup/BackupManagerService.java
|
| cf962601186a05a8818c02b690c1e7b5c15144f1 |
16-Jan-2015 |
Christopher Tate <ctate@google.com> |
Don't write widget metadata to backup unless it's new/changed
Redundant backup traffic is bad. Don't commit the widget metadata payload
(or the deletion operation for it) unless the widget state of the app has
actually changed since the last backup.
Bug 19003911
Change-Id: I93819173c0e2357b030d9e2b3d2ee57f2410bb57
om/android/server/backup/BackupManagerService.java
|
| b89e1405cf9f1da533dc0843390a1b6783abb0f4 |
07-Jan-2015 |
Christopher Tate <ctate@google.com> |
Support single-package backup rejection by the transport
We now cleanly handle the case of the transport blacklisting specific
packages from key/value backup. Previously we would halt the entire
backup pass and reschedule if the transport returned any error from
performBackup(pkg). Now, we recognize the TRANSPORT_PACKAGE_REJECTED
result from that invocation, and properly drop that package's work
but proceed with running the rest of the backup queue as expected.
Bug 18694053
Change-Id: Id0dd6d59492bdea9f970540d776f37db0cc5d99c
om/android/server/backup/BackupManagerService.java
|
| 603ad6f7d00b6c1687102f4679314af533f18f6a |
06-Jan-2015 |
Christopher Tate <ctate@google.com> |
Remove the "backup_data_changed" event log
Nowadays it's just spammy and uninformative, so away it goes.
Bug 18833115
Change-Id: Ic373c596d7a892c4fedc0343e2c03dc1c295225e
om/android/server/backup/BackupManagerService.java
|
| 22192ada99691221f9ab167c046fb71c23baf723 |
05-Dec-2014 |
Christopher Tate <ctate@google.com> |
Correctly parse previous PMBA state during backup
Bug 18628030
Change-Id: Iefa23de50dd9e1b27cfa5d887f117876d57e4083
om/android/server/backup/PackageManagerBackupAgent.java
|
| a7e47d5d344674f4174919c4ac51e5b9c74b5802 |
01-Dec-2014 |
Christopher Tate <ctate@google.com> |
Don't crash if a system restore fails before constructing the PMBA
If a whole-system restore operation failed at just the wrong point,
we'd wind up in the teardown code without a certain vital bit of it
having been initialized, and crash on the null pointer. Now we
recognize this failure mode and make sure not to do that.
Bug 18574450
Change-Id: Ifa2c10ce16bb3c6bc916ed7151c5fd51b7225691
om/android/server/backup/BackupManagerService.java
|
| 201caf57f9a9699e04620eac9b1fcdaf4338d2f0 |
12-Nov-2014 |
Zoltan Szatmary-Ban <szatmz@google.com> |
Adding method to query backup manager service activity status
Bug: 17367491
Change-Id: I9920c07d56c4c0ccb1f3dce637c0fb390902d2ff
om/android/server/backup/Trampoline.java
|
| bbe23b31dcd0eec8af5b5198970de7ff2a9ef79a |
30-Oct-2014 |
Christopher Tate <ctate@google.com> |
Enable runtime turndown of backup/restore services
The heavy implementation of the backup manager service is now sitting
behind a lightweight trampoline that actually provides the binder
call interface. The indirection allows us now to tear down the
implementation on the fly without breaking callers who have cached
binder references to the backup services: these callers will simply
see their future invocations failing benignly.
In addition there is now an API for suitably privileged callers such
as device policy management to effect this turndown.
Finally, there is now a static system property, "ro.backup.disable",
that a product can use to outright remove backup/restore operation
from the system's operation. The public APIs will continue to be
safely usable on such products but no data will be moved to or
from the device.
Bug 17367491
Change-Id: I8108e386ef3b5c967938fae483366d6978fe4e04
om/android/server/backup/BackupManagerService.java
om/android/server/backup/FullBackupJob.java
om/android/server/backup/Trampoline.java
|
| a28b5c51602ccc48f2672274dabda05d3776ccd9 |
16-Oct-2014 |
Christopher Tate <ctate@google.com> |
Eliminate race condition around backup completion + resumption
Ensure that the callback always sees the current-operation state in sync
with the various other bits of internal backup-operation state. Previously
only the current-operation state was managed inside the critical section;
this resulted in a slim race window where a callback could see an ongoing
operation as still valid, but after the internal state on which that
operation depended had already been cleared.
Bug 17931760
Change-Id: Ia032668e7a9d22f1029c57fc98db9e86484d5719
om/android/server/backup/BackupManagerService.java
|
| 0f32717a17307ee581381d7f8527b686aacb3ac4 |
16-Oct-2014 |
Christopher Tate <ctate@google.com> |
Fix spurious restore session timeouts
The restore-session idle timeout should not be ticking while we're
doing legitimate restore work. We now explicitly stop the timeout
ticker [a delayed message on our handler thread] whenever we undertake
a valid restore operation. The timer is already correctly resumed
when restore operations conclude.
(In practice we need to suspend the timeout tracking at exactly those
times when we're entering the wakelock-protected restore flow. The
timeout is reestablished when the wakelock is released; this part
is already in the code.)
Bug 17990544
Change-Id: I7318020ce30fd9c35bc3a644f8c101fd3d063c8b
om/android/server/backup/BackupManagerService.java
|
| 2aa1d18e3acd269ed7a5f5a4843d447735f0676c |
10-Oct-2014 |
Christopher Tate <ctate@google.com> |
Fix bug 17931760 - spurious timeout leads to mayhem
We know a priori that the PMBA metadata package's backup pass
doesn't need to be tracked for timeout, because it's run inline
rather than as an asynchronous separate-process operation.
Change-Id: Ifd21ab3a016917f5e557a38c1c88f8d8ac1337d2
om/android/server/backup/BackupManagerService.java
|
| 6067d79807653172de9772d8cfd5e914557207b7 |
08-Oct-2014 |
Christopher Tate <ctate@google.com> |
Actually tell the widget service that restore is starting
Before beginning a full-system restore we need to tell the widget service,
so that it can properly start remapping IDs from the ground state.
Bug 17869323
Change-Id: I152257563f5b52cae67244e936bc2c44ced7618d
om/android/server/backup/BackupManagerService.java
|
| ecae2116169e4cc7c109fcfc2aa9f5be1d105995 |
04-Oct-2014 |
Christopher Tate <ctate@google.com> |
adb backup/restore fixes
Bug 17811327 : teach adb restore about the new widget metadata entries
Bug 14165872 : -nosystem should not act like -onlysystem
Change-Id: I39da0ba80df7c5309a78ec1fa38016cebd80aa5f
om/android/server/backup/BackupManagerService.java
|
| 64f10efab72aa7701a8d292425f4f56f04ca556b |
12-Sep-2014 |
Christopher Tate <ctate@google.com> |
Track enable/disable of transport components
For fallback / rollback of backup transport selection we need to
handle live enable/disable of legacy or superseded transports.
We now watch for component enable state changes in packages that
host transports, and rebind as needed.
The semantics for selecting the current transport have also been
adjusted. We no longer require that the selected transport be
live and currently bound in order to be designated as the active
instance. This prevents nondeterministic races around upgrade
and replacement.
Bug 17136637
Change-Id: Idaf45cf4522a23576444e6b11626ee3f7f47c36c
om/android/server/backup/BackupManagerService.java
|
| 539b217b764562964c7f11b416da8391cb7cf93f |
03-Sep-2014 |
Christopher Tate <ctate@google.com> |
The transport system API needs to manage binder identity
...around writing settings. It does its own proper permission check;
it just needs to make sure not to accidentally crash the caller in
strange and wondrous ways because of failing to clear binder identity
before writing the result to secure settings.
Bug 16542048
Change-Id: I88d1f2dbeebd24eed5d86989f0ca0d834878b054
om/android/server/backup/BackupManagerService.java
|
| 674d3e750133efc4b2d575d806596d1f56bda8d9 |
27-Aug-2014 |
Christopher Tate <ctate@google.com> |
Do not require device provisioning to do restore-at-install
Provisioning is a milestone used for gating *backup* operation,
but it's important that restores be possible during the setup
process. In particular, some applications such as home apps may
be deliberately pushed for install after platform restore, but
before the end of the setup process. We need to be able to do
install-time restores of such apps.
Bug 17288313
Change-Id: Iaff5d9919e6392b2ca5925be4d63a4116cd11f77
om/android/server/backup/BackupManagerService.java
|
| 915f1dc785886ecd14a5222778f7d46f0243b1f5 |
27-Aug-2014 |
Christopher Tate <ctate@google.com> |
Remember having done full-data as well as key/value app backups
The "what have we ever succesfully backed up?" log is used to determine
whether we can do an install-time restore from the currently-live dataset
rather than go back to the ancestral dataset (if any). We now track
apps that have gotten a successful full-data backup through the transport,
not just key/value backups.
Bug 17263823
Change-Id: If21350a8dd8aaa4ed02fb74101617e935920e4ae
om/android/server/backup/BackupManagerService.java
|
| b8e6838583c9d784a7e8d030999d57eb2e87a561 |
23-Aug-2014 |
Paul Lawrence <paullawrence@google.com> |
Merge "Fix adb backup for encrypted case" into lmp-dev
|
| d1c06753d045ad10e00e7aba53ee2adba0712ccc |
22-Aug-2014 |
Matthew Williams <mjwilliams@google.com> |
Implement API review feedback for JobScheduler
BUG: 17005336
Took the opportunity to clean up some back-off logic
Change-Id: Ibc8ae34d1d44dd064ba071e4cbad17872f7e38cf
om/android/server/backup/FullBackupJob.java
|
| e7bbe47833160d05bc31fa33f6d2e6134f3cb8e9 |
22-Aug-2014 |
Christopher Tate <ctate@google.com> |
Merge "Automatically bind to newly-installed backup transports" into lmp-dev
|
| 5684dae9ccceb756c9b44b80931ccac9af198ea6 |
22-Aug-2014 |
Christopher Tate <ctate@google.com> |
Automatically bind to newly-installed backup transports
They'll be rebound automatically at boot, but need to be brought
up immediately. As always they can only be provided by privileged
apps.
Bug 16542048
Change-Id: I9f121a5c111a772deb3f0c44166002a2cbb16ad5
om/android/server/backup/BackupManagerService.java
|
| 32d06732cdb7ee653a58e49a4dab13a780513db5 |
21-Aug-2014 |
Paul Lawrence <paullawrence@google.com> |
Fix adb backup for encrypted case
New behavior. Backup no longer uses the encryption password. This is in
part because that is hard with patterns, in part because it is a security
issue - the off line backup is much easier to brute force than the phone.
Instead, we simply insist on an encryption password if your device is encrypted
and locked.
Bug: 17159330
Change-Id: Ia22f84722522abf0b569a3ef1e16ead5527c726d
om/android/server/backup/BackupManagerService.java
|
| 8def5cbb3a1a68bb66fbe7ce63fcc8eadcbb238d |
22-Aug-2014 |
Brian Carlstrom <bdc@google.com> |
Move SystemBackupAgent from services.jar to frameworks.jar
Bug: 17168017
Change-Id: I89b98ca839a78eeb7fb43930e0699ee235deafad
om/android/server/backup/SystemBackupAgent.java
|
| b2707afb0cbf955952d313e4c75fd3bfd3a35e98 |
20-Aug-2014 |
Christopher Tate <ctate@google.com> |
Maintain transport connection through package updates
When a package is updated, existing bindings to that package's
services are severed and must be manually re-established. Now
that the transport can be updated outside the system per se,
make sure that we detect these cases and rebind as needed.
Bug 16139912
Change-Id: I5d6fa75bb86484f8f7d4f8e93c9157773995e6a7
om/android/server/backup/BackupManagerService.java
|
| 9dbba1b669eeb69316b70dbc9e457f8f8b084ea1 |
20-Aug-2014 |
Christopher Tate <ctate@google.com> |
Don't crash good-citizen restore session clients
If an app is trying to do the right thing and end its restore sessions
cleanly, but winds up being slow and having the session timed out from
under them, don't crash them with an illegal state exception for having
appeared to end the session twice.
Bug 17133115
Change-Id: I0a0989e2067b156569bddb6626ce045e625c6604
om/android/server/backup/BackupManagerService.java
|
| 10ab095a5be2cc45354266b8fbe642c3facafd55 |
18-Aug-2014 |
Christopher Tate <ctate@google.com> |
Minor restore fixes
1. We were missing a 'break' in the session-timeout case of
message dispatch, so were falling through into a different
case. Oops. Fortunately it was benign; the other case's
logic was merely logging "hey it doesn't look like there's
anything to do here" and cleanly exiting.
2. After a restore operation finishes we were previously
always leaving the session timeout clock running. However,
this was not appropriate in the case of restore-at-install,
when the restore was a one-shot kicked off by the package
manager rather than an operation on an ongoing RestoreSession.
That logic now properly tidies up the session timeout when
winding up the restore in either situation.
Bug 17080648
Change-Id: I51d4a50db4feefc4c355230a3bfb926ea2fb5944
om/android/server/backup/BackupManagerService.java
|
| a63246d6daa02c6f3e4e78d0072d991387e14c87 |
15-Aug-2014 |
Christopher Tate <ctate@google.com> |
Tighten restore-at-install behavior
Harden the guarantee that if we're asked about a possible restore,
we always ALWAYS report back to the package manager. This involved
closing "should never happen" edge cases around provisioning/auto-restore
setting that nevertheless were happening.
Also, on the auto-restore setting front, make sure to plumb that
system API through appropriately, since going behind its back and
manipulating the secure setting directly would cause things to get
out of step.
Bug 17060654
Change-Id: I52ca9c1ffbfc0bd6b57196157500d0868bfc2989
om/android/server/backup/BackupManagerService.java
|
| bf1a4a81ebd340a18583f4ca9b5d562a01f55674 |
09-Aug-2014 |
Christopher Tate <ctate@google.com> |
Start using cancelFullBackup() when appropriate
The API was in place but the framework wasn't yet calling it.
Bug 16524520
Change-Id: Ie368758c830a7d0ad11e7dd3142a0ed896069944
om/android/server/backup/BackupManagerService.java
|
| 0660244119243928a69e5f21ef5ea339c7f6d008 |
07-Aug-2014 |
Christopher Tate <ctate@google.com> |
Merge "Sanity-check paths of files to be restored" into lmp-dev
|
| 4cf9f007e6b66c0a970600f66b4229c4ede73f7f |
06-Aug-2014 |
Christopher Tate <ctate@google.com> |
Add event logs for full backup/restore milestones
Bug 16689703
Change-Id: If870f1b7b9cb3929ac1edc38affc688a37c2acfd
om/android/server/backup/BackupManagerService.java
|
| 46db93404b27fe5ec121ab55527712e2a6692c7a |
30-Jul-2014 |
Michael Wright <michaelwr@google.com> |
Ensure backup schedule file is closed.
Change-Id: Ie4a62cda74815c67c62fb08e8df25a71d6102d4c
om/android/server/backup/BackupManagerService.java
|
| cce476034388383a6006555a225e2170f3b4dcd9 |
04-Aug-2014 |
Christopher Tate <ctate@google.com> |
Sanity-check paths of files to be restored
The duplicated implementations are an artifact of an ongoing
refactor of the full-data restore code. The adb-specific path
will be switched to use the FullRestoreEngine [as has already
been done for the 'adb backup' path using the parallel full
backup engine], at which point the extra implementation here
will be removed, but for now we need to make sure that all
bases are covered.
Bug 16298491
Change-Id: I9cdb8a1c537939a620208df3cf0e921061b981ad
om/android/server/backup/BackupManagerService.java
|
| 7dfbaf52db6401ae85588e334be5af751bb813a8 |
29-Jul-2014 |
Christopher Tate <ctate@google.com> |
Make archive metadata idempotent
We want to make sure that the manifest and widget metadata
blocks are identical, including their in-stream headers, if
we regenerate the archive without underlying filesystem changes.
Bug 15968355
Change-Id: I828b264545d19e1d865d98d5723915d02fafc012
om/android/server/backup/BackupManagerService.java
|
| c17739d112d8e7076924c7fdd98614abafd58609 |
29-Jul-2014 |
Christopher Tate <ctate@google.com> |
Provide outside-facing API for data management intent+label
Bug 16346320
Change-Id: I3f4c2f4b700c77880ba3d8db7c92cdb404763d0d
om/android/server/backup/BackupManagerService.java
|
| 5eeb59cceb1f95813c548c1c5937f161c1ed3571 |
22-Jul-2014 |
Christopher Tate <ctate@google.com> |
Schedule full backups
Initial policy: at most daily; backups only run when the
device is idle + charging + on an unmetered network.
Bug 16485874
Change-Id: I5665d890a943bac765adcef14be79d7dba6ce078
om/android/server/backup/BackupManagerService.java
om/android/server/backup/FullBackupJob.java
|
| 7ff106c20d403e3217f5f384e63737285e2668a2 |
25-Jul-2014 |
Christopher Tate <ctate@google.com> |
A couple of restore fixes:
* Fix crasher after transport-level failure attempting to ask for
the name of the next package to be restored
* Current-dataset single-package restore path no longer requires
that the package have its own backup agent.
Bug 16548983
Change-Id: Id37f2f0e6075d53c414d9a997bf738bbf0cfff8b
om/android/server/backup/BackupManagerService.java
|
| a4e4d68f08c1d48a3cdcf83617468370366d03d4 |
23-Jul-2014 |
Christopher Tate <ctate@google.com> |
Handle single-package restores properly
Bug 16346405
Change-Id: I69e3288f5a9d68d818fad6a2cd4b27ad45c1007e
om/android/server/backup/BackupManagerService.java
|
| f7cbb1fc25223bbf793f7128280ee4b00d509eb0 |
22-Jul-2014 |
Christopher Tate <ctate@google.com> |
Always check restore against the latest backend metadata
Bug 16484934
Change-Id: I472a7db89a94b9804f6ea94c25da206dd111a497
om/android/server/backup/BackupManagerService.java
om/android/server/backup/PackageManagerBackupAgent.java
|
| 89101f7fe89134a609459e80f779c1a5114e562a |
18-Jul-2014 |
Christopher Tate <ctate@google.com> |
Tear down agents properly at EOD in full restore
The restore engine wasn't tearing down the bound agent after reaching
the end of data for the app, and furthermore was allowing the restore
operation to resume running the queue before all data had been delivered
to the current target.
Also make LocalTransport deliver data in 2K chunks rather than 32K,
as a first step towards making its timing characteristics more like
we'll see in networked situations.
Finally, added a bunch of MORE_DEBUG output for finding odd bugs
like this.
Change-Id: Icdbe6a070af6cc7c708a938ad044108d40ebce9a
om/android/server/backup/BackupManagerService.java
|
| 5f7f252b451f94bc09e2e5b880e026c28a9c2d0b |
18-Jul-2014 |
Christopher Tate <ctate@google.com> |
Properly end full restore attempt if getNextFullRestoreDataChunk() fails
Don't just drop the error return on the floor and retry (forever!).
Change-Id: I5f0ef2d09ea286d813add69517f865e474341b43
om/android/server/backup/BackupManagerService.java
|
| 2e40d115ca4332d88424d1b591fdd8d5f78d1831 |
15-Jul-2014 |
Christopher Tate <ctate@google.com> |
Add BackupAgent.onRestoreFinished() callback
The agent's onRestoreFinished() method is called after all available
data has been delivered to the app, whether via the key/value restore
API or the full-data file-at-a-time API. This gives the app a stable
opportunity to do any postprocessing that might be appropriate.
Also fixes a lingering bug in the framework's handling of backup
agent lifetimes. In cases where an existing agent instances was
being rebound, the framework was forgetting to notify the dependent
that the agent was available. This was causing timeouts and restore
failure.
Bug 16241004
Change-Id: I3f52b299312d30d38b0cba63a2cfaeb934991ef2
om/android/server/backup/BackupManagerService.java
|
| a176d22110a1670f363ba0f745f127d2b6ca2350 |
16-Jul-2014 |
Christopher Tate <ctate@google.com> |
Always call finishBackup() if performFullBackup() succeeded
Even if we later get an error from sendBackupData() we need to give
the transport its teardown callback. This simplifies the transport
logic considerably.
Change-Id: Ib8c0e210d4a876ee6b083a4d619dfccc462da4e5
om/android/server/backup/BackupManagerService.java
|
| a7835b6b6b00923b608a6bc3194e7840f67de7a8 |
12-Jul-2014 |
Christopher Tate <ctate@google.com> |
Add Context.getNoBackupFilesDir()
This is an app-private filesystem space exactly like the one
reported by Context.getFilesDir(), with one exception: files
placed here are never backed up by the full-backup infrastructure.
If an app attempts to back up any of its contents via the normal
API it's immediately ignored with a logged warning.
The restriction is also enforced on the restore side, because
apps using support libraries might wind up creating full backup
archives containing no_backup subdirs on pre-L devices (via
adb backup, Helium, &c.). We check for this before passing the
restore data to the app, and drop it if we detect the situation
so that the app never sees the bits.
Bug 16240573
Change-Id: I11216a391f1d32117ec7ce15aafc9cd93d0337de
om/android/server/backup/BackupManagerService.java
|
| 8f1bb3a0d47a4cb34471464dff2af932772a7ade |
08-Jul-2014 |
Christopher Tate <ctate@google.com> |
Fix NPE in platform restore
Bug 16061451
Change-Id: I79d7913455886828a493a0c4ea850d259bfeeeab
om/android/server/backup/BackupManagerService.java
|
| d746057f2414cba2bdc69257cc5be8cb681bb592 |
07-Jul-2014 |
Jeff Sharkey <jsharkey@android.com> |
Change new file installs to be cluster-based!
Now that all the other pieces are in place, we're ready to start
installing new file-based packages as a cluster (the new unified
directory-based layout). This greatly simplifies the renaming
process.
Also add helper methods to ApplicationInfo to give a much clearer
mapping between it and internal field names, since we can't change
the public API.
Add recursive restorecon().
Bug: 14975160
Change-Id: I72a63c5ddbc594c2fec4a91dd59f73ef253fbfd7
om/android/server/backup/BackupManagerService.java
|
| 51fea57e06fcb1dab1d239a5fff6e75ba2b7cee7 |
24-Jun-2014 |
Christopher Tate <ctate@google.com> |
Refactor restore to deal with heterogeneous datasets
Transport-based restore now handles both key/value and full-data
(stream) data delivery.
Also: PMBA now holds metadata for *all* apps, not just those with
backup agents. Since we need to consult this for every restore-
at-install operation we cache this locally now, tagged per transport
and per remote dataset, to avoid having to re-download it as part
of every future restore operation.
Also fixed a bug in LocalTransport that was preventing restore of
key/value datasets, i.e. all of them that were nominally available
prior to this change.
NOTE: at present there is no automatic full-data backup; if for
testing purposes you need to create some to then use for restore,
you still need to use 'bmgr fullbackup ...' to push them.
NOTE: at present the unified transport restore uses a refactored
"engine" implementation to handle stream data that encapsulates
the existing "adb restore" implementation. However, the adb
restore code path has not yet been refactored to wrap the newly-
extracted engine version; it still contains its own copy of all
the relevant logic. This will change in a future CL, at which
point offline/USB archive restore will simply wrap the same
shared stream-restore engine implementation.
Bug 15330073
Bug 15989617
Change-Id: Ieedb18fd7836ad31ba24656ec9feaaf69e164af8
om/android/server/backup/BackupManagerService.java
om/android/server/backup/PackageManagerBackupAgent.java
|
| 6a49dd087f29cfca82d55dfabeb97439ef84b508 |
17-Jun-2014 |
Christopher Tate <ctate@google.com> |
Tweak restore API
We need the transport to tell the system not only what package it's going
to deliver data for next, but also what format that data is in.
Change-Id: I989cf78febf923a4208acb33ed80ccc7869356f5
om/android/server/backup/BackupManagerService.java
|
| 9ff53a7100b1a40f5d2df3eb19a2f3f2fff39a46 |
04-Jun-2014 |
Christopher Tate <ctate@google.com> |
Implement full data backup through transport
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
om/android/server/backup/BackupManagerService.java
|
| 4dd2635bf501ad1a1adc22a6ceb4c66cd61a1a23 |
03-Jun-2014 |
Christopher Tate <ctate@google.com> |
Add full-backup stream API to BackupTransport
Also started migrating the definition of transport success/failure constants
into BackupTransport to make them permanent.
The new methods are not yet plumbed in; this is just to allow forward
progress against a proposed stable API.
Bug 15329632
Change-Id: I27472e09b831350c140b9fa548ebda3af334eb1a
om/android/server/backup/BackupManagerService.java
|
| f97c63350abcc6715ba9fdc21fd3405d0f7ba716 |
29-Apr-2014 |
Elliott Hughes <enh@google.com> |
Move internal libcore.os users over to android.system.
Change-Id: I84e1ace19ba3b4e58d7bb24f3ecda1bdf5dc75a5
om/android/server/backup/BackupManagerService.java
|
| d4659698fe2c8d854089138000ec24193d8359b8 |
09-Apr-2014 |
Christopher Tate <ctate@google.com> |
Don't crash on null installer package bookkeeping.
Bug 13906859
Change-Id: I926ccc5620abae8b97bd2b7de21b82b7729e78dd
om/android/server/backup/PackageManagerBackupAgent.java
|
| a99d02170bc0e54f729b2b735571c8eea8d5034d |
05-Apr-2014 |
Christopher Tate <ctate@google.com> |
Back up the preferred home app, if any
If the user has stated a preference about their home app, make sure we
capture that so that a system restore can return them to that preferred
situation. It's built into the system metadata so that we can, if
necessary, fast-path configuration of that home app while the rest of
the restore operation is in flight.
Change-Id: I64dfee8f7a2a9e40f556cd19298d7b367c6aa8dc
om/android/server/backup/BackupManagerService.java
om/android/server/backup/PackageManagerBackupAgent.java
|
| cba5941c6085dab1566bc047c1ea31f58a2dd4cf |
01-Apr-2014 |
Christopher Tate <ctate@google.com> |
Rejigger the invalid-key checks at backup time
Bug 13732002
Change-Id: Ic8f71234d1bbc7420eaa8e1762b999d09f308d46
om/android/server/backup/BackupManagerService.java
|
| adfe8b86e9178a553b6db9722340fa4ff5201cf1 |
05-Feb-2014 |
Christopher Tate <ctate@google.com> |
App widget backup/restore infrastructure
Backup/restore now supports app widgets.
An application involved with app widgets, either hosting or publishing,
now has associated data in its backup dataset related to the state of
widget instantiation on the ancestral device. That data is processed
by the OS during restore so that the matching widget instances can be
"automatically" regenerated.
To take advantage of this facility, widget-using apps need to do two
things: first, implement a backup agent and store whatever widget
state they need to properly deal with them post-restore (e.g. the
widget instance size & location, for a host); and second, implement
handlers for new AppWidgetManager broadcasts that describe how to
translate ancestral-dataset widget id numbers to the post-restore
world. Note that a host or provider doesn't technically need to
store *any* data on its own via its agent; it just needs to opt in
to the backup/restore process by publishing an agent. The OS will
then store a small amount of data on behalf of each widget-savvy
app within the backup dataset, and act on that data at restore time.
The broadcasts are AppWidgetManager.ACTION_APPWIDGET_RESTORED and
ACTION_APPWIDGET_HOST_RESTORED, and have three associated extras:
EXTRA_APPWIDGET_OLD_IDS
EXTRA_APPWIDGET_IDS
EXTRA_HOST_ID [for the host-side broadcast]
The first two are same-sized arrays of integer widget IDs. The
_OLD_IDS values are the widget IDs as known to the ancestral device.
The _IDS array holds the corresponding widget IDs in the new post-
restore environment. The app should simply update the stored
widget IDs in its bookkeeping to the new values, and things are
off and running. The HOST_ID extra, as one might expect, is the
app-defined host ID value of the particular host instance which
has just been restored.
The broadcasts are sent following the conclusion of the overall
restore pass. This is because the restore might have occurred in a
tightly restricted lifecycle environment without content providers
or the package's custom Application class. The _RESTORED broadcast,
however, is always delivered into a normal application environment,
so that the app can use its content provider etc as expected.
*All* widget instances that were processed over the course of the
system restore are indicated in the _RESTORED broadcast, even if
the backing provider or host is not yet installed. The widget
participant is responsible for understanding that these are
promises that might be fulfilled later rather than necessarily
reflecting the immediate presentable widget state. (Remember
that following a cloud restore, apps may be installed piecemeal
over a lengthy period of time.) Telling the hosts up front
about all intended widget instances allows them to show placeholder
UI or similarly useful information rather than surprising the user
with piecemeal unexpected appearances.
The AppWidgetProvider helper class has been updated to add a new
callback, onRestored(...), invoked when the _RESTORED broadcast
is received. The call to onRestored() is immediately followed by
an invocation of onUpdate() for the affected widgets because
they will need to have their RemoteViews regenerated under the
new ID values.
Bug 10622506
Bug 10707117
Change-Id: Ie0007cdf809600b880d91989c00c3c3b8a4f988b
om/android/server/backup/BackupManagerService.java
|
| cb20740ee171de3e604c07cdd02963d4d08a5fc9 |
06-Mar-2014 |
Christopher Tate <ctate@google.com> |
Fix build. Silly gits.
Change-Id: I8f21b7239621da500d9a73eb17d350e06dda9b20
om/android/server/backup/BackupManagerService.java
|
| ff8b037c10a7ce90cbb6130b49c8cb076e1e7c0f |
05-Mar-2014 |
Christopher Tate <ctate@google.com> |
am 777b8a80: am 422b2656: resolved conflicts for merge of c45ff35f to klp-modular-dev
* commit '777b8a808ee76401429f7210ebb7194632040d45':
Adapt to underlying changes in the PBKDF2 implementation
Change-Id: Ia68694a03e52693fceaedc6740dbd8e690e21257
om/android/server/backup/BackupManagerService.java
|
| 5c38516e83f772fe04176f72f2ab7a1094e17430 |
03-Mar-2014 |
Christopher Tate <ctate@google.com> |
Don't hang installs if the transport disappears
Bug 12991308
Change-Id: Ie5d3d27fe565dd4014976f5333e37b5707acb707
om/android/server/backup/BackupManagerService.java
|
| 091e8d2aefe39cec85f64d74898354fff596735c |
11-Feb-2014 |
Narayan Kamath <narayan@google.com> |
Fix build.
com.android.server.SystemServer was no longer imported
on master.
Change-Id: Ie712aa28940953952aa7a99cbb22f74129649249
om/android/server/backup/BackupManagerService.java
|
| cab8617b8ccea3a99b1ee15e15915c512a10c738 |
11-Feb-2014 |
Jeff Brown <jeffbrown@google.com> |
am 25df673b: am 1b51c9cb: Merge "Make SystemService constructor take a Context." into klp-modular-dev
* commit '25df673b849de374cf1de40250dfd8a48b7ac28b':
Make SystemService constructor take a Context.
|
| b880d880c6cd989eacc28c365fc9a41d31900da1 |
11-Feb-2014 |
Jeff Brown <jeffbrown@google.com> |
Make SystemService constructor take a Context.
This change simplifies the process of initializing a SystemService
by folding the onCreate() step back into the constructor. It removes
some ambuiguity about what work should happen in the constructor and
should make it possible for services to retain most of their final
fields after refactoring into the new pattern.
Change-Id: I25f41af0321bc01898658ab44b369f9c5d16800b
om/android/server/backup/BackupManagerService.java
om/android/server/backup/BackupManagerSystemService.java
|
| 9f97de13359662c2709eed227b3fab2ce7d5dabc |
06-Feb-2014 |
Adam Lesinski <adamlesinski@google.com> |
am a5a93f55: am 7f416631: Merge "Check feature bits before loading optional services" into klp-modular-dev
* commit 'a5a93f559d337ad5b79716b05ea43707eb779dc8':
Check feature bits before loading optional services
|
| 898c13df7b9b12ff10062f3542593e12fbe0c119 |
29-Jan-2014 |
Adam Lesinski <adamlesinski@google.com> |
Check feature bits before loading optional services
At startup, we check with PackageManager whether a system service is
available before attempting to load it. A system service is available
if its associated feature (similar to hardware features) is present.
This does not remove unavailable services from the compiled jar.
Change-Id: I13571805083aa4e65519a74acb52efd17b9fb3d7
ervice.mk
|
| 684d6f9f4d1a11069d9c9c1996fbc45cda7e7f04 |
13-Jan-2014 |
Christopher Tate <ctate@google.com> |
Adapt to underlying changes in the PBKDF2 implementation
We need to specify "PBKDF2WithHmacSHA1And8bit" now in order to get precisely
the same output as was previously generated with "PBKDF2WithHmacSHA1". We
also now try both when it's ambiguous which was used to generate the archive
checksums.
Bug 12494407
Change-Id: I5443f31a5e13c24f44445768b6e9a6eea221ede6
om/android/server/backup/BackupManagerService.java
|
| e58a49e411327e26b6ad9939833f53c7fa5aef20 |
21-Dec-2013 |
Amith Yamasani <yamasani@google.com> |
Merge commit '817ec49e' into manualmerge
Conflicts:
services/print/java/com/android/server/print/PrintManagerService.java
Change-Id: I1b9bf364ca50ee3c48f53d87ae0ce23e7f3c2bc2
|
| 817ec49e7991d4cac50b2308cd7cf5f8641e1e29 |
20-Dec-2013 |
Amith Yamasani <yamasani@google.com> |
Wrap some services into a SystemService
These services can now be excluded by modifying the list of REQUIRED_SERVICES (TB renamed)
Changed appwidget, devicepolicy, backup and print services.
Change-Id: Id8e2855d5c045cd57bdb02dca9ed75172803bce7
om/android/server/backup/BackupManagerService.java
om/android/server/backup/BackupManagerSystemService.java
|
| 49782e46c0eb85a25ae2abcf80880c48dbab5aea |
20-Dec-2013 |
Amith Yamasani <yamasani@google.com> |
am 9158825f: Move some system services to separate directories
* commit '9158825f9c41869689d6b1786d7c7aa8bdd524ce':
Move some system services to separate directories
|
| 9158825f9c41869689d6b1786d7c7aa8bdd524ce |
22-Nov-2013 |
Amith Yamasani <yamasani@google.com> |
Move some system services to separate directories
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
om/android/server/backup/BackupManagerService.java
om/android/server/backup/PackageManagerBackupAgent.java
om/android/server/backup/SystemBackupAgent.java
ervice.mk
|