| 43a4a8c777fbb8f71540ac7fbe82674489ef557b |
09-Jan-2015 |
Christopher Tate <ctate@google.com> |
Fix redundant file backups
We'd observed a bug in which an unchanged file was nevertheless
being redundantly transmitted for backup on every backup pass.
The underlying issue turns out to have been the FileBackupHelper
base implementation's logic for diffing the prior-state file
set against the current state, in the case when there had been
deletions of prior files. In addition, there was also a
parallel bug in which file checksums were not calculated
properly in some cases, leading to at least one additional
redundant backup of the file in question.
Bug 18694053
Change-Id: Ie0dec06486b5fef4624561737019569c85d6b2a0
ackupHelperDispatcher.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
ackupTransport.java
|
| 31f25696d950dd54e8b339074b98ad6335738f2f |
03-Dec-2014 |
Christopher Tate <ctate@google.com> |
Adjust wallpaper-restore acceptance criteria
Previously the dimension check had implicit orientation sensitivity.
We now make sure to compare the candidate image's width to the smallest
screen dimension for acceptance purposes; this fixes cases when we would
e.g. get a restored image of (1680x2560) but believe that we needed it
to have a max width of 2048, even though it had originated on that same
device -- due to current-orientation issues.
Bug 18448052
Change-Id: I64ca6a4ed91ce1ccc04f5a9a6851e5cfe511b7c7
allpaperBackupHelper.java
|
| 07334334aab3863408325653ceccee47f9e1788d |
21-Nov-2014 |
Zoltan Szatmary-Ban <szatmz@google.com> |
Merge "Adding method to query backup manager service activity status" into lmp-mr1-dev
|
| ac6a3a5e9d90edb533e5b377a4a14ef514be955a |
18-Nov-2014 |
Christopher Tate <ctate@google.com> |
Recents backup helper
Handles backup/restore of recent tasks for the system. Currently the
thumbnails are not saved.
At restore time the historical task records are placed in a designated
separate location rather than directly in the live bookkeeping; this
avoids ID duplication issues and makes it easier to deal with lazy
adoption of the historical task state as apps are installed on the
device post-restore.
Bug 17303286
Bug 15986349
Change-Id: Ie156c1e2ab9c9a7e7ac0447b27016fdcef55dded
ecentsBackupHelper.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
BackupManager.aidl
|
| 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
BackupManager.aidl
|
| 1133e29f22252cc36102f41204c3de35779e49d2 |
10-Oct-2014 |
Christopher Tate <ctate@google.com> |
Tweak wallpaper restore rejection threshold
Raise the height ratio threshold slightly in order to start accepting
restores of height=1920 images onto height=2560 devices.
Bug 17882661
Change-Id: I63b47817fdf754cda9a052bddb62aee764522c6f
allpaperBackupHelper.java
|
| 431906b34f33e23b5407fc2f72f8c085ef572816 |
08-Oct-2014 |
Christopher Tate <ctate@google.com> |
Turn on dimension validation in wallpaper restore
Bug 17906491
Change-Id: I4c76c3197df95b51a6e44d1fe2d522b6c05284e5
allpaperBackupHelper.java
|
| 406abd45471c523aea151f5aca84b008fee02bbe |
07-Oct-2014 |
Christopher Tate <ctate@google.com> |
Accept any restored wallpaper
...and let the wallpaper service & hosts figure out what to do
with it.
Bug 17677006
Change-Id: Ie5bfa549af4da178e621ffc42a759a552897d93a
allpaperBackupHelper.java
|
| 004c16654f2f86ff3055f3c88b5498eb3254f2e1 |
02-Oct-2014 |
Christopher Tate <ctate@google.com> |
Tweak wallpaper restore acceptance heuristics
We now accept for restore any image that is at least wide enough to
fit the screen, and has a height within a comfortable margin of the
previously stated target.
Bug 17677006
Change-Id: I5937a82ddfbfa0bbb30d568621eb48e4b3533fac
allpaperBackupHelper.java
|
| 9e079298edd022c43a960729442a53557fd16e45 |
10-Sep-2014 |
Christopher Tate <ctate@google.com> |
Fix BackupManager.isBackupEnabled()
It wasn't properly lazy-initializing the service binder, so it always
thought the backend service didn't exist, and so always returned false.
Also directly validated that every usage of sService in the module is
now correctly lazy-initialized.
Bug 16661321
Change-Id: If5fbb18aef81bfa8fd70eb40a1f6af54cc96d804
ackupManager.java
|
| cd31d5d9aee277da23365e7e0a96ad359eb68a5f |
28-Aug-2014 |
Christopher Tate <ctate@google.com> |
Correct misleading javadoc for BackupHelper
Change-Id: I3865cb3bd55f04baadedb55e9f84fc516eae75b4
ackupHelper.java
|
| 8ab0865156d447fbebcc366164ca7c57108ea57c |
27-Aug-2014 |
Christopher Tate <ctate@google.com> |
Briefly log wallpaper restore outcomes
Bug 17112780
Change-Id: I3e9a23d28c9df4f708eb24b4688322c21a8c8382
allpaperBackupHelper.java
|
| ff31addb9b767496ba5c907513be172779eadfc5 |
18-Aug-2014 |
arete <arete@google.com> |
Expose system apis for backup transport migration
Bug: 16542048
Change-Id: I45e710028316e7b2dc4195700a1e7344afb54691
ackupDataInput.java
ackupDataOutput.java
ackupTransport.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
ackupManager.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
ackupTransport.java
|
| 58d467a58484e51837f8bc8895b02deaa09c7418 |
08-Aug-2014 |
Christopher Tate <ctate@google.com> |
A little more system API in RestoreSetObserver
Bug 16542048
Change-Id: I8b773df872e3cc50c42645e3833d40a691edc4e7
estoreObserver.java
|
| e079264b981d87c648921185528b553a86ae353d |
07-Aug-2014 |
Christopher Tate <ctate@google.com> |
API to tell the transport to cancel a full backup in progress
Bug 16524520
Change-Id: If2cbffd3c8a03bf4eb7b11ff1ae784c437e27e7f
ackupTransport.java
|
| 2e5979236ccc06beec8b8f7f631f31bdedc79614 |
07-Aug-2014 |
Christopher Tate <ctate@google.com> |
Mark beginRestoreSession() as system API
Bug 16874911
Change-Id: Idb06ebf2d0f54bb13af1d2eeacf0d7b06fda68db
ackupManager.java
|
| d5cf722ae62d06d1fb6a9505c6f4c403a5d14a37 |
30-Jul-2014 |
Christopher Tate <ctate@google.com> |
Reify the transport lookup/selection API
Introduce a stable BackupTransport interface class for transport
implementations to derive from.
Make the interface for viewing/selecting the active backup transport
part of the stable API.
Make restore-related classes (RestoreSession, RestoreSet) stable API.
Express backup manager APIs needed for transport operation as
@SystemApi methods in BackupManager.
Bug 16661321
Change-Id: I423b87ae8f45c1b77831d4f8ffd97715484c2d2b
ackupManager.java
ackupTransport.java
estoreDescription.java
estoreSession.java
estoreSet.java
|
| c17739d112d8e7076924c7fdd98614abafd58609 |
29-Jul-2014 |
Christopher Tate <ctate@google.com> |
Provide outside-facing API for data management intent+label
Bug 16346320
Change-Id: I3f4c2f4b700c77880ba3d8db7c92cdb404763d0d
BackupManager.aidl
|
| 9679410db578e179c7559e7a52bb21c8082e9631 |
28-Jul-2014 |
Christopher Tate <ctate@google.com> |
Add data-management intent + label to BackupTransport API
Bug 16346320
Change-Id: Id9e855a1d3cebbf801c27a21e1edc3ffcccfd2e9
ackupTransport.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
ackupAgent.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
ackupTransport.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
ackupAgent.java
ullBackup.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
ackupTransport.java
estoreDescription.java
|
| 5a009f9008d1f18b156c142b69e173109f5e218b |
19-Jun-2014 |
Christopher Tate <ctate@google.com> |
Adjust full restore API
Introduces a new constant, BackupTransport.NO_MORE_DATA, defined to
be -1. The transport returns this constant when asked for the next
chunk of streaming full restore data to indicate that it has reached
EOF on the current restore target's archive stream.
If the transport returns TRANSPORT_PACKAGE_REJECTED from that same
method, then the OS will abort the current target's restore operation
and move on to the next package in the overall restore dataset (by
calling nextRestorePackage() on the transport).
If the transport returns zero when asked for the next chunk of
restore stream data, this will be interpreted as meaning that no data
is currently deliverable but the restore download is still running
properly; the caller will then retry until either data is delivered
or the transport reports NO_MORE_DATA (or an error).
Also sketched in the implementation of this latest API in the
test LocalTransport.
Bug 15330073
Change-Id: I81621cb322f831460133b7dced5bb88d2a4124e1
ackupTransport.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
ackupTransport.java
estoreDescription.aidl
estoreDescription.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
ackupTransport.java
BackupManager.aidl
|
| c777185688d1de4f1c989b3f7630e7715fd71be3 |
03-Jun-2014 |
Christopher Tate <ctate@google.com> |
Finish migration of backup transport constants
...and make sure to fix a couple of lingering Javadoc references.
Bug 15329632
Change-Id: I1de7b53a58940834cd2dae2301fd5f65dbb48ba6
ackupTransport.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
ackupTransport.java
|
| 74318c98a0f67e042815798f85c75eb7f14390e1 |
16-May-2014 |
Christopher Tate <ctate@google.com> |
Provide stable concrete wrapper for backup transport API
This initial version is a simple pass-through of the existing
IBackupTransport AIDL definition.
Change-Id: I0f6c9ffc7101f82127ab61ba6cba9f5003af6a0c
ackupTransport.java
|
| 10596fbcce710a76ffc7e917400df13af5c2ebcb |
28-Apr-2014 |
Elliott Hughes <enh@google.com> |
resolved conflicts for merge of 3ce4f3d0 to master
Change-Id: Id5c5997ad8f801b32e1dbd97413ea42e38c27210
|
| 3ce4f3d0af8b20f915631ab927aafa76a6105135 |
28-Apr-2014 |
Elliott Hughes <enh@google.com> |
am 685a0a72: am bbd87eb9: Merge "Track libcore.os\' move to android.system."
* commit '685a0a72d445515167a2071330679cdf9b53a62d':
Track libcore.os' move to android.system.
|
| 34385d352da19805ae948215e2edbeedd16b7941 |
28-Apr-2014 |
Elliott Hughes <enh@google.com> |
Track libcore.os' move to android.system.
(This is partial, but should cover everything in AOSP master except
for the zygote.)
Change-Id: I1042c99245765746a744c44e714095cb2c6cb75d
ackupAgent.java
ullBackup.java
|
| cba5941c6085dab1566bc047c1ea31f58a2dd4cf |
01-Apr-2014 |
Christopher Tate <ctate@google.com> |
Rejigger the invalid-key checks at backup time
Bug 13732002
Change-Id: Ic8f71234d1bbc7420eaa8e1762b999d09f308d46
ackupAgent.java
ackupDataOutput.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
ackupDataOutput.java
BackupManager.aidl
|
| 0203d58ecf145a0b30dc33828c0f45d83fce983b |
08-Jan-2014 |
Narayan Kamath <narayan@google.com> |
am db47efd3: am 651807fc: am 3f589e5d: am 2842bd02: am de8c3cf1: Merge "AArch64: Use long for pointers in App/Backup"
* commit 'db47efd3f8581c2c0d72a1b8617aeae9830f7ea4':
AArch64: Use long for pointers in App/Backup
|
| 3f589e5d1e09e17a2aaa0a52fc15e16520d1bd5a |
08-Jan-2014 |
Narayan Kamath <narayan@google.com> |
am 2842bd02: am de8c3cf1: Merge "AArch64: Use long for pointers in App/Backup"
* commit '2842bd021c11274720d6a10219538b536b7d2050':
AArch64: Use long for pointers in App/Backup
|
| 58b8b24256bdc2b613b7fda9151845ed9898a4c7 |
02-Jan-2014 |
Ashok Bhat <ashok.bhat@arm.com> |
AArch64: Use long for pointers in App/Backup
For storing pointers, long is used, as
native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: I7aee49dc26cf6c86af8f1d882e9cd1cc145a1977
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
ackupDataInput.java
ackupDataOutput.java
ileBackupHelperBase.java
|
| 6090995951c6e2e4dcf38102f01793f8a94166e1 |
19-Nov-2013 |
John Spurlock <jspurlock@google.com> |
Remove unused imports from frameworks/base.
Change-Id: Ia1f99bd2c1105b0b0f70aa614f1f4a67b2840906
ullBackup.java
haredPreferencesBackupHelper.java
|
| b0183f0ae311966cff0e10e8139c56f97288d1f2 |
18-Nov-2013 |
Christopher Tate <ctate@google.com> |
Harden against transiently unavailable backup transports
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
BackupManager.aidl
|
| d5965cb506bde84612109bf26c3fcc6712ca91e5 |
19-Nov-2013 |
Sascha Prueter <saschap@google.com> |
Trying to unbreak build...
Revert "Harden against transiently unavailable backup transports"
This reverts commit 8f98252afea3fd0e68693635ec21b6004a52fa69.
Change-Id: I3aabb80f1a5932d530bce6b82d4b30c6cd1cdd5a
BackupManager.aidl
|
| 8f98252afea3fd0e68693635ec21b6004a52fa69 |
18-Nov-2013 |
Christopher Tate <ctate@google.com> |
Harden against transiently unavailable backup transports
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
BackupManager.aidl
|
| f85f5b2125461ea664cf67a16d4608a5a9bf2f98 |
19-Apr-2013 |
Christopher Tate <ctate@google.com> |
Provide SharedPreferences coherence guarantees for BackupAgent
SharedPreferences uses deferred writes internally, and the public
API doesn't allow apps to explicitly synchronize with this, so the
backup/restore implementation needs to take a little care to make
sure that the app process isn't killed before the deferred writes
land on disk. This parallels the coherence guarantees around
SharedPreference that the Activity and Service lifecycles provide.
Bug 8659368
Change-Id: I853e54f9fb0d2d260dbe6e40d640959f998092df
ackupAgent.java
|
| 7323765bbf13d9638cf2cc1e06113bffcdac46c4 |
25-Mar-2013 |
Christopher Tate <ctate@google.com> |
Validate restored file paths against their nominal domain
Bug 8460775
Change-Id: Ib16d740a001adf4f9cb9ccaa31066ac7cadfb430
ackupAgent.java
|
| 294b512ecaa98a6a8ef12285ad14e7a4091b5d57 |
19-Feb-2013 |
Christopher Tate <ctate@google.com> |
DO NOT MERGE - Full backup/restore now handles OBBs sensibly
OBB backup/ restore is no longer handled within the target app
process. This is done to avoid having to require that OBB-using
apps have full read/write permission for external storage.
The new OBB backup service is a new component running in the
same app as the already-existing shared storage backup agent.
The backup infrastructure delegates backup/restore of apps'
OBB contents to this component (because the system process
may not itself read/write external storage).
From the command line, OBB backup is enabled by using new
-obb / -noobb flags with adb backup. The default is noobb.
Finally, a couple of nit fixes:
- buffer-size mismatch between the writer and reader of chunked
file data has been corrected; now the reading side won't be
issuing an extra pipe read per chunk.
- bu now explicitly closes the transport socket fd after
adopting it. This was benign but triggered a logged
warning about leaked fds.
(Cherrypicked)
Change-Id: I471f6348abcccb7bf1e1710b7beda9f23de53e14
ackupAgent.java
ullBackup.java
BackupManager.aidl
|
| 5cb5c337d5fe523723b8e5ceb4bdf38dff0cec70 |
21-Feb-2013 |
Christopher Tate <ctate@google.com> |
Be cool in backup/restore of apps that can't touch external storage
Bug: 8241337
Change-Id: I23f6eeba8448b234a7b18ce50d2ced2ba54b4ebd
ackupAgent.java
|
| 416c39e8d48048fa4a997c09460c262cca871fc4 |
15-Feb-2013 |
Christopher Tate <ctate@google.com> |
Full backup now saves getExternalFilesDir() content with the app data
... instead of only saving it with the enormous "shared storage" generic
data blob. In parallel, we no longer store managed app-specific files
on external storage as part of the generic shared-storage blob.
At restore time we just go ahead and apply such files, though,
because they're a priori going to be part of an archive generated by
an older version of the platform, so that's how the data is expected
to be handled in those circumstances.
Bug 6718844
Change-Id: I4410514d368b11d74b3afe6b92d363d4115a3415
ackupAgent.java
ullBackup.java
|
| f6d6fa8cbc0251da1900e858bb0379cda5014b6f |
27-Sep-2012 |
Christopher Tate <ctate@google.com> |
Full (local) restore security changes
(1) Prevent full restore from creating files/directories that are
accessible by other applications
(2) Don't restore filesets from "system" packages; i.e. any that runs
as a special uid, unless they define their own agent for handling
the restore process.
Bug 7168284
Change-Id: Id6a0cb4c113c2e4a8c4605252cffa41bea22d8a3
ullBackup.java
|
| 61f57379ca2c5b6290c8da7548fa17128f7ab24f |
31-Aug-2012 |
Amith Yamasani <yamasani@google.com> |
Centralize the creation of the user system directory
Environment.getUserSystemDirectory(int userId)
Use it all relevant places that was hardcoding it.
Also, wipe out the user's system directory when user is removed, otherwise old state
might be transferred to a new user.
Change-Id: I788ce9c4cf9624229e65efa7047bc0c019ccef0a
allpaperBackupHelper.java
|
| 9be0105fbc56eb1b1813bb7c5fe258a144867a43 |
22-Jun-2012 |
Scott Main <smain@google.com> |
docs: fix several links
Change-Id: I89d9fd64dc22c90680bb05415cc966c255165af9
ackage.html
|
| f5491fc1b61088843f280a6b55c1a995e2e6f939 |
25-May-2012 |
Christopher Tate <ctate@google.com> |
Prevent construction/use of invalid restore session proxies
Possible (rare) null return was not being handled. Fixes
bug 6554812.
Change-Id: I470e916f2156ff7ed2947d6ce21ef2816fc7f97d
ackupManager.java
|
| 37ce3a8af6faab675319d0803b288ab1dddc76be |
06-Feb-2012 |
Amith Yamasani <yamasani@google.com> |
Multi-user - wallpaper service
- Allow each user to have their own wallpaper (live or static).
- Migrate old wallpaper on upgrade.
- Update SystemBackupAgent to backup/restore from primary user's
new wallpaper directory.
Reduce dependency on Binder.getOrigCallingUser() by passing the
userId for bindService.
Change-Id: I19c8c3296d3d2efa7f28f951d4b84407489e2166
allpaperBackupHelper.java
|
| 61fd1e8d8c3ccf2d6b7d4af1c19e8f0988d5a1ec |
26-Oct-2011 |
Joe Fernandez <joefernandez@google.com> |
docs: add developer guide cross references, Project ACRE, round 3
Change-Id: I6125315ecdf0f78dd947c514a9944729d723e95d
ackupAgent.java
ackupAgentHelper.java
ackupManager.java
|
| bf6ee4f509cbe7a44f4cc72f28e6150ca47c066d |
07-Oct-2011 |
Christopher Tate <ctate@google.com> |
Fix wallpaper restore
Following a restore of the wallpaper data files, the settingsRestored()
method was binding the new wallpaper by passing null as the component,
because once upon a time that meant just use the configuration that had
just been loaded from the [newly restored] settings filed. However, at
some point this broke when the load from settings was made a staging
operation, not also the commitment of the changes.
This CL passes the newly-determined component configuration explicitly
to the bind, overriding the product default that may already have been
emplaced by the time the restore happens.
It also turns off the (minor) debugging that had been enabled in
WallpaperBackupHelper while digging into the issue.
Bug 5416839
Change-Id: I963893c236e24c75d10dde75836805295ea42cbb
allpaperBackupHelper.java
|
| 240c7d2d1fb2944ee6a6f1dee41c7bbd766f8f0d |
04-Oct-2011 |
Christopher Tate <ctate@google.com> |
Add -nosystem flag to adb backup
This makes it easy to back up everything that belongs to 3rd party apps, but
nothing that comes with the system per se. If any system packages are
explicitly named on the command line they will be included in the backup
even if -nosystem was passed. So, for example, this will back up all 3rd
party apps as well as system settings, but nothing else belonging to
system-deployed apps:
adb backup -all -nosystem com.android.provider.settings
Bug 5361503
Change-Id: Iebe04b7d7027ca58b9f55e8eb7f219d6cca69269
BackupManager.aidl
|
| 78be158ce4b95fa537c6cb60a55dbc9161e53ef1 |
29-Aug-2011 |
Christopher Tate <ctate@google.com> |
Un-hide the new BackupAgent.onFullBackup() API
This is intended to be new public API for ICS, and unbundled app
development needs access to it.
Change-Id: I091b31ae9ec319850a93efc3d5860b87b68d355e
ackupAgent.java
|
| 728a1c4d5ed3b808172013a7f5bb5065d1e964f6 |
29-Jul-2011 |
Christopher Tate <ctate@google.com> |
Require the current backup pw in all backup/restore operations
Specifically, we now also require the current password to confirm any
restore operation.
Bug 4901637
Change-Id: I39ecce7837f70cd05778cb7e0e6390ad8f6fe3f3
BackupManager.aidl
|
| 2efd2dbbac9eac89620683696c6076463c3a1cd6 |
20-Jul-2011 |
Christopher Tate <ctate@google.com> |
Support full-backup encryption and global backup password
If the user has supplied a backup password in Settings, that password
is validated during the full backup process and is used as an encryption
key for encoding the backed-up data itself. This is the fundamental
mechanism whereby users can secure their data even against malicious
parties getting physical unlocked access to their device.
Technically the user-supplied password is not used as the encryption
key for the backed-up data itself. What is actually done is that a
random key is generated to use as the raw encryption key. THAT key,
in turn, is encrypted with the user-supplied password (after random
salting and key expansion with PBKDF2). The encrypted master key
and a checksum are stored in the backup header. At restore time,
the user supplies their password, which allows the system to decrypt
the master key, which in turn allows the decryption of the backup
data itself.
The checksum is part of the archive in order to permit validation
of the user-supplied password. The checksum is the result of running
the user-supplied password through PBKDF2 with a randomly selected
salt. At restore time, the proposed password is run through PBKDF2
with the salt described by the archive header. If the result does
not match the archive's stated checksum, then the user has supplied
the wrong decryption password.
Also, suppress backup consideration for a few packages whose
data is either nonexistent or inapplicable across devices or
factory reset operations.
Bug 4901637
Change-Id: Id0cc9d0fdfc046602b129f273d48e23b7a14df36
ackupAgent.java
BackupManager.aidl
|
| 7926a693c4a4f4d2a2d352343bca23e189c7420d |
11-Jul-2011 |
Christopher Tate <ctate@google.com> |
Compress the backup output stream
Zlib compression, with a full flush between each application's
data. Encryption will be performed on the already-compressed data
once that's implemented.
On restore, the streamed data is similarly uncompressed on the fly.
Change-Id: I19b65c88e759a66527d10913d18fffa9df0bc011
ackupAgent.java
|
| 284f1bb4daf77f7e6b688c0936dd4a31ec2e7c74 |
07-Jul-2011 |
Christopher Tate <ctate@google.com> |
Can now restore a subset of apps from historical dataset
Adds the ability to filter a restore of an historical dataset so that it
only restores certain apps' data regardless of what is actually present
in the dataset. This is currently only used by the bmgr command-line tool,
for debugging / developer support.
Bug 2021590
Change-Id: I7685e5d609b0f5506f71d70c26410602bb387659
RestoreSession.aidl
estoreSession.java
|
| b848b7a99c81081723077d7fb2006b2a35760259 |
07-Jul-2011 |
Christopher Tate <ctate@google.com> |
Remove unused object
Change-Id: I98c55432c26ccc4e8421db46c9f825cb42772508
ackupAgent.java
|
| 79ec80db70d788f35aa13346e4684ecbd401bd84 |
24-Jun-2011 |
Christopher Tate <ctate@google.com> |
Make full backup API available to apps
New methods for full backup/restore have been added to BackupAgent
(still hidden): onFullBackup() and onRestoreFile(). The former is the
entry point for a full app backup to adb/socket/etc: the app then writes
all of its files, entire, to the output. During restore, the latter
new callback is invoked, once for each file being restored.
The full backup/restore interface does not use the previously-defined
BackupDataInput / BackupDataOutput classes, because those classes
provide an API designed for incremental key/value data structuring.
Instead, a new FullBackupDataOutput class has been introduced, through
which we restrict apps' abilities to write data during a full backup
operation to *only* writing entire on-disk files via a new BackupAgent
method called fullBackupFile().
"FullBackupAgent" exists now solely as a concrete shell class that
can be instantiated in the case of apps that do not have their own
BackupAgent implementations.
Along with the API change, responsibility for backing up the .apk
file and OBB container has been moved into the framework rather than
have the application side of the transaction do it.
Change-Id: I12849b06b1a6e4c44d080587c1e9828a52b70dae
ackupAgent.java
ullBackup.java
ullBackupAgent.java
ullBackupDataOutput.java
|
| b0628bfd5aac480a0d412ac96b8af1d97ac01c30 |
03-Jun-2011 |
Christopher Tate <ctate@google.com> |
Implement shared-storage full backup/restore
Every available shared-storage volume is backed up, tagged with its
ordinal in the set of mounted shared volumes. This is an approximation
of "internal + the external card". This lets us restore things to the
same volume [or "equivalent" volume, in the case of a cross-model
restore] as they originated on.
Also fixed a bug in the handling of files/dirs with spaces in
their names.
Change-Id: I380019da8d0bb5b3699bd7c11eeff621a88e78c3
ackupAgent.java
ullBackup.java
ullBackupAgent.java
|
| 75a99709accef8cf221fd436d646727e7c8dd1f1 |
19-May-2011 |
Christopher Tate <ctate@google.com> |
Restore from a previous full backup's tarfile
Usage: adb restore [tarfilename]
Restores app data [and installs the apps if necessary from the backup
file] captured in a previous invocation of 'adb backup'. The user
must explicitly acknowledge the action on-device before it is allowed
to proceed; this prevents any "invisible" pushes of content from the
host to the device.
Known issues:
* The settings databases and wallpaper are saved/restored, but lots
of other system state is not yet captured in the full backup. This
means that for practical purposes this is usable for 3rd party
apps at present but not for full-system cloning/imaging.
Change-Id: I0c748b645845e7c9178e30bf142857861a64efd3
ackupAgent.java
ullBackup.java
ullBackupAgent.java
BackupManager.aidl
|
| 4a627c71ff53a4fca1f961f4b1dcc0461df18a06 |
01-Apr-2011 |
Christopher Tate <ctate@google.com> |
Full local backup infrastructure
This is the basic infrastructure for pulling a full(*) backup of the
device's data over an adb(**) connection to the local device. The
basic process consists of these interacting pieces:
1. The framework's BackupManagerService, which coordinates the
collection of app data and routing to the destination.
2. A new framework-provided BackupAgent implementation called
FullBackupAgent, which is instantiated in the target applications'
processes in turn, and knows how to emit a datastream that contains
all of the app's saved data files.
3. A new shell-level program called "bu" that is used to bridge from
adb to the framework's Backup Manager.
4. adb itself, which now knows how to use 'bu' to kick off a backup
operation and pull the resulting data stream to the desktop host.
5. A system-provided application that verifies with the user that
an attempted backup/restore operation is in fact expected and to
be allowed.
The full agent implementation is not used during normal operation of
the delta-based app-customized remote backup process. Instead it's
used during user-confirmed *full* backup of applications and all their
data to a local destination, e.g. via the adb connection.
The output format is 'tar'. This makes it very easy for the end
user to examine the resulting dataset, e.g. for purpose of extracting
files for debug purposes; as well as making it easy to contemplate
adding things like a direct gzip stage to the data pipeline during
backup/restore. It also makes it convenient to construct and maintain
synthetic backup datasets for testing purposes.
Within the tar format, certain artificial conventions are used.
All files are stored within top-level directories according to
their semantic origin:
apps/pkgname/a/ : Application .apk file itself
apps/pkgname/obb/: The application's associated .obb containers
apps/pkgname/f/ : The subtree rooted at the getFilesDir() location
apps/pkgname/db/ : The subtree rooted at the getDatabasePath() parent
apps/pkgname/sp/ : The subtree rooted at the getSharedPrefsFile() parent
apps/pkgname/r/ : Files stored relative to the root of the app's file tree
apps/pkgname/c/ : Reserved for the app's getCacheDir() tree; not stored.
For each package, the first entry in the tar stream is a file called
"_manifest", nominally rooted at apps/pkgname. This file contains some
metadata about the package whose data is stored in the archive.
The contents of shared storage can optionally be included in the tar
stream. It is placed in the synthetic location:
shared/...
uid/gid are ignored; app uids are assigned at install time, and the
app's data is handled from within its own execution environment, so
will automatically have the app's correct uid.
Forward-locked .apk files are never backed up. System-partition
.apk files are not backed up unless they have been overridden by a
post-factory upgrade, in which case the current .apk *is* backed up --
i.e. the .apk that matches the on-disk data. The manifest preceding
each application's portion of the tar stream provides version numbers
and signature blocks for version checking, as well as an indication
of whether the restore logic should expect to install the .apk before
extracting the data.
System packages can designate their own full backup agents. This is
to manage things like the settings provider which (a) cannot be shut
down on the fly in order to do a clean snapshot of their file trees,
and (b) manage data that is not only irrelevant but actively hostile
to non-identical devices -- CDMA telephony settings would seriously
mess up a GSM device if emplaced there blind, for example.
When a full backup or restore is initiated from adb, the system will
present a confirmation UI that the user must explicitly respond to
within a short [~ 30 seconds] timeout. This is to avoid the
possibility of malicious desktop-side software secretly grabbing a copy
of all the user's data for nefarious purposes.
(*) The backup is not strictly a full mirror. In particular, the
settings database is not cloned; it is handled the same way that
it is in cloud backup/restore. This is because some settings
are actively destructive if cloned onto a different (or
especially a different-model) device: telephony settings and
AndroidID are good examples of this.
(**) On the framework side it doesn't care that it's adb; it just
sends the tar stream to a file descriptor. This can easily be
retargeted around whatever transport we might decide to use
in the future.
KNOWN ISSUES:
* the security UI is desperately ugly; no proper designs have yet
been done for it
* restore is not yet implemented
* shared storage backup is not yet implemented
* symlinks aren't yet handled, though some infrastructure for
dealing with them has been put in place.
Change-Id: Ia8347611e23b398af36ea22c36dff0a276b1ce91
ackupAgent.java
ullBackup.java
ullBackupAgent.java
BackupManager.aidl
FullBackupRestoreObserver.aidl
|
| 44bc17c6b517aef35a390c81b5aa79c4f284f744 |
21-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Rework display size access.
Applications now get the display size from the window manager. No
behavior should be changed yet, this is just prep for some real
changes.
Change-Id: I2958a6660895c1cba2b670509600014e55ee9273
allpaperBackupHelper.java
|
| 9b95a4fcdce4b1a7a418e36de2ddc4d2c3acfc69 |
11-Mar-2011 |
Christopher Tate <ctate@google.com> |
Broaden the filter for wallpaper restore
Tweak the filter parameters so that we now use any restored wallpaper image
that is larger than our ideal size, and will reject any smaller images only
if they are *much* smaller than our ideal size. The specific threshold used
here will just barely reject Nexus One or Droid sized wallpapers for restore
onto a Xoom, but will pass anything larger.
Bug 4070129
Change-Id: I889bdb3ef5011343b2fccb2f81c6abc2f4603ee2
allpaperBackupHelper.java
|
| 7f765cf588e37a70fa2a1d251aaa8e7b847801b6 |
01-Mar-2011 |
Christopher Tate <ctate@google.com> |
Make sure to properly default the screen size during wallpaper restore
The wallpaper service claims a desired width/height of (-1,-1) during
initial setup, so look to the default display's metrics if necessary.
Change-Id: I341f12fb7b0b9d6b7761c277f23fc68fa5355256
allpaperBackupHelper.java
|
| 00724cacc8292900c3be8657ea9b3b6284cf4877 |
17-Feb-2011 |
Christopher Tate <ctate@google.com> |
Turn on wallpaper restore debug logs
For investigation of bug 3462173 et alia
Change-Id: Id5f82a97c72d2a02f9a878029782fa698c5b124f
allpaperBackupHelper.java
|
| f4f05b8f24183b9e0d6959fe8b71fb88543edd9b |
07-Jan-2011 |
Scott Main <smain@google.com> |
Update package descriptions with editorial revisions.
Notably, this removes exessive info about resources
from the content package, because it's not a good location
and the info is avilable in the dev guide, but also
added some of the info to the Resources class description.
Change-Id: Ie78af26c9cec66314deb98e53078f48e16c08e70
ackage.html
|
| 3f64f8d8fc05189777e83b4efd3882cbc661fdeb |
11-Dec-2010 |
Christopher Tate <ctate@google.com> |
Don't restore wildly wrong sized wallpapers
If the dimensions of the original are sufficiently different from the
device's preferred dimensions, just don't restore the image. This
avoids bad letterboxing / clipping on e.g. phone <-> tablet data
migration.
The expansion/shrinkage ratios used here allow restores of saved
wallpaper images among HVGA devices, among WVGA variants, and
among tablets; but skip restoring wallpapers across those
categories (where severe clipping or letterboxing would occur).
Bug 3261863
Change-Id: I75e75d6401d18f1df10d75796ee04e21d2302cfa
ileBackupHelperBase.java
allpaperBackupHelper.java
|
| f5e1c296370b45503a6c48bdb7da8b829bc0b906 |
09-Dec-2010 |
Christopher Tate <ctate@google.com> |
Add a couple of transport-descriptive methods to IBackupManager
Privileged callers can now ask the transport for a string describing
its current state, and for an Intent that can be passed to startActivity()
in order to bring up its exported configuration UI. These will be used
in Settings in order to e.g. show the user the currently active account
being used for backup, and allow the user to choose an account.
The data being funnelled through IBackupManager here are the ones
already exposed by the transports in their implementation of the
IBackupTransport interface.
Bug: 2753632
Change-Id: I2227a2b111d8d0ddf221d63020e20c1316fff55b
BackupManager.aidl
|
| 44ab8453e1c4c46790f792a46d026fa1017d8cfe |
17-Nov-2010 |
Chris Tate <ctate@google.com> |
Permission fix: don't require BACKUP perm for self-restores
The public API is not supposed to require the BACKUP permission in order
for an application to restore its own last-known-good backup data. However,
as currently implemented, BackupManager.requestRestore() [the public API
in question] depends on private Backup Manager methods that *do* enforce
that permission. The net result is that the method cannot be successfully
used by third party applications: it will throw an exception if attempted.
This CL restructures the permission checking involved.
First, the underlying beginRestoreSession() operation can now be passed a
'null' transport name; if this is done, then the restore session is begun
on whatever the currently-active transport is. Looking up the name of the
active transport is one of the permission-guarded actions that was required
with the initial implementation.
Second, a package name can now be passed to beginRestoreSession(). If
this is done, then the restore session can only be used to perform a
single-package restore of that one application. The BACKUP permission is
not required if the caller is tying the restore to its own package name.
In combination, these changes permit BackupManager.requestRestore() to
function without the calling app needing to hold any special permission.
The no-permission case is intentionally quite narrow: the caller must
hold the permission unless they both (a) pass 'null' for the transport
name, thereby accepting whatever the currently active transport is, and
(b) pass their own package name to restrict the restore session only
to their own app.
External bug http://code.google.com/p/android/issues/detail?id=10094
Internal bug 3197202
Change-Id: Ibc9d652323f2da03727d850f991b4096af6520d2
ackupManager.java
BackupManager.aidl
|
| a4270e7e1e09bf5f60c65102d34e887033c5befa |
21-Sep-2010 |
Scott Main <smain@google.com> |
am 73e150c8: provide link to backup guide above the fold
Merge commit '73e150c886afc6cd92e8b065a58d61e0b2a098ed' into gingerbread
* commit '73e150c886afc6cd92e8b065a58d61e0b2a098ed':
provide link to backup guide above the fold
|
| 73e150c886afc6cd92e8b065a58d61e0b2a098ed |
20-Sep-2010 |
Scott Main <smain@google.com> |
provide link to backup guide above the fold
Change-Id: I84ad3fbd4c3c7793fbf330d6a2be5cab611a9b26
ackage.html
|
| 6f9d58ac62366b13a1eac00d58ebc84f03cea3f2 |
07-Sep-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
Make SharedPreferencesBackupHelper wait for async SharedPreference writes
Fixes a potential race with backups.
Change-Id: I73492c0384091cedd7802109257312387fcd43f9
haredPreferencesBackupHelper.java
|
| b83a283ac178ab0a72f1d811189d79b26097835e |
29-Apr-2010 |
Scott Main <smain@google.com> |
docs: add dev guide for backup
Change-Id: I168f6b15d3441c9cbea2cd9699612476c7244530
ackupAgent.java
ackage.html
|
| d17da43c82c4edb97514d6138bc208eeba321636 |
30-Apr-2010 |
Scott Main <smain@google.com> |
docs: revise and add documentation for backup APIs
Change-Id: I0b015a6de16da07ccd31756b8d2329dc2785c2f7
ackupAgent.java
ackupAgentHelper.java
ackupDataInput.java
ackupDataInputStream.java
ackupDataOutput.java
ackupHelper.java
ackupManager.java
ileBackupHelper.java
haredPreferencesBackupHelper.java
ackage.html
|
| 7cc088232d20a63d24dd1f79f529ddad1b792cde |
13-Apr-2010 |
Christopher Tate <ctate@google.com> |
SDK: last of the backup/restore docs content
There is probably still some editing and cleanup to do, but this takes care
of the last of the "need this documented by the time we ship!" material.
Bug #2465360
Change-Id: Ic4ce9e5a07c79aa2b584a18012a2e8fe199c19fd
ackupAgentHelper.java
ackupDataInputStream.java
ackupHelper.java
|
| 4e14a829129feee14ebe453f61a124784c870610 |
08-Apr-2010 |
Christopher Tate <ctate@google.com> |
SDK: more backup/restore documentation work
Still not complete, but here's a lot more of the necessary documentation.
Submitting a checkpoint seems prudent.
Bug #2465360
Change-Id: Ifff60d57e4b24cee21f3a34f5f50e290d377c386
ackupAgent.java
ackupAgentHelper.java
ackupDataInput.java
ackupDataOutput.java
ackupHelper.java
ackupManager.java
ileBackupHelper.java
haredPreferencesBackupHelper.java
|
| fc922f115325371aaadd4e423472476303039a72 |
09-Apr-2010 |
Christopher Tate <ctate@google.com> |
API CHANGE: remove obsolete constants and hide some methods
This change removes some unused constants from BackupDataOutput
and hides a few methods that do not actually need to be exposed.
Change-Id: I47a9a107a5b58f4d53b5a2fcf9b73a765b1c5dd8
ackupDataOutput.java
|
| 27a63583bfb8b4668911a819f3c7827ef0cc2ec8 |
30-Mar-2010 |
Christopher Tate <ctate@google.com> |
API CHANGE: @hide AbsoluteFileBackupHelper
We don't want to publish this, but for risk mitigation we are hiding it
rather than rewriting/expanding the FileBackupHelper to accomodate the
absolute-path use cases that the system uses internally.
Change-Id: I513c97ec54de8dd7d28b10868d447d94b82d4ec3
bsoluteFileBackupHelper.java
|
| 2d449afe3d075020bdd1115bcc15c9383cbce122 |
30-Mar-2010 |
Christopher Tate <ctate@google.com> |
Make RestoreSession.getAvailableRestoreSets() asynchronous
This transaction can involve the transport having to query a remote backend
over the wire, so it can take a Long Time(tm). Make it main-thread-safe by
making it asynchronous, with the results passed as a callback to the invoker's
RestoreObserver. We also make the IRestoreObserver callback interface
properly oneway.
Bug #2550665
Bug #2549422
Change-Id: If18a233a0a3d54c7b55101715c9e6195b762c5a0
RestoreObserver.aidl
RestoreSession.aidl
estoreObserver.java
estoreSession.java
|
| 03aa34f50d7e8deefeb5e29f96425469c07c281d |
30-Mar-2010 |
Amith Yamasani <yamasani@google.com> |
Fix preloaded classes for API rename of BackupAgentHelper
Change-Id: Ica6301b2aac6879702b98edfcf67fc7bc62002db
ackage.html
|
| cc84c69726507a85116f5664e20e2ebfac76edbe |
29-Mar-2010 |
Christopher Tate <ctate@google.com> |
API CHANGE: rename BackupHelperAgent => BackupAgentHelper per API Council
Part of bug #2545514
Change-Id: Ic775e3b942c485252149c1b6c15c88517fa4e3e5
ackupAgent.java
ackupAgentHelper.java
ackupHelper.java
ackupHelperAgent.java
ackupManager.java
ileBackupHelper.java
haredPreferencesBackupHelper.java
|
| 9c3cee9824026764275e4d84ba9b5d9fdc5da690 |
26-Mar-2010 |
Christopher Tate <ctate@google.com> |
API CHANGE: Backup/restore API changes requested by the API Council
* @hide the android.app.backup.RestoreSession class and functionality
* Provide a public method on android.app.backup.BackupManager that apps
can use to request a restore pass of their last-known-good dataset.
The new method is called requestRestore().
* Provide the name of the package being restored, not just its ordinal,
in the RestoreObserver's onUpdate() callback.
Part of bug #2545514
Change-Id: I9689bf8d6e2b808b4ee412424a36a835be0a5ca8
ackupManager.java
RestoreObserver.aidl
estoreObserver.java
estoreSession.java
|
| 3de55bcd34afd5871816526294f9514d1adf3fe5 |
13-Mar-2010 |
Christopher Tate <ctate@google.com> |
API CHANGE: expose the backup-related ApplicationInfo flag masks
Fixes bug #2507582 by doing the following:
- Un-@hide the FLAG_ALLOW_BACKUP, FLAG_KILL_AFTER_RESTORE, and
FLAG_RESTORE_ANY_VERSION mask constants in ApplicationInfo. These
correspond, respectively, to the <application> manifest tag's
android:allowBackup, android:killAfterRestore, and
android:restoreAnyVersion attributes.
- Remove the android:restoreNeedsApplication attribute and the
corresponding FLAG_RESTORE_NEEDS_APPLICATION constant [which was still
marked @hide]. We now always use the application's own Application
class when performing a normal restore. In the future when we support
an externalized full-filesystem backup/restore operation, we will use
an OS-defined agent class with a base-class Application instance, but
this will not happen until a future release.
Also expands real documentation on the above ApplicationInfo constants;
that work is part of bug #2465360
Change-Id: I735d07a963ae80a01343637d83bef84e4c23fdcc
ackupManager.java
|
| f49501eec5c5c51487e3ec271d5c0dbe1ca9a639 |
06-Mar-2010 |
Christopher Tate <ctate@google.com> |
Fix doc references to "android.backup" to the new "android.app.backup"
Change-Id: Ia347590a374f7e0b8928b0673dc10d55fe785e73
ackage.html
|
| 4528186e0d65fc68ef0dd1941aa2ac8aefcd55a3 |
06-Mar-2010 |
Christopher Tate <ctate@google.com> |
Refactor android.backup => android.app.backup
Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
bsoluteFileBackupHelper.java
ackupAgent.java
ackupDataInput.java
ackupDataInputStream.java
ackupDataOutput.java
ackupHelper.java
ackupHelperAgent.java
ackupHelperDispatcher.java
ackupManager.java
ileBackupHelper.java
ileBackupHelperBase.java
BackupManager.aidl
RestoreObserver.aidl
RestoreSession.aidl
estoreObserver.java
estoreSession.java
estoreSet.aidl
estoreSet.java
haredPreferencesBackupHelper.java
ackage.html
|