We now try to perform key/value backups only while charging, proceeding
off-charger only after we've waited a full day for the device to be
plugged in.
Bug 21076663
Change-Id: Ib32c9f8bfaf8a310f5f388907e38a28d3c54bd8e
We still retain the data in the backup, in order to support the flow
in which a user has the app and its data is stored; then the app
is uninstalled; then later the app is reinstalled. We depend on
having correct metadata for the data in the datastore in order to
evaluate its validity for restore-at-install, so we mustn't
forget that metadata just because the app is not currently
installed.
We also now permit the sentinel pseudopackage name "@pm@" as an
argument to dataChanged(), indicating specifically that the metadata
should be scheduled for backup without having to be piggybacked on
another app's requested backup pass. That lets us now make sure to
schedule a backup pass for metadata-update in response to app
install activity.
Finally, fix a "min instead of max" bug in full backup scheduling
that was causing the OS to ignore the transport's inter-package
quiet time requirement when multiple packages were overdue for
backup.
Bug 21471973
Change-Id: I1dbc260edb91b8deadd2744e273dfa9578b9ef2a
OTA or similar might have caused an app to appear without the usual
notifications being sent. Make sure we pick up those apps as
appropriate for full-data backup.
Bug 19462310
Change-Id: Ic17bc72b14cc7599ae8ea540548fda932606b8f2
Significantly narrow the circumstances under which transports
will be re-bound. In particular, we now do not unbind + rebind
whenever any component in a bound transport's host package changes;
rather, we do so only when the transport component itself has
changed state, or when there is a state change that might cause
a new transport to become available.
Bug 19775237
Change-Id: Ib386875df19ffe9f2d3eb9f9788187338360644a
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
If a scheduled full-data backup was attempted but the device had not yet
run the primary key/value backup pass, the full-data backup scheduler
would wind up in a bad state and potentially never retry until reboot.
We now properly reschedule a future retry, using the key/value
scheduling batch quantum as a backoff to be sure to give it a chance
to run before the next time full data is attempted.
Change-Id: Ic7eb7a7940fe6380f40d04813a46fc336e95815e
We now make sure to pause by at least requestFullBackupTime() between full-data
backup operations, to give the transport the ability to apply traffic control
while we're running the queue of eligible packages.
Also, we now reset a package's queue position whenever a full-data backup for
that package is run explicitly via adb.
Bug 19732890
Change-Id: I6cf24495ad18eebd55557f229d11c703e5b7f529
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
Tracking the deprecation of older API variants and switching to the
new and more informative versions. Also tidying up a few unused
variables along the way.
Change-Id: I282a18525f9db838f4e0a77c90403b8b904e4fd7
We already decline to run key/value backup passes for (participating)
apps that are in the 'stopped' state. Now we also properly avoid
full-data backup passes on such apps.
Bug 19684052
Change-Id: Ieafc07b5531a91a243d57238c53db41ad3459140
We are correctly refusing to actually process apps for backup if they have
declared android:allowBackup="false" in their manifests, but we're still
wasting bookkeeping & a certain amount of work in tracking them as part of
the full backup queue. Fix that; now we recognize that they shouldn't be
in the queue in the first place.
When reinflating the queue at boot time we also re-verify the participation
of each mentioned app so that we properly drop ones that have been uninstalled
or altered such that they are no longer full-data backup candidates.
Finally, if an app previously implemented key/value backup, so we think
we'll be running it in that mode in a future backup pass, but has been
updated to use the full-data path instead, we don't want to go ahead and
run a key/value pass on it. Added a backstop check and proceed gracefully
in this situation.
(Also add bit more debug-build logging to LocalTransport)
Bug 19462310
Change-Id: I07ab4f2e68e92766d9e8f2595fa763c91193d743
Instead of a runs-forever periodic alarm that drives key/value backup
passes, we instead schedule-on-demand a trigger job that will kick off
the pass after a batching interval. The key semantic change is that
we now never wake for key/value backup work unless we've been explicitly
asked to do so. We also use a rather longer batching interval than
was previously the case.
Bug 19536032
Change-Id: Ie377562b2812c9aeda0ee73770dfa94af6017778
There's a narrow window of time in which an agent reporting that its
operation has completed races with timeouts such that we wind up
handling the completion callback just after certain fundamental state
has been reset. Detect this race and proceed gracefully instead of
crashing.
Bug 19498669
Change-Id: I5a475527db1a55a8e567366ddfb10112e427682e
Make sure that even if backup is disabled outright (and hence there
is no underlying service implementation for the trampoline to delegate
to), the DUMP permission exception is thrown as expected.
Bug 19422232
Change-Id: I6d1a17c5f85adcfad75af969b521920e786c05a8
The public API field android.content.pm.ApplicationInfo.flags can
support only 32 flags. This limit has been reached. As a short term
workaround to enable new public flags to be added, this CL moves flags
which are not public API into a separate new field privateFlags and
renames the affected flags constants accordingly (e.g., FLAG_PRIVILEGED
is now PRIVATE_FLAG_PRIVILEGED).
The new privateFlags field is not public API and should not be used
for flags that are public API.
The flags that are moved out of ApplicationInfo.flags are:
* FLAG_HIDDEN,
* FLAG_CANT_SAVE_STATE,
* FLAG_FORWARD_LOCK, and
* FLAG_PRIVILEGED.
NOTE: This changes the format of packages.xml. Prior to this CL flags
were stored in the "flags" attribute. With this CL, the public flags
are stored in a new "publicFlags" attribute and private flags are
stored in a new "privateFlags" attribute. The old "flags" attribute
is interpreted by using the old values of hidden/private flags.
Change-Id: Ie23eb8ddd5129de3c6e008c5261b639e22182ee5
If the scheduled job fires but backup is disabled or the device is
not yet provisioned (i.e. has not yet finished going through setup),
bow out gracefully without running any backup operations. Also, even
if a backup is directly invoked (e.g. via adb), verify again right
before we start collecting app data, and abandon the operation in
that path as well.
(This is redundant; having only the latter test would suffice, but
this lets us distinguish in the logging more easily.)
Finally, make sure that if we were waiting on setup before permitting
backup operations to begin, that we startup the full-data scheduling
as well as the [separate] key/value scheduling.
Bug 19197062
Change-Id: I3d8fb650c50f946d8ed7ac7170df361c707f2528
Redundant backup traffic is bad. Don't commit the widget metadata payload
(or the deletion operation for it) unless the widget state of the app has
actually changed since the last backup.
Bug 19003911
Change-Id: I93819173c0e2357b030d9e2b3d2ee57f2410bb57
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
If a whole-system restore operation failed at just the wrong point,
we'd wind up in the teardown code without a certain vital bit of it
having been initialized, and crash on the null pointer. Now we
recognize this failure mode and make sure not to do that.
Bug 18574450
Change-Id: Ifa2c10ce16bb3c6bc916ed7151c5fd51b7225691
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
Ensure that the callback always sees the current-operation state in sync
with the various other bits of internal backup-operation state. Previously
only the current-operation state was managed inside the critical section;
this resulted in a slim race window where a callback could see an ongoing
operation as still valid, but after the internal state on which that
operation depended had already been cleared.
Bug 17931760
Change-Id: Ia032668e7a9d22f1029c57fc98db9e86484d5719
The restore-session idle timeout should not be ticking while we're
doing legitimate restore work. We now explicitly stop the timeout
ticker [a delayed message on our handler thread] whenever we undertake
a valid restore operation. The timer is already correctly resumed
when restore operations conclude.
(In practice we need to suspend the timeout tracking at exactly those
times when we're entering the wakelock-protected restore flow. The
timeout is reestablished when the wakelock is released; this part
is already in the code.)
Bug 17990544
Change-Id: I7318020ce30fd9c35bc3a644f8c101fd3d063c8b
We know a priori that the PMBA metadata package's backup pass
doesn't need to be tracked for timeout, because it's run inline
rather than as an asynchronous separate-process operation.
Change-Id: Ifd21ab3a016917f5e557a38c1c88f8d8ac1337d2
Before beginning a full-system restore we need to tell the widget service,
so that it can properly start remapping IDs from the ground state.
Bug 17869323
Change-Id: I152257563f5b52cae67244e936bc2c44ced7618d
Bug 17811327 : teach adb restore about the new widget metadata entries
Bug 14165872 : -nosystem should not act like -onlysystem
Change-Id: I39da0ba80df7c5309a78ec1fa38016cebd80aa5f
For fallback / rollback of backup transport selection we need to
handle live enable/disable of legacy or superseded transports.
We now watch for component enable state changes in packages that
host transports, and rebind as needed.
The semantics for selecting the current transport have also been
adjusted. We no longer require that the selected transport be
live and currently bound in order to be designated as the active
instance. This prevents nondeterministic races around upgrade
and replacement.
Bug 17136637
Change-Id: Idaf45cf4522a23576444e6b11626ee3f7f47c36c
...around writing settings. It does its own proper permission check;
it just needs to make sure not to accidentally crash the caller in
strange and wondrous ways because of failing to clear binder identity
before writing the result to secure settings.
Bug 16542048
Change-Id: I88d1f2dbeebd24eed5d86989f0ca0d834878b054
Provisioning is a milestone used for gating *backup* operation,
but it's important that restores be possible during the setup
process. In particular, some applications such as home apps may
be deliberately pushed for install after platform restore, but
before the end of the setup process. We need to be able to do
install-time restores of such apps.
Bug 17288313
Change-Id: Iaff5d9919e6392b2ca5925be4d63a4116cd11f77
The "what have we ever succesfully backed up?" log is used to determine
whether we can do an install-time restore from the currently-live dataset
rather than go back to the ancestral dataset (if any). We now track
apps that have gotten a successful full-data backup through the transport,
not just key/value backups.
Bug 17263823
Change-Id: If21350a8dd8aaa4ed02fb74101617e935920e4ae
They'll be rebound automatically at boot, but need to be brought
up immediately. As always they can only be provided by privileged
apps.
Bug 16542048
Change-Id: I9f121a5c111a772deb3f0c44166002a2cbb16ad5
New behavior. Backup no longer uses the encryption password. This is in
part because that is hard with patterns, in part because it is a security
issue - the off line backup is much easier to brute force than the phone.
Instead, we simply insist on an encryption password if your device is encrypted
and locked.
Bug: 17159330
Change-Id: Ia22f84722522abf0b569a3ef1e16ead5527c726d
When a package is updated, existing bindings to that package's
services are severed and must be manually re-established. Now
that the transport can be updated outside the system per se,
make sure that we detect these cases and rebind as needed.
Bug 16139912
Change-Id: I5d6fa75bb86484f8f7d4f8e93c9157773995e6a7
If an app is trying to do the right thing and end its restore sessions
cleanly, but winds up being slow and having the session timed out from
under them, don't crash them with an illegal state exception for having
appeared to end the session twice.
Bug 17133115
Change-Id: I0a0989e2067b156569bddb6626ce045e625c6604
1. We were missing a 'break' in the session-timeout case of
message dispatch, so were falling through into a different
case. Oops. Fortunately it was benign; the other case's
logic was merely logging "hey it doesn't look like there's
anything to do here" and cleanly exiting.
2. After a restore operation finishes we were previously
always leaving the session timeout clock running. However,
this was not appropriate in the case of restore-at-install,
when the restore was a one-shot kicked off by the package
manager rather than an operation on an ongoing RestoreSession.
That logic now properly tidies up the session timeout when
winding up the restore in either situation.
Bug 17080648
Change-Id: I51d4a50db4feefc4c355230a3bfb926ea2fb5944
Harden the guarantee that if we're asked about a possible restore,
we always ALWAYS report back to the package manager. This involved
closing "should never happen" edge cases around provisioning/auto-restore
setting that nevertheless were happening.
Also, on the auto-restore setting front, make sure to plumb that
system API through appropriately, since going behind its back and
manipulating the secure setting directly would cause things to get
out of step.
Bug 17060654
Change-Id: I52ca9c1ffbfc0bd6b57196157500d0868bfc2989
