| b59a4b85ade3f1f408def6a0dd3dbb146225bdd7 |
|
03-Mar-2017 |
Johan Toras Halseth <johanth@google.com> |
Add support for key-value packages to adb backup/restore.
For adding CTS tests for packages having key-value backup agents, we add
support for key-value backups to the adb backup/restore command.
Previously, packages not supporting fullbackup would just be skipped on
this command. Now, by adding the -keyvalue flag to the adb backup command,
packages supporting key-value will also be added to the resulting
tarball. Similarly, if the tarball being supplied to adb restore
contains data from key-value packages, it will be restored.
This will later be utilized for writing CTS tests for such packages.
Test: adb backup -includekeyvalue -all && adb restore backup.ab
Change-Id: I7b4ccfb7072d01d29a888952145d7cce90a4f59e
/frameworks/base/core/java/android/app/backup/FullBackup.java
|
| 60af594c3e5834fb710032c2294e36784cdd506f |
|
05-Aug-2016 |
Christopher Tate <ctate@google.com> |
Fix "adb backup -shared"
An accidental side-effect of introducing the XML content file and its
domain semantic checking was that the shared-storage domain got
dropped on the floor. Now the mechanism understands what it means
again.
Bug 29999884
Change-Id: I22b99c96869683d1a92430f237dda54b170b8f60
/frameworks/base/core/java/android/app/backup/FullBackup.java
|
| 8a372a0a280127743ce9a7ce4b6198c7a02d2a4f |
|
16-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
Refactoring FBE APIs based on council feedback.
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
/frameworks/base/core/java/android/app/backup/FullBackup.java
|
| 2c1ba9a961d4f96c26df260ee437655ad9e7c03e |
|
17-Feb-2016 |
Jeff Sharkey <jsharkey@android.com> |
Make BackupManager encryption aware.
Backup requires both CE and DE storage to be available, so delay
spinning up the backup system until the user is unlocked, since
that's when CE storage becomes available. Note that devices without
FBE immediately transition USER_SYSTEM into the unlocked state,
since their CE is always available.
Offer to backup and restore files under both CE and DE. Since DE
is effectively the same as CE, most logic is simply duplicated for
now, but it could be simplified in the future. Since system apps
can force their default storage location to DE, we always build
explicit CE and DE paths.
Add getDataDir() to give clean access to the top-level private data
directory, but disclaim that apps shouldn't create files there.
Bug: 26279618
Change-Id: Ic34a4b330223725db93b1d0f5c9dffc88002c61f
/frameworks/base/core/java/android/app/backup/FullBackup.java
|
| 80e8db3d9cbdd6f42ca83b535abd26d761dc26ee |
|
05-Aug-2015 |
Dmitry Polukhin <dpolukhin@chromium.org> |
[Backup] Special handling for sharedpref files in backup config
Allow specifying sharedpref without .xml suffix as it is for
getSharedPreferences Android API. If .xml extension is missing for
sharedpref file name, it is added in include/exclude filters.
BUG: 20923818
Change-Id: I8bf3d43654b69d847e57c94f23aa3799e01948e6
/frameworks/base/core/java/android/app/backup/FullBackup.java
|
| 303650c9cdb7cec88e7ec20747b161d9fff10719 |
|
18-Apr-2015 |
Matthew Williams <mjwilliams@google.com> |
Add full backup criteria to android manifest
BUG: 20010079
Api change: ApplicationInfo now has a fullBackupContent int
where -1 is (off) 0 is (on) and >0 indicates an xml
resource that should be parsed in order for a developer
to indicate exactly which files they want to include/exclude
from the backup set.
dd: https://docs.google.com/document/d/1dnNctwhWOI-_qtZ7I3iNRtrbShmERj2GFTzwV4xXtOk/edit#heading=h.wcfw1q2pbmae
Change-Id: I90273dc0aef5e9a3230c6b074a45e8f5409ed5ce
/frameworks/base/core/java/android/app/backup/FullBackup.java
|
| 11ae768cf1b8348e761ad9c09e98788da1e591b1 |
|
25-Mar-2015 |
Christopher Tate <ctate@google.com> |
Add payload-size preflight stage to full transport backup
We now peform a total-size preflight pass before committing data to the
wire. This is to eliminate the large superfluous network traffic that
would otherwise happen if the transport enforces internal quotas: we
now instead ask the transport up front whether it's prepared to accept
a given payload size for the package.
From the app's perspective this preflight operation is indistinguishable
from a full-data backup pass. If the app has provided its own full-data
handling in a subclassed backup agent, their usual file-providing code
path will be executed. However, the files named for backup during this
pass are not opened and read; just measured for their total size. As
far as component lifecycles, this measurement pass is simply another
call to the agent, immediately after it is bound, with identical
timeout semantics to the existing full-data backup invocation.
Once the app's file set has been measured the preflight operation
invokes a new method on BackupTransport, called checkFullBackupSize().
This method is called after performFullBackup() (which applies any
overall whitelist/blacklist policy) but before any data is delivered
to the transport via sendBackupData(). The return code from
checkFullBackupSize() is similar to the other transport methods:
TRANSPORT_OK to permit the full backup to proceed; or
TRANSPORT_REJECT_PACKAGE to indicate that the requested payload is
unacceptable; or TRANSPORT_ERROR to report a more serious overall
transport-level problem that prevents a full-data backup operation
from occurring right now.
The estimated payload currently does not include the size of the
source-package metadata (technically, the manifest entry in its
archive payload) or the size of any widget metadata associated with
the package's install. In practice this means the preflighted size
underestimates by 3 to 5 KB. In addition, the preflight API currently
cannot distinguish between payload sizes larger than 2 gigabytes;
any payload estimate larger than that is passed as Integer.MAX_VALUE
to the checkFullBackupSize() query.
Bug 19846750
Change-Id: I44498201e2d4b07482dcb3ca8fa6935dddc467ca
/frameworks/base/core/java/android/app/backup/FullBackup.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
/frameworks/base/core/java/android/app/backup/FullBackup.java
|
| 10596fbcce710a76ffc7e917400df13af5c2ebcb |
|
28-Apr-2014 |
Elliott Hughes <enh@google.com> |
resolved conflicts for merge of 3ce4f3d0 to master
Change-Id: Id5c5997ad8f801b32e1dbd97413ea42e38c27210
|
| 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
/frameworks/base/core/java/android/app/backup/FullBackup.java
|
| 6090995951c6e2e4dcf38102f01793f8a94166e1 |
|
19-Nov-2013 |
John Spurlock <jspurlock@google.com> |
Remove unused imports from frameworks/base.
Change-Id: Ia1f99bd2c1105b0b0f70aa614f1f4a67b2840906
/frameworks/base/core/java/android/app/backup/FullBackup.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
/frameworks/base/core/java/android/app/backup/FullBackup.java
|
| 46cc43c6fa7623820d4ae9149496cf96bb15f8a3 |
|
19-Feb-2013 |
Christopher Tate <ctate@google.com> |
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.
Bug: 6718844
Change-Id: Ie252494e2327e9ab97cf9ed87c298410a8618492
/frameworks/base/core/java/android/app/backup/FullBackup.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
/frameworks/base/core/java/android/app/backup/FullBackup.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
/frameworks/base/core/java/android/app/backup/FullBackup.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
/frameworks/base/core/java/android/app/backup/FullBackup.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
/frameworks/base/core/java/android/app/backup/FullBackup.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
/frameworks/base/core/java/android/app/backup/FullBackup.java
|
| 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
/frameworks/base/core/java/android/app/backup/FullBackup.java
|