This CL adds more 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.
The base cl is ag/1835775
Test: TODO
BUG: 34873525
Change-Id: I127fe739a7522078eecce2ae689a4607203a98da
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
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
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
com.android.server.backup.BackupManagerService#parseLeftoverJournals
uses input stream to read UTF. The method used RandomAccessFile to
perform the operation. The change replace the RandomAccessFile with
a Buffered InputStream.
Bug: 32866032
Test: `make`
Change-Id: I6594cecc49cb6efcfdf73beb5e425688cf890722
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
