When we were designing Android, we knew we wanted the platform to be able to scale between different screen densities. This is why even in version 1.0 all layout dimensions needed to specify a unit and we introduced the concept of the "dp" unit (for "density-independent pixel") as the normal unit to use.
Much of the motivation for this came from experience at Palm / PalmSource. Palm device traditionally had a 160x160 screen. Later in their life, Sony introduced a 320x320 screen; this worked pretty well by just doubling the coordinates supplied by the application so (unless using new APIs) it still thought it was drawing on a 160x160 screen but the OS would convert those and take advantage of the higher-resolution screen to show sharper text and drawn shapes.
This strategy became problematic in PalmOS later however when they wanted to ship QVGA screens. These were cheaper to produce since they were used in many other devices; by putting the handwriting area at the bottom of the screen you could still have the expected square area for the app. However their density was half-way between 160x160 an 320x320, giving a scaling factor of 1.5, and here the problems appeared.
On PalmOS, applications built their interface by placing UI elements at absolute coordinates in the 160x160 screen space. When doubling to 320x320 this was not a problem, it just meant the UI layout could only be positioned on every other pixel. However at a 1.5x scaling, the original coordinates now alias to the screen resulting in visible artifacts.
Here is an example: if I have a UI with a row of four buttons going across the screen, with two pixels between each of them, the 1.5x scaling factor means the distance from one pixel to the next switches between 1 and 2 pixels on screen. So the consistent two pixel spacing of my buttons varies between 3 or 4 pixels on the actual screen just depending on where they happen to line up.
This was especially bad on PalmOS, where everything used integer coordinates and there was no anti-aliasing. Even if you have anti-aliasing everywhere it is a problem though -- your nice solid lines now get various gray smudges on them depending on how they align with the real screen pixels.
To solve this, in Android we have developers use dp units in layouts for specifying the spacing and widths of their UI elements, however we also have layout managers that are responsible for placing the final elements on screen. Once your layout is loaded, all "dp" units are converted to physical pixels, and the view hierarchy and layout managers run at whatever native density the screen is. So if you have a row of buttons with 2dp units between them, this spacing when scaled by 1.5 will always be 3 pixels on the screen. The layout manager will take care of doing the final fine-grained placement of UI elements so that they are consistent.
In theory then Android can scale to any density and show its UI to match the exact density of the screen. In practice we don't do this -- we have defined a handful of specific densities we support and require that compatible devices stick to them. Why is this?
The first reason is just to help our developers. UI designers tend to like to make nice clean graphics; these graphics are drawn as bitmaps, and giving designers a small set of target bitmap sizes to support instead of infinite variation makes things a lot simpler for them. Especially at lower densities, scaling the original bitmaps by a few percent up or down to exactly match the screen density is not going to bring much happiness. (You can argue here that the solution is to use vectors, but this brings a lot of its own problems and some significant overhead and limitations. Kirill has a great discussion on this topic at http://www.pushing-pixels.org/2011/11/04/about-those-vector-icons.html
which I highly recommend.)
Beyond dealing with graphics, arbitrary density support has other issues -- it means that each phone's screen is slightly smaller or larger than another, making it imperative that developers completely embrace layout managers and let go of the control they are used to over placement on screen. This is something we have been pushing developers to do, and as Androids grows to support a wider variety of devices it becomes more important, however forcing this on developers 4 years ago because devices were varying by .1 inch screen diagonals would have been a waste and just gratuitously cruel.
Beyond that, it is not clear this is actually what you want. If I buy device A with a 3.5" 320x480 screen and device B with a 3.6" 320x480 screen do I really expect the UI on the second device to have a different layout? In fact I probably don't, and the chances of there being any useful difference between them (will text even be able to go up a point size?) is low. More than that -- maybe if I am getting a device with a somewhat different screen, I actually find it attractive because the UI is larger and easier to see or smaller in my hand but still with everything shown I expect.
So Android defines a few major buckets of density values that devices can used, called ldpi (approx 120dpi), mdpi (160 dpi), hdpi (240 dpi), and xhdpi (320 dpi). Manufacturers can select the density that is appropriate for their device, as long as it results in a screen that (after scaling for density) is within the minimum allowed screen size of the platform. Because there tend to be some standard display sizes (320x480, 480x800, 540x960, 1024x600, 1280x720/800, etc) the layout spaces apps encounter tend to congregate around a handful of specific buckets themselves, even though the actual physical dimensions of device screens are all over the map.
This all came to my mind when Tim Bray recently posted about a cool web site (which unfortunately seems to be down right now) that lets you compare the actual sizes of different devices: https://plus.google.com/u/0/107606703558161507946/posts/LMKLpCnN3ah
I was very happy with how things came together for the development of the Galaxy Nexus, where we had a new screen density we had seen coming but never shipped a product on, and a new screen size and resolution that we had never explicitly considered supporting. Besides creating assets for that density and some cleanup of layouts, Android and its applications were able to pretty much run on it as-is.