It's a good start, but it doesn't consider device diversity even within an identical version number of Android. Is may not be a factor for simple apps, but trust me, if you are doing things that interface with the underlying hardware it's a big problem. Apps that do things with Bluetooth and capturing audio, for example, really expose the fragmentation. I know some folks building something that records and plays audio over the Bluetooth SCO channel and even though they have standardized on Gingerbread, they still have to test every model from the major manufacturers due to different firmware builds.
Audio recording support on Android is pathetic. The APIs only have one error code - roughly corresponding to "it didn't work" without further clue as to what the problem is.
I also found that often the driver or hardware on HTC and Motorola devices would get wedged. You could only fix it by a reboot. (They were probably using the same Qualcomm chipset.)
Of course once it got wedged users couldn't actually tell. Any audio recording program (eg Google's voice search) would say it had started recording and then immediately stop saying "error". Because of the lack of useful error codes they had no idea why and usually didn't expect the error anyway giving a horrendous user experience (untested code paths).
You also can't practically record audio when using the emulator, and in any event it behaves differently than real hardware, so you have to development and testing with a variety of real devices.
