Previously any apk bundled in priv-app could insert a backup transport.
Reduce risk surface by giving the OEM explicit control over who is
allowed to handle backup data.
Bug 28406080
Change-Id: I84ed954c31b41b671825122e537971b110e00a4d
...if the restoring data engine thread winds up operations. By closing
the engine side of the pipe unconditionally when exiting the thread,
the unanticipated-failure path is now guaranteed (instead of blocking
forever in write() to a pipe that isn't being read!).
In addition, wire agent-timeout handling into the various stream
data-handling operations (preflight, backup, restore). This were
not sufficiently robust and were in some situations leaving the
backup/restore mechanisms in a livelock state.
Finally, plug a longstanding problem in which we'd have orphaned
timeout messages coming in and producing a certain amount of "wtf?"
logging and wasted CPU. No longer!
Bug 28457158
Change-Id: I597c76c3eada378ffeb20870253847594f73e089
The engine itself knows about it, but that's at one remove from the
code that needs to consume it. Make sure it gets passed up the chain.
Bug 28346706
Change-Id: Ib94c9fbc512d92039bb7db5cd6b0b088a4a66027
In particular, don't ask the producer about error overrides when
it is still relying on the consumer to do its job first. This
needs to be policy for *any* transport-side error condition, not
just the one that was previously handled safely. Any transport-
initiated error "on the fly" means that the app-facing side of
the engine doesn't know to stop feeding data, and mustn't be
consulted with any blocking request.
We also now detect unexpected PACKAGE_REJECTED by the transport
after data streaming has begun, and translate that to the general
TRANSPORT_ERROR for correct handling down the line.
Bug 28399225
Bug 28375634
Change-Id: I613dc21bc9f2d23e6520eed6c3ac2e9dbc1d88dc
If an app undergoes restore during install, it is considered 'started'
and the FIRST_LAUNCH broadcast needs to go out. However, this must not
take place until after the restore operation has fully completed, in
order to avoid publishing the app's existence while it may still be in
an incoherent state. We now make this broadcast part of POST_INSTALL
in the restore case.
Bundled apps are in the 'started' state regardless, so no FIRST_LAUNCH
broadcast is ever sent for them -- this CL does not change that
existing behavior even in the case of setup-time data restore of
factory-installed packages.
Bug 28173625
Change-Id: Ibcc3758576662dc447b75476173a0d008a9fe4da
The code was attempting to let a reported error in the app <-> engine
surface take precedence over apparent success at the engine <-> transport
handoff surface. However, in the case of timeout, this is inappropriate.
It was leading to deadlock because the engine runs free, with socket-closed
as its shutdown signals for determinism. In this case that means that
having accidentally asked it to finish and report the final result, we
locked up forever since the data it was writing dutifully to the engine
was no longer being consumed, and the actual teardown signals were never
sent.
The fix is to properly express the error-state hierarchy: only when the
engine <-> transport layer is not issuing its own abort is the app-data-
moving layer consulted about errors detected at that surface.
Bug 22348852
Change-Id: I8987be0c4f708116dfeb08098d7222241ed317f3
We now impose restricted launch behavior and lifetime only on "ordinary"
apps' backup/restore operations. System-ish targets such as the telephony
provider continue to get their full Application instance and providers,
and won't get killed following conclusion of the data-moving operations.
Such customers of backup/restore are expected to be able to deal
gracefully with this sort of thing.
Bug 27362301
Bug 27076602
Change-Id: Ib62483b8469cc750a20f80b7c596ad486a397564
An app can now declare that it really needs to be backed up
whenever possible even if it is currently engaged in foreground-
equivalent work. Only applies to full-data backup clients: key/value
backups are not intrusive on normal lifecycle so they can already
happen in such circumstances.
Bug 26790411
Change-Id: Ia0ebcc7a53da888ae9ae4d63cd4bcab6e3a2e866
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
Previously, all results from runner thread - both for preflight
or full backup pass were ignored.
This change adds two synchronized method to get preflight result
and result of full backup pass.
This leads to better coverage of AGENT_ERROR to return in callback
as a result of backup operation.
On the other side we won't start backup pass in main thread
if preflight check hasn't been succeeded.
Change-Id: Id5f9e4c956a1bd5c396d59b7ad2098139a15e69d
mResult in SinglePackageBackupPreflight could be set
to a negative value if preflight timeouted.
Together with ag/863259 this change will better handle this case.
Bug: 26818914
Change-Id: I171bf95f146552b3b50f044964c2b041f6303d90
(cherry picked from commit a235f7e4e046b1a69af988240ff5f0dd46f3b5f9)
Before this in case of TRANSPORT_ERROR backup pass was aborted before backupFinished() call.
Now this happens in 'finally' block so that there is no way to avoid it.
Also, now backup pass doesn't break in case of QUOTA_EXCEEDED result for single package.
And some refactoring around 'currentPackage' variable.
Bug: 27094847
Change-Id: I18df3f500b427381f32bd11ed1aa87ab9577bc91
(cherry picked from commit 2ea71ad6254c4094d0d34a39d9988c9d75b038ed)
Also make sure not to do the restorecon() before the file is
created.
(Also fix binder identity bug in the 'bmgr fullbackup' flow.)
Bug 26834865
Change-Id: Ia8a59eeb55762264163c8b310caae5e303413571
An app that transitioned from full-data to key/value backup regimes
was being left in the full-data backup queue until next reboot. In
edge cases this would result in the app being inappropriately shut
down for backup; furthermore, it would potentially cause there to
exist a full-data payload for the app that was considered "newest"
and therefore be the one delivered at restore time on a new device
or app (re)installation.
Defense in depth: full-backup candidates are just-in-time reevaluated
for validity when they come up again in the queue; app update
notifications cause a reevaluation and removal from the queue if
full-data is no longer the right modality; and the common engine for
all cloud-facing full-data backups does an additional last-ditch
validation that each stated target is actually supposed to get
full-data backups rather than key/value, to backstop the checks on
queue-presence validity.
Bug 26744511
Change-Id: I55bea3e19a2cab0150dbe5a08dd9fc550f0068c4
Introduces a way to request immediate backup for list of packages
and receive callbacks on backup progress.
Bug: 25688526
Change-Id: Ib826933d44f4ebf2b981f8be366215b2d37847e2
We have to kill the app and bring it up in a controlled lifecycle mode
in order to do full-data backup, and if it's e.g. playing media, this
is hugely disruptive. Instead, we now check whether an app being
considered for full-data backup is in a user-observable state, and
defer its backup if so. We don't kick it all the way down the
daily-backup cycle in this situation -- we set it up to retry the
backup in just a few hours.
Bug 25960428
Change-Id: I576f25c6fb07545565f59bd685624c612b9c5ffd
This is just a straight constant replace. The feature is tracked in a
separate bug b/22388012.
Bug: 19913735
Change-Id: I7ae0953558bfdb77441e9efd749f1bb1cc77050c
When asking for the set of services published by a package, it's
quite possible that there are none, in which case the returned List<>
is null rather than valid-but-empty. Don't bother looking at it
when it's null.
Bug 23614440
Change-Id: Ibebb26b9c3f75ec810a95f1b9d2663e884cb98bc
Specifically: correctly distinguish the "I want to restore my own data"
case, in which the app is intentionally not killed, from the single-package
restore at install operation.
Bug 23357388
Change-Id: Ic50ac39fe942af1f6ec9e04a32d81a39b70a0b2b
The target app crashed at an inopportune time but this shouldn't
invalidate the whole ongoing restore operation; it's a problem local to
the specific app undergoing restore. Recognize this, clean up the app's
possibly-incomplete data, and continue running the restore queue as
planned.
Bug 23228982
Change-Id: If9a19d2fe6a0ce5339c893630d7a61a5a5ccd9b1
The unified code path for cleanup was mistakenly looking at the
android:killAfterRestore manifest attribute even for full-data restore
operations. That attribute is only relevant for key/value payload
handling. We need to *always* kill after restore in the full-data
case because the app will otherwise be allowed to enter normal
component lifecycles without its correct Application / ContentProvider
state in force.
Bug 22704852
Change-Id: Ia63f985a35c28084c734389cfc49d3792173e5c7
The RestoreSession is no longer responsible for calling finishRestore();
that happens as part of tidying up after running the restore itself,
even in failure cases.
Bug 22640096
Change-Id: I0be52af2ae8c2c1ac685e9904ccb8120f7fcf522
Update backup manager todo about backups for profiles
to mention the need for DevicePolicyManager control.
Change-Id: I7f17fc01a53d9608b104b70e57da7f619cb82c5f
The agent instance wasn't properly being conveyed from the generic
restore engine implementation to the state machine handling the
lifecycles. On top of that, the lifecycle wasn't advancing to the
restore-finished callback phase properly in the full-data restore
case.
Bug 22194736
Change-Id: Ic649d6a196adbd21a4a0f3083c7eed2fff383e52
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
