summaryrefslogtreecommitdiff
path: root/docs/html/sdk/api_diff/13/changes
diff options
context:
space:
mode:
authorDianne Hackborn <hackbod@google.com>2012-11-01 16:28:16 -0700
committerDianne Hackborn <hackbod@google.com>2012-11-02 14:19:59 -0700
commit98129739afcb3786a6ec9f3efe774d8e01f6d632 (patch)
tree7e38ec6db6862e3b1f0e4557361fec2e09ac6d8c /docs/html/sdk/api_diff/13/changes
parent7ab7f538924371a9dd4be7a27a6ae3b4c04b301c (diff)
Fix issue #7343200: Fails to show wallpaper in the background for...
...lockscreen sometimes and remains black / blank The problem was that we were using the animation-side wallpaper state in cases where it was not updated yet. The mWallpaperTarget variable is propagated over to the animation side when the main window manager state updates. On the animation side, this is used by hideWallpapersLocked() to determine if the current wallpaper should be hidden. The problem is that various paths to hideWallpapersLocked() can come from the layout side of the window manager instead of the animation side. This causes the problem here because in this case the wallpaper state may not have yet been propagated to the animation side, so it could incorrectly decide to hide the wallpaper because it thinks there is not a target when in fact a target is set in the layout side. This won't get fixed until some time way later that the layout side decides that a new window is being shown that may need to have the wallpaper shown. The fix here is pretty gross, but as safe as possible -- the hideWallpapersLocked() function now uses either the animation or layout wallpaper state depending on where the call to it is coming from. Change-Id: I9250bfeae6e11c1761760bcc696fdb33fb5c8a5f
Diffstat (limited to 'docs/html/sdk/api_diff/13/changes')
0 files changed, 0 insertions, 0 deletions