| 924afe2b0f721afa857a55c33da559f6efc41d32 |
|
16-Jun-2017 |
Christopher Tate <ctate@google.com> |
Add 'bmgr' command to synchronously init transports
bmgr init TRANSPORT [...]
will run an init operation on each named transport, blocking
until the operations have all completed.
Bug 62253989
Test: manual
Change-Id: I7dbd94293738d5ecf195764f5b28905253819791
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 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/IBackupManager.aidl
|
| c3704427c9a34397fd90bf5438adae2eebcc97f6 |
|
28-Jan-2017 |
Shreyas Basarge <snb@google.com> |
BackupManager#cancelBackups() API
Introduces a cancelBackups() API for
BackupManager. When this function returns,
it is guaranteed that currently running
backup operations won't interact with
the active transport.
Bug: 34760860
Ref: https://docs.google.com/document/d/18MnfwkDfKNtXQBPRmL8vpVgfLgSWJsDja1Nm1QV5hOw/edit#heading=h.9p6yo0wx44k3
Test: GTS tests at ag/1893365
Change-Id: I67f78699bbe763ea71c85937fbc01a5b48694eed
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| b1f573dca3ccdd113ca513f32c9964211ca71c78 |
|
27-Jan-2017 |
Stefanot <stefanot@google.com> |
Add monitoring to backup in BackupManager.
This is the first CL of many that will add instumentation to
backup/restore operation in the BackupManager. For more details please
point to:
https://docs.google.com/document/d/1sUboR28LjkT1wRXOwVOV3tLo0qisiCvzxIGmzCVEjbI/edit#
This first Cl introduces 3 events that we sent to the monitor.
Test: ag/1858962 (same topic)
BUG: 34873525
Change-Id: I6c338b6fd9f4d7c8670dac201897250b6b170677
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 865303fce57b968f5bd7efb4dd23ccb1a3747b93 |
|
13-Jan-2017 |
Shreyas Basarge <snb@google.com> |
API to select backup transport
This cl adds an API to select a backup
transport by its component name and
receive a callback when BackupManager
is bound to the transport. Calling this API
will make BackupManager bind to the transport
if it isn't already bound to it.
Also fixes the issue where BackupManager would
detect only one transport per package.
Ref: go/backup-transport-switching
Bug: 33616220
Test: Manually tested. GTS tests will be put up shortly.
Change-Id: I8c23bdbb84ceb05eb1fad9b3a8b9c4441cb06c74
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 38e7486d3870797f7cc6e2cd2f5b59462a66b1a6 |
|
11-Jan-2017 |
Shreyas Basarge <snb@google.com> |
Non incremental backup flag for requestBackup
This cl adds a new requestBackup API to
BackupManager that takes in an int flag
to indicate whether the caller wants the
entire key value set to be passed to the
transport and not just a diff.
Change-Id: Ia225797a58c4431fe742f2f116b257d006b30cd1
Bug: 33749084
Ref: go/request-backup-api-changes
Test: GTS Test at ag/1774002
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| e227ec61c24c3c33d42de4996d38fc4e44fa5e4d |
|
16-Jun-2016 |
Christopher Tate <ctate@google.com> |
Let bmgr inspect the set of whitelisted transports
Needed for compliance testing.
Bug 29072466
Change-Id: I025058ab9197f9e2db062bf0074e79f1cd04b443
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 9448196076d5a5266b3ae7e4945216b30ee88aa7 |
|
07-Jan-2016 |
Sergey Poromov <poromov@google.com> |
Add BackupManager#isAppEligibleForBackup() method to Backup API.
Check is done only in framework.
Transport still can deny backup for the package.
Bug: 26443192
Change-Id: Ifcde67a4d11725aa4b15ab4f57d740f55ab2b265
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| fe06bf64d204c459699b0bf6465f9fb69208345e |
|
15-Dec-2015 |
Sergey Poromov <poromov@google.com> |
Introduce BackupManager#requestBackup & BackupObserver API
Introduces a way to request immediate backup for list of packages
and receive callbacks on backup progress.
Bug: 25688526
Change-Id: Ib826933d44f4ebf2b981f8be366215b2d37847e2
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 511d02fcc37dce092e17354d53023db44817ebe6 |
|
09-Apr-2015 |
Christopher Tate <ctate@google.com> |
Add system API for querying the available restore dataset for a package
Bug 20123585
Change-Id: Ife6e77a224b5d4175178aacdb7c285e9944b9eab
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 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/IBackupManager.aidl
|
| 201caf57f9a9699e04620eac9b1fcdaf4338d2f0 |
|
12-Nov-2014 |
Zoltan Szatmary-Ban <szatmz@google.com> |
Adding method to query backup manager service activity status
Bug: 17367491
Change-Id: I9920c07d56c4c0ccb1f3dce637c0fb390902d2ff
/frameworks/base/core/java/android/app/backup/IBackupManager.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
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| c17739d112d8e7076924c7fdd98614abafd58609 |
|
29-Jul-2014 |
Christopher Tate <ctate@google.com> |
Provide outside-facing API for data management intent+label
Bug 16346320
Change-Id: I3f4c2f4b700c77880ba3d8db7c92cdb404763d0d
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 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
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 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
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 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
/frameworks/base/core/java/android/app/backup/IBackupManager.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
/frameworks/base/core/java/android/app/backup/IBackupManager.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
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 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/IBackupManager.aidl
|
| 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
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 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
/frameworks/base/core/java/android/app/backup/IBackupManager.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
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 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/IBackupManager.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
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 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
/frameworks/base/core/java/android/app/backup/IBackupManager.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
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|
| 4528186e0d65fc68ef0dd1941aa2ac8aefcd55a3 |
|
06-Mar-2010 |
Christopher Tate <ctate@google.com> |
Refactor android.backup => android.app.backup
Change-Id: I0b21316ff890d7f3c7d4b82837bb60670724c2e8
/frameworks/base/core/java/android/app/backup/IBackupManager.aidl
|