| 9f22443b4e3ac1ca1763a25a186177809ec1c3cb |
|
02-Aug-2017 |
Christopher Tate <ctate@google.com> |
Use normal API for legacy wallpaper restore
No longer do we play crazy rename-into-place tricks! Just take
the restored image and treat it as an ordinary new system wallpaper,
and let the system machinery do all its proper work. While we're at
it, we get rid of the now-spurious shenanigans about backing up the
wallpaper under the 'android' package, an overdue and welcome bit
of thinning.
In addition, we now fully migrate a legacy wallpaper image to have
both a source and a display crop in place. We were previously
not generating the equivalent source image, which made N+ backups
unable to store the image properly.
Fix 64269208
Fix 62809439
Test: manual (set wallpaper under M, backup, flash to ToT,
force restore)
Change-Id: If9b26b777f0fda95cf37c3c790a3fa4e82ff0340
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| ebadfb17e77c5e297635376dbdbcf1615192620f |
|
25-Jul-2016 |
Christopher Tate <ctate@google.com> |
Fix wallpaper restore from pre-N devices
The previous path "worked" but left the wallpaper bookkeeping with
incorrect SELinux labeling, which led to cascade failures later on
when apps tried to set new system wallpaper imagery or read the
current image for the picker UI.
We now (a) explicitly label wallpaper files in all change cases,
(b) let the restored imagery flow through the full crop path, as
should have been done in the first place, and as a result (c) lift
the size restrictions on the source image, because now we are doing
a device-appropriate scaling operation on the image.
The "when to crop/scale" test has been slightly relaxed such that
a restored image of exactly the right size now longer triggers a
superfluous factor-1.0 scaling operation.
Bug 30361282
Change-Id: I9a305eea2227952493f64ab78862648cafb816ff
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 41297ff82c94d28fe19a6dd8f6214aee7c0af8e2 |
|
11-Mar-2016 |
Christopher Tate <ctate@google.com> |
Once restored, the wallpaper needs to actually draw
We now wait until both the wallpaper imagery and the metadata have
been restored [if present], and then explicitly regenerate the crop
from the source based on that.
Bug 27423845
Change-Id: I986efd13b6b73d25b5ab1215af516ccea3a5c609
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| bd0e03bb763ae7956ecba35fe5759d4b443158ca |
|
21-Aug-2015 |
Xiaohui Chen <xiaohuic@google.com> |
More USER_OWNER cleanup.
Bug: 19913735
Change-Id: I408a92d9dbab2a096407efccb91e2a8bdc22714d
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 31f25696d950dd54e8b339074b98ad6335738f2f |
|
03-Dec-2014 |
Christopher Tate <ctate@google.com> |
Adjust wallpaper-restore acceptance criteria
Previously the dimension check had implicit orientation sensitivity.
We now make sure to compare the candidate image's width to the smallest
screen dimension for acceptance purposes; this fixes cases when we would
e.g. get a restored image of (1680x2560) but believe that we needed it
to have a max width of 2048, even though it had originated on that same
device -- due to current-orientation issues.
Bug 18448052
Change-Id: I64ca6a4ed91ce1ccc04f5a9a6851e5cfe511b7c7
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 1133e29f22252cc36102f41204c3de35779e49d2 |
|
10-Oct-2014 |
Christopher Tate <ctate@google.com> |
Tweak wallpaper restore rejection threshold
Raise the height ratio threshold slightly in order to start accepting
restores of height=1920 images onto height=2560 devices.
Bug 17882661
Change-Id: I63b47817fdf754cda9a052bddb62aee764522c6f
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 431906b34f33e23b5407fc2f72f8c085ef572816 |
|
08-Oct-2014 |
Christopher Tate <ctate@google.com> |
Turn on dimension validation in wallpaper restore
Bug 17906491
Change-Id: I4c76c3197df95b51a6e44d1fe2d522b6c05284e5
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 406abd45471c523aea151f5aca84b008fee02bbe |
|
07-Oct-2014 |
Christopher Tate <ctate@google.com> |
Accept any restored wallpaper
...and let the wallpaper service & hosts figure out what to do
with it.
Bug 17677006
Change-Id: Ie5bfa549af4da178e621ffc42a759a552897d93a
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 004c16654f2f86ff3055f3c88b5498eb3254f2e1 |
|
02-Oct-2014 |
Christopher Tate <ctate@google.com> |
Tweak wallpaper restore acceptance heuristics
We now accept for restore any image that is at least wide enough to
fit the screen, and has a height within a comfortable margin of the
previously stated target.
Bug 17677006
Change-Id: I5937a82ddfbfa0bbb30d568621eb48e4b3533fac
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 8ab0865156d447fbebcc366164ca7c57108ea57c |
|
27-Aug-2014 |
Christopher Tate <ctate@google.com> |
Briefly log wallpaper restore outcomes
Bug 17112780
Change-Id: I3e9a23d28c9df4f708eb24b4688322c21a8c8382
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 61f57379ca2c5b6290c8da7548fa17128f7ab24f |
|
31-Aug-2012 |
Amith Yamasani <yamasani@google.com> |
Centralize the creation of the user system directory
Environment.getUserSystemDirectory(int userId)
Use it all relevant places that was hardcoding it.
Also, wipe out the user's system directory when user is removed, otherwise old state
might be transferred to a new user.
Change-Id: I788ce9c4cf9624229e65efa7047bc0c019ccef0a
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 37ce3a8af6faab675319d0803b288ab1dddc76be |
|
06-Feb-2012 |
Amith Yamasani <yamasani@google.com> |
Multi-user - wallpaper service
- Allow each user to have their own wallpaper (live or static).
- Migrate old wallpaper on upgrade.
- Update SystemBackupAgent to backup/restore from primary user's
new wallpaper directory.
Reduce dependency on Binder.getOrigCallingUser() by passing the
userId for bindService.
Change-Id: I19c8c3296d3d2efa7f28f951d4b84407489e2166
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| bf6ee4f509cbe7a44f4cc72f28e6150ca47c066d |
|
07-Oct-2011 |
Christopher Tate <ctate@google.com> |
Fix wallpaper restore
Following a restore of the wallpaper data files, the settingsRestored()
method was binding the new wallpaper by passing null as the component,
because once upon a time that meant just use the configuration that had
just been loaded from the [newly restored] settings filed. However, at
some point this broke when the load from settings was made a staging
operation, not also the commitment of the changes.
This CL passes the newly-determined component configuration explicitly
to the bind, overriding the product default that may already have been
emplaced by the time the restore happens.
It also turns off the (minor) debugging that had been enabled in
WallpaperBackupHelper while digging into the issue.
Bug 5416839
Change-Id: I963893c236e24c75d10dde75836805295ea42cbb
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 44bc17c6b517aef35a390c81b5aa79c4f284f744 |
|
21-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Rework display size access.
Applications now get the display size from the window manager. No
behavior should be changed yet, this is just prep for some real
changes.
Change-Id: I2958a6660895c1cba2b670509600014e55ee9273
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 9b95a4fcdce4b1a7a418e36de2ddc4d2c3acfc69 |
|
11-Mar-2011 |
Christopher Tate <ctate@google.com> |
Broaden the filter for wallpaper restore
Tweak the filter parameters so that we now use any restored wallpaper image
that is larger than our ideal size, and will reject any smaller images only
if they are *much* smaller than our ideal size. The specific threshold used
here will just barely reject Nexus One or Droid sized wallpapers for restore
onto a Xoom, but will pass anything larger.
Bug 4070129
Change-Id: I889bdb3ef5011343b2fccb2f81c6abc2f4603ee2
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 7f765cf588e37a70fa2a1d251aaa8e7b847801b6 |
|
01-Mar-2011 |
Christopher Tate <ctate@google.com> |
Make sure to properly default the screen size during wallpaper restore
The wallpaper service claims a desired width/height of (-1,-1) during
initial setup, so look to the default display's metrics if necessary.
Change-Id: I341f12fb7b0b9d6b7761c277f23fc68fa5355256
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 00724cacc8292900c3be8657ea9b3b6284cf4877 |
|
17-Feb-2011 |
Christopher Tate <ctate@google.com> |
Turn on wallpaper restore debug logs
For investigation of bug 3462173 et alia
Change-Id: Id5f82a97c72d2a02f9a878029782fa698c5b124f
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|
| 3f64f8d8fc05189777e83b4efd3882cbc661fdeb |
|
11-Dec-2010 |
Christopher Tate <ctate@google.com> |
Don't restore wildly wrong sized wallpapers
If the dimensions of the original are sufficiently different from the
device's preferred dimensions, just don't restore the image. This
avoids bad letterboxing / clipping on e.g. phone <-> tablet data
migration.
The expansion/shrinkage ratios used here allow restores of saved
wallpaper images among HVGA devices, among WVGA variants, and
among tablets; but skip restoring wallpapers across those
categories (where severe clipping or letterboxing would occur).
Bug 3261863
Change-Id: I75e75d6401d18f1df10d75796ee04e21d2302cfa
/frameworks/base/core/java/android/app/backup/WallpaperBackupHelper.java
|