A recent change in nyc-mr2 means that setWallpaperComponent will
promote any static system wallpaper to the lock screen. If we don't
actually have a static lock wallpaper to restore, we need to explicitly
clear the lock wallpaper to have the live one show through
Test: manually using adb backup / restore
Bug: 35090402
Change-Id: I8a2c5ffbaefe172c9d78a9f746ab87d9bc6b7448
If WallpaperManager is asked to read a wallpaper between when we
call mWm.clear and mWm.setStream, it is possible for us to end
up losing restored state such as cropHint and allowBackup
By not calling mWm.clear, we make this much less likely to happen.
It isn't necessary to call clear, as will explicitly overwrite
all the interesting state anyway.
Test: by repeated adb restore
Bug: 34760753
Change-Id: I2750695d5dd16077b47b5b8fca3a667b98cc4f6c
By gating this on system/lock wallpaper imagery state we were
inadvertently missing backup state for some live-wallpaper use
cases.
Bug 31023198
Change-Id: Ie53000453e6618844be7c01766c1b715d14cc713
We now correctly:
- avoid backing up stale lock-wallpaper imagery when it is
present but unused,
- restore system+lock wallpaper state when that was the
source device's situation
Bug 30274136
Change-Id: Ib34f635f9d840c64f96cc7fdb67279ce5f6422fc
Pass 'null' as the crop hint when the crop as expressed in the restored
wallpaper metadata is either unspecified or effectively empty.
Bug 30521402
Bug 30274136
Change-Id: I14e5d2bae1ec30fb27e8fd45b340b2ca87f35a01
It's fine for wallpaper backups to proceed even while the system uid
is considered to be doing something foreground-equivalent, since it's
in its own process and killing it won't interrupt the actual system
work.
Bug 30662562
Change-Id: I463c1ed221da17fbeb336b3be09d3b1ac47aca80
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
