This is an interesting point. Couldn't the OS give access to the pixel data without access to the EXIF data? i.e. doesn't need to give direct access to the image file, just convert it first to strip the metadata.

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.

It could, but there's other benefits as well of decoupling wallpaper rendering from the launcher - it allows you to switch the launcher without having to beg the developer (OEM nowadays) to support your preferred (live) wallpaper. It gives you freedom to choose while preventing what the OP is ranting about - the launcher developer deciding for you what's best for you.

> the launcher developer deciding for you what's best for you.

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.

of coure the OS could that.

Why not also provide a way to deny all network access to the app? Then there’s nothing it can do with any data of gets.

This is how third party keyboards work on iOS. No network access by default, but the user can go into settings and grant network permission if they judge it fit to.

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.

Honestly it should be how all apps work. I hate that I can’t deny Internet access to any app.

I'm so glad that the only entity with access to this data is Google and that open source launchers can't... render an image