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
|