This is limiting and completely rules out implementing effects like blurs or a Liquid Glass lookalike unless you want to make the user set the wallpaper in the launcher separately. Totally killed my motivation to build further.
This is limiting and completely rules out implementing effects like blurs or a Liquid Glass lookalike unless you want to make the user set the wallpaper in the launcher separately. Totally killed my motivation to build further.
That still gives you the image data which might be private, but we should be able to lock that behind a permission dialog "Allow access to current desktop background image" or whatever. It's a weird and very specific permission but it might be worth having.
I don’t understand how I would be deciding what’s best for users?
The only reason why third party launchers wouldn’t support live wallpapers is if Google didn’t give devs the tools to render them. All they’d need to do is include a WallpaperView the dev can add to their view hierarchy that supports live wallpapers. Boom, the dev can do fancy effects and the user loses nothing.
I think this model would make a lot of sense for Android launchers, too, given how they continually run and potentially have access to much more user data than is typical.
Still has some limits, though, like inability to blur specific parts of the image (e.g. under a box) and apparently the Android skin that ships with some devices disables that window blurring feature, in which case it won’t work. Better than nothing but still restricts the scope of what’s possible quite a lot.
My guess is, this might have to do with fixed layers in the Hardware Composer HAL, which offloads compositing that otherwise (I guess) Surface Flinger would need GPU/CPU for.