Question

It’s easy to find many articles discussing the implementation of Live Wallpapers for beginners, which addresses major questions involving Surfaces and so on.

But what about the professional development of Live Wallpapers? What are best practices for structuring the code the right way, to ensure good performance, low power consumption (to save battery power) and best fit different devices?

If possible, some code samples covering these issues would be great.

Answer 1

Power consumption…
1) The most important thing, by far, is that your wallpaper should switch itself off when it is not visible. The cube example handles this correctly, removing runnable callbacks in onDestroy(), onSurfaceDestroyed(), and onVisibilityChanged() (when visible == false).
2) Beyond that, the largest determinant of power drain will be your frame rate. A 24 fps animation will drain much more juice than a clock that just updates at 1 fps to make its sweep-second hand tick. There’s no way around this, except to educate the user, so that expectations are reasonable. An action game will kill your battery whether it’s an app or a live wallpaper.

Performance…
Drawing to a canvas has the benefit of simplicity, but for a very sophisticated wallpaper you will need to use OpenGL. There’s GLWallpaperService, and AndEngine. The stock wallpapers are rigged to use RenderScript (you may find it useful to look up this code within the Android source tree — much more sophisticated than the cube example in the SDK). And there was some talk about extending libGDX to handle wallpaper.

Best Fit…
Well, it’s just like the rest of Android: you need to design your artwork in terms of scalable proportions, query the device, and adjust accordingly. For a simple wallpaper, it’s usually enough to scale your artwork in onSurfaceChanged(), where you are given the width and the height as parameters. In some cases you may want to examine the full DisplayMetrics.