File-based encryption regimes turn out to make the zero-copy approach
unworkable. We now copy the file to the local stage for backup purposes,
making sure only to refresh the copy when it changes.
Bug 30201058
Change-Id: Ie3f29ed63f778e3e0e00d1cf56b0bb37553b7823
Otherwise we attempt to link a nonexistent file, which throws, and then
we abort the whole backup outright. This way, we back up exactly what is
present regardless of the presence of each file individually.
We also now make sure to reset to the factory state and then apply the
restored content from there.
Bug 30102506
Change-Id: Ia6a39114f6b84e8cc01342df3da99833d7ca8e9b
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
* 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
This plays nicer with SELinux and generally means we can be more robust
about file security policies.
Bug 28403975
Change-Id: I857ee7073c0090c7515421f41c9334025e25bc79
In addition, now that the full uncropped wallpaper image is being
backed up, we now handle that via the full-data backup path instead
of key/value. Restore still knows about legacy data that gets
delivered via the older key/value mechanism.
This change also has the effect of removing the size limitations
around wallpaper restore acceptance. Any size source imagery is
valid, as crop & scale are rerun in a device-appropriate way
after the restore.
Bug 25453848
Bug 25727875
Change-Id: Idc64a2eaab97a8ecc9d2b8ca5dc011f29cab324d
