• Home
  • History
  • Annotate
  • only in /frameworks/base/core/java/android/app/backup/
History log of /frameworks/base/core/java/android/app/backup/
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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