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
The bmgr whitelist command was broken
after the selectTransport api cl. This
cl fixes it.
Bug: 34953486
Test: Verify that adb shell bmgr whitelist prints all whitelisted
transports
Change-Id: I3c3275258a45a035a0ca9404d1016ca5663cceaf
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 494df79172 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 494df79172 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
