For instance, the Motorola Droid is as wide as the G1, but has more height.
Should I try to spread the UI out across the extra height found on the Motorola Droid? How do others handle this problem?
I'm not using OpenGL, but a SurfaceView for a 2D game.
Be aware of density independence (basically resolution) as described here: http://developer.android.com/guide/practices/screens_support.html
And as related to aspect ratio, pick your minimal target aspect ratio and design within it as sort of a safe frame. When confrontend with wider aspect ratio, show more of the game which is not critical to gameplay. I have posted a similar question here and described what I'd do: How do you approach resolution independence in raster based graphics content?
You can do the dynamic resolution which I show here on the iphone:
http://www.blog.namar0x0309.com/2011/10/adaptive-resolution/
Make sure you place everything with ratios. For example a health bar would be placed at 80% of the screen width with 10% of the screen width for its horizontal scale (refer to CSS styling dimensions). It's a little weird in the beginning but you won't have to deal with all the different resolutions in the long run as your widgets/images will move dynamically with different screens.
If your game uses picking translate that too with ratios (you need an original set dimension which you can use as reference to build ratios with the device dimensions.
If you are using eclipse, you can have several different sized images put into the drawable-ldpi, drawable-mdpi, and drawable-hdpi and the android engine will automatically choose which image will be appropriate for the screen resolution.
Keyframe mentions a good approach, but I'll offer two more:
1) Design your game for multiple resolutions/aspect ratios. The idea is to take advantage of every bit of the screen real estate, but "design out" any advantages that one aspect ratio might have over another. Depending a lot on the game, different aspect ratios may still have an advantage over others, so you'll want to keep that in mind for things like multiplayer matchmaking, leaderboards, achievements, etc. if any of these are relevant.
2) Use the extra space for more HUD / chroming. Pretty much what Keyframe said as far as having a baseline or minimum resolution supported, but instead use the extra space for something other than the game action.
The big disadvantage with the second approach is that if you take something very square-ish as your "safe zone," you leave a lot of unused / unintentionally used pixels in a widescreen setup.
Chosing the optimal resolution for a game from the start of development can reduce headaches with porting later on.
The "best" resolution depends on a lot of factors:
-The platform the game is supposed to be released on first
-Other possible platforms you plan to port to later
-Graphical fidelity (An 8-bit or pixel art game doesn't need to be hi-res.)
-Genre (A puzzle-game can probably get away with a lower resolution, but a high-speed competitive FPS might not.)
