The scheduling mechanism was properly checking for it, but the raw
data-handling engine wasn't. Now it is.
Bug 32054889
Change-Id: Id57ea12be8e2674c4f678f058278b8c14865b6fa
If writing both system + lock wallpapers winds up hitting the
transport-defined quota, the next backup operation steps back
to storing only the system wallpaper.
Also makes sure to unbind full-backup target agents following
the backup operation. In practice this usually doesn't matter
because the target gets killed following the operation, but
the wallpaper agent runs in the system process where this does
not happen, so was mistakenly being left in place and reused
for the next operation, failing to re-run the full create +
backup lifecycle.
Bug 28968107
Change-Id: I219c2ddd7e899a430ef4cf693b1259464c15eed5
Scheduling involves writing to journal file. This part can be done on the
background thread in order to speed up the unlocking. Deferring writes to
journal file should be safe, because the system will reschedule backups in
case of a crash.
Bug: 29619732
Bug: 29645167
Change-Id: I0667ac2bf159e0f40b7a5066f41ea0841df98437
We're losing the stream footer for mysterious reasons; maybe this
will help even though supposedly close() is expected to flush pending
buffered writes anyway. In particular, an explicit flush of the
compression stage will generate a SYNC_FLUSH point, which ordinary
deflate-at-close operation does not.
Bug 28056941
Change-Id: I96580411257932d7addb176c6672eae72a5ac6f7
Make sure we catch any exception thrown back from the transport,
rather than relying on it to maintain the interface surface. Some
exceptions turn out to be beyond the call-target's control to
prevent.
Bug 29761883
Change-Id: Ifafbac300e7d7dab793237b2fd47d3122751435f
* Exclude key/value-only backup participants until we have a chance to
augment the archive format with proper handling.
* Don't back up 'stopped' apps, which would un-stop them
* Fix unspecified-user bindService/startActivity invocations
* Teach adb restore about the onRestoreFinished() lifecycle method
* Implement proper app timeout handling in the adb data flows
* Backstop wallpaper backup against rare leftover-state issues
Bug 28056941
Change-Id: Ia59c71a2c74a632a2c2a527b9b7374229c440d46
Get the canonical identity and metadata about the package from the
Package Manager at time of usage rather than rely on the caller to
have gotten things right, even when the caller has the system uid.
Bug 28795098
Change-Id: I215786bc894dedf7ca28e9c80cefabd0e40ca877
Gracefully no-op if apps attempt to restore themselves while there is
a backup pass in flight.
Bug 29135379
Change-Id: I8f0b5cd9d149b703e1de7a3a0b4b54c3aff766b6
Work around nebulous lost-timeout issues by adding a backstop timeout
to "wait for result" latch operations. When we hit these, the initial
conditions will be reported as final result; so make those intial states
match the error condition that is appropriate to such a timeout.
Bug 28963707
Change-Id: I4d21a86c48e87633118b1e6eaa05c1d966efec81
Sysconfig define a whitelist of permitted backup transports
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
Backport of 494df791728f4d42d67e935c327910975993ad29 from N
Change-Id: I9f90e324169a68720d608f74754d284a7e59cf87
Sysconfig define a whitelist of permitted backup transports
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
Backport of 494df791728f4d42d67e935c327910975993ad29 from N
Change-Id: I405b49daee8c576584575c3e46877cc97632d8c6
...because the other in-VM reference to that FD means that it won't
get GC'd after we release our local reference to the containing object,
and we wind up with the feeder end blocking on write to a still-fully-
open pipe rather than being made aware that the read end has needed
to shut down.
Bug 28756668
Change-Id: I90b6aaeaabe7d912d96d7ef57c24f68d87d9d0ab
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
