| 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
|