The canonical response is that, if an app were to suddenly find itself on a differently-sized screen, the app's UI would (should!) adapt to the new display boundaries by stretching (or compressing) each UI element in zero, one, or two dimensions.
This is because of how layouting is managed similar to the "
box model" from html/css; every UI element is contained within a rectangle that is anchored in some way in relation to its surroundings, and furthermore may have a fixed size or may be allowed to expand to fill whatever room it is given. You see how this should quite automatically scale the UI to make the best use of the actual screen real estate.
The only real problems would be for custom-drawn UI elements. Buttons with icons and similar graphics should be okay up to a certain point as long as they use the neat
nine-patch stretchable images (but only up to a certain point, eventually you will end up with an unreasonably tiny icon on a huge button). The real concern would be for games because they are fundamentally hand-drawn and can exhibit flaky scaling behaviour. Obviously, at some point you'd also expect the UI to change, for instance by showing more of everything -- three menu buttons plus a "more" submenu would seem daft on a screen that could easily support 20 buttons side by side.
On a side note, and a complicating matter, is that you're not supposed to think in actual "pixels". They've come up with the term "DIP", for
device-independent pixel, which I guess is supposed to be similar to an "
em" in html-speak, and which basically intends to work on a perceived relative size and becomes all the more confusing with non-uniform displays such as the Nexus One's
PenTile matrix.