| 1760fe3f9556a1ce233d99d01540fc0a6837a33a |
|
16-Feb-2016 |
Sergey Poromov <poromov@google.com> |
Fix BackupTransport#getBackupQuota() javadoc.
Change-Id: Ifff3329c618dabd2e73011439a2ddce2f0eeabf6
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| 872d3b6e19933af6fa9ae65214b9f6df04fc3222 |
|
12-Jan-2016 |
Sergey Poromov <poromov@google.com> |
Quota exceeded API in BackupAgent
Should be also implemented in GMS BackupTransport.
Bug: 25693504
Change-Id: I6e4b2edb6d62addca0aced3e801d7629fb9394ca
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| 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/BackupTransport.java
|
| 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/BackupTransport.java
|
| 0e3de6cacaffcfeda4d6353be61e2f1f9ed80705 |
|
30-Jul-2015 |
Dianne Hackborn <hackbod@google.com> |
Change MNC codename to just M.
Change-Id: I4281d200ff6560791c47cf9073ceea1cb509361e
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| 56341e70a23338900ec015450a7eca8fdb17d8d5 |
|
14-May-2015 |
Christopher Tate <ctate@google.com> |
Clarify docs for BackupTransport.initializeDevice()
Explicitly call out that even if the backend is in an undefined state
(such as no authenticated account, so there is by definition no work
that can be done here), the transport should return TRANSPORT_OK in
response to initializeDevice(). Error returns from that method must
only be used to indicate that the initialize should be *retried*.
Bug 21136957
Change-Id: I41ad115b92c16092b4d931d9c554a44b77945359
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| 9310e4285b3fc951c3524d040726d1161015562c |
|
10-Apr-2015 |
Christopher Tate <ctate@google.com> |
Avoid zero-payload backups in local transport
The local debugging transport now implements
BackupTransport.checkFullBackupSize() to detect and reject backup attempts
for which no actual file content will be committed. The documentation for
checkFullBackupSize() has also been expanded to document the transport's
responsibilities in this regard.
The local transport now lazy-creates the destination file when data is
first delivered for an approved backup operation, rather than doing it
proactively in performBackup(), to ensure that changes in the datastore
are only attempted after the transport has positive confirmation that
data is indeed flowing.
Change-Id: I6e47a7e72cd938fc0ed31da4bc490540c71f9e65
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| e012a235569fe307d165dfd0784ae847d0b13739 |
|
02-Apr-2015 |
Christopher Tate <ctate@google.com> |
Back up / restore preferred app configuration
Bug 19848104
Change-Id: I84cdfcc44b48a9732984955d7eedf745b5586bdd
/frameworks/base/core/java/android/app/backup/BackupTransport.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/BackupTransport.java
|
| b89e1405cf9f1da533dc0843390a1b6783abb0f4 |
|
07-Jan-2015 |
Christopher Tate <ctate@google.com> |
Support single-package backup rejection by the transport
We now cleanly handle the case of the transport blacklisting specific
packages from key/value backup. Previously we would halt the entire
backup pass and reschedule if the transport returned any error from
performBackup(pkg). Now, we recognize the TRANSPORT_PACKAGE_REJECTED
result from that invocation, and properly drop that package's work
but proceed with running the rest of the backup queue as expected.
Bug 18694053
Change-Id: Id0dd6d59492bdea9f970540d776f37db0cc5d99c
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| ff31addb9b767496ba5c907513be172779eadfc5 |
|
18-Aug-2014 |
arete <arete@google.com> |
Expose system apis for backup transport migration
Bug: 16542048
Change-Id: I45e710028316e7b2dc4195700a1e7344afb54691
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| bf1a4a81ebd340a18583f4ca9b5d562a01f55674 |
|
09-Aug-2014 |
Christopher Tate <ctate@google.com> |
Start using cancelFullBackup() when appropriate
The API was in place but the framework wasn't yet calling it.
Bug 16524520
Change-Id: Ie368758c830a7d0ad11e7dd3142a0ed896069944
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| e079264b981d87c648921185528b553a86ae353d |
|
07-Aug-2014 |
Christopher Tate <ctate@google.com> |
API to tell the transport to cancel a full backup in progress
Bug 16524520
Change-Id: If2cbffd3c8a03bf4eb7b11ff1ae784c437e27e7f
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| d5cf722ae62d06d1fb6a9505c6f4c403a5d14a37 |
|
30-Jul-2014 |
Christopher Tate <ctate@google.com> |
Reify the transport lookup/selection API
Introduce a stable BackupTransport interface class for transport
implementations to derive from.
Make the interface for viewing/selecting the active backup transport
part of the stable API.
Make restore-related classes (RestoreSession, RestoreSet) stable API.
Express backup manager APIs needed for transport operation as
@SystemApi methods in BackupManager.
Bug 16661321
Change-Id: I423b87ae8f45c1b77831d4f8ffd97715484c2d2b
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| 9679410db578e179c7559e7a52bb21c8082e9631 |
|
28-Jul-2014 |
Christopher Tate <ctate@google.com> |
Add data-management intent + label to BackupTransport API
Bug 16346320
Change-Id: Id9e855a1d3cebbf801c27a21e1edc3ffcccfd2e9
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| a176d22110a1670f363ba0f745f127d2b6ca2350 |
|
16-Jul-2014 |
Christopher Tate <ctate@google.com> |
Always call finishBackup() if performFullBackup() succeeded
Even if we later get an error from sendBackupData() we need to give
the transport its teardown callback. This simplifies the transport
logic considerably.
Change-Id: Ib8c0e210d4a876ee6b083a4d619dfccc462da4e5
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| 51fea57e06fcb1dab1d239a5fff6e75ba2b7cee7 |
|
24-Jun-2014 |
Christopher Tate <ctate@google.com> |
Refactor restore to deal with heterogeneous datasets
Transport-based restore now handles both key/value and full-data
(stream) data delivery.
Also: PMBA now holds metadata for *all* apps, not just those with
backup agents. Since we need to consult this for every restore-
at-install operation we cache this locally now, tagged per transport
and per remote dataset, to avoid having to re-download it as part
of every future restore operation.
Also fixed a bug in LocalTransport that was preventing restore of
key/value datasets, i.e. all of them that were nominally available
prior to this change.
NOTE: at present there is no automatic full-data backup; if for
testing purposes you need to create some to then use for restore,
you still need to use 'bmgr fullbackup ...' to push them.
NOTE: at present the unified transport restore uses a refactored
"engine" implementation to handle stream data that encapsulates
the existing "adb restore" implementation. However, the adb
restore code path has not yet been refactored to wrap the newly-
extracted engine version; it still contains its own copy of all
the relevant logic. This will change in a future CL, at which
point offline/USB archive restore will simply wrap the same
shared stream-restore engine implementation.
Bug 15330073
Bug 15989617
Change-Id: Ieedb18fd7836ad31ba24656ec9feaaf69e164af8
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| 5a009f9008d1f18b156c142b69e173109f5e218b |
|
19-Jun-2014 |
Christopher Tate <ctate@google.com> |
Adjust full restore API
Introduces a new constant, BackupTransport.NO_MORE_DATA, defined to
be -1. The transport returns this constant when asked for the next
chunk of streaming full restore data to indicate that it has reached
EOF on the current restore target's archive stream.
If the transport returns TRANSPORT_PACKAGE_REJECTED from that same
method, then the OS will abort the current target's restore operation
and move on to the next package in the overall restore dataset (by
calling nextRestorePackage() on the transport).
If the transport returns zero when asked for the next chunk of
restore stream data, this will be interpreted as meaning that no data
is currently deliverable but the restore download is still running
properly; the caller will then retry until either data is delivered
or the transport reports NO_MORE_DATA (or an error).
Also sketched in the implementation of this latest API in the
test LocalTransport.
Bug 15330073
Change-Id: I81621cb322f831460133b7dced5bb88d2a4124e1
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| 6a49dd087f29cfca82d55dfabeb97439ef84b508 |
|
17-Jun-2014 |
Christopher Tate <ctate@google.com> |
Tweak restore API
We need the transport to tell the system not only what package it's going
to deliver data for next, but also what format that data is in.
Change-Id: I989cf78febf923a4208acb33ed80ccc7869356f5
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| 9ff53a7100b1a40f5d2df3eb19a2f3f2fff39a46 |
|
04-Jun-2014 |
Christopher Tate <ctate@google.com> |
Implement full data backup through transport
Currently no timed/scheduled full-data backup operations are
performed by the OS, but the plumbing is now in place and can
be tested using 'adb shell bmgr fullbackup pkg [pkg2 pkg3 ...]'.
The LocalTransport test transport implementation has been augmented
to support the new full-data backup API as well.
In addition, 'adb backup' now takes the -compress/-nocompress
command line options to control whether the resulting archive is
compressed before leaving the device. Previously the archive was
always compressed. (The default is still to compress, as it will
usually reduce the archive size considerably.)
Internally, the core implementation of gathering the full backup
data stream from the target application has been refactored into
an "engine" component that is shared by both 'adb backup' and the
transport-oriented full backup task. The archive file header
generation, encryption, and compression logic are now factored out
of the engine itself instead of being hardwired into the data
handling.
Bug 15329632
Change-Id: I4a044faa4070d684ef457bd3e11771198cdf557c
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| c777185688d1de4f1c989b3f7630e7715fd71be3 |
|
03-Jun-2014 |
Christopher Tate <ctate@google.com> |
Finish migration of backup transport constants
...and make sure to fix a couple of lingering Javadoc references.
Bug 15329632
Change-Id: I1de7b53a58940834cd2dae2301fd5f65dbb48ba6
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| 4dd2635bf501ad1a1adc22a6ceb4c66cd61a1a23 |
|
03-Jun-2014 |
Christopher Tate <ctate@google.com> |
Add full-backup stream API to BackupTransport
Also started migrating the definition of transport success/failure constants
into BackupTransport to make them permanent.
The new methods are not yet plumbed in; this is just to allow forward
progress against a proposed stable API.
Bug 15329632
Change-Id: I27472e09b831350c140b9fa548ebda3af334eb1a
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|
| 74318c98a0f67e042815798f85c75eb7f14390e1 |
|
16-May-2014 |
Christopher Tate <ctate@google.com> |
Provide stable concrete wrapper for backup transport API
This initial version is a simple pass-through of the existing
IBackupTransport AIDL definition.
Change-Id: I0f6c9ffc7101f82127ab61ba6cba9f5003af6a0c
/frameworks/base/core/java/android/app/backup/BackupTransport.java
|