...rather than overwriting the existing wallpaper bitmap file "in
place." If the new bitmap is smaller than the previous one, we wind
up with the previous image's contents as spurious trailing file
contents. Also, it means that if any wallpaper image is particularly
large on disk, then we'll forever be backing up that high-water-mark
amount of data every time the wallpaper is changed.
The fix is to open the "write the new bitmap to disk" fd with
MODE_TRUNCATE.
Bug 17285333
Change-Id: I3d8708d72e316834b7ecec20386153a703efddd9
90f86baebd