bonk live wallpaper source code walk-through


This is a a brief walkthrough of the various objects which comprise the Android bonk live wallpaper along with some general observations and constraints that drove this particular design and implementation.

Live wallpapers are pretty easy to write. However, they're different than plain old apps in that:

Therefore just keep these following simple rules in mind when you write your wallpaper:
  1. Don't use any memory.
  2. Don't consume any CPU cycles.
  3. Don't use any threads.
and you should be fine. (Oh, I forgot one: Stay away from the NDK. You probably really don't need to use it anyway. I know it's tempting, but this will open up a whole world of underlying architecture, compiler, platform, and support concerns that you don't really need to think about. Unless you're doing some actual real-time work like controlling a phased-array radar, stick with the Java SDK.)

The package consists of two parts:

The Wallpaper Service

The wallpaper service is implemented in these Java files:

(...more coming soon...)

The Settings Activity

The settings activity allows users to communicate (via SharedPreferences) with the wallpaper service and implements choosing various boolean flags (like whether to display circles, turn sound on/off, &cet), choosing a background picture (via an Android Intent), choosing colors, and choosing a collision sound (via Android Intent). When the app runs, and a user modifies a preference, BonkWallpaper.BonkEngine.onSharedPreferenceChanged() is called to process the change within the running wallpaper service. The settings activity is implemented in these files:

(...more coming soon...)


All the utility routines are static (and used mostly for teasing data from the media content provider database), and they're in:

The SharedPreferences which refer to sounds or pictures are stored as strings, so we need a way to convert them from their string value (usually either URIs or URLs) to device filenames or bitmaps. The methods in here are all static, and they serve to do that conversion by means of Android's content providers. Given a URI of some picture-file-or-other, return a bitmap of the picture...stuff like that.

oh! that reminds me... There's a problem I ran into when using the camera to form a background bitmap. The cameras on many of these devices tend to make big pictures. Way bigger pictures than the screen can display. Say we have a 5 megapixel camera on a device whose display is FWVGA (480x850)... which is kindof typical. Then if we consider that we have one byte each of red, green, blue, and alpha, we could end up with a 20 megabyte camera-generated bitmap that only needs to go into a 1.5 megabyte screen buffer. If we try to read the picture from a file we could easily end up running out of memory (remember the rule: "Don't use any memory"). BonkUtil.imageFilePathToBitmap() tries to go round this problem by first finding the smallest bitmap that's still a multiple of 2 and that's bigger than or equal to the screen resolution. Once it does that it reads the picture data using inSampleSize to limit the input size. That's prettymuch the only thing that happens in this file which is not exactly straightforward.

(bonk wallpaper page: