When designing an UI, we need to target many android mutations and various screen resolutions.
If you build your views using "dp" it would, basically, be the same size for eack screen size.
In most cases you will prefer that your view will resize itself proportional to the screen size.
Of course, in most cases you will need to build separate layouts for tablets.
But, besides I can recommend you to do the next steps:
1. Add this library to your project.
2. Now in your layout you can write views like that:
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="I'm scalable!"
android:textSize="@dimen/_12sdp"/>
In this example your TextView will scale on each screen size.
I would suggest as much as possible use Relative calculations rather than Absolute. Avoid Hard coding of numbers for padding, margins etc. Simply give them a value in relation to desired property like Width, height of screen or any component.
I think the answer to this has changed recently, but I'll go over historical solutions.
Pre-Honeycomb, the solution was to create a dynamic layout that could adjust itself to the size of the screen (using 9-patches, dips, layouts that expand/shrink, etc.). This meant that none of your Views could be "pixel perfect", but you could adjust to different aspect ratios that you encounter. Sometimes you would come up with different layouts for landscape and portrait, but beyond that customization wasn't necessary.
With the release of Honeycomb, the problem got a lot more complex. Now you've got dramatically different screen sizes, where your app stretching doesn't look good at all. You've got tablets that stretch from 7" to 10" - which one is "large" vs. "xlarge"? 3.0 and 3.1 were an awkward period, where you had to detect the API version/screen size and configure your app accordingly (supposing your app supports both phones and tablets).
However, everything's changed in 3.2 and beyond. Now, the best practice can be described thus: think like a web designer, not an Android designer. Instead of thinking about phone vs. tablet vs. landscape vs. portrait layouts, think instead of layouts that work on particular screen sizes.
This thought process is detailed by this blog post, and these slides, but I think it's best demonstrated by going to some sample web pages and seeing it in action. Try visiting this page (or this page, or this page) and changing the size of your browser. Notice how they dynamically change layout based on the width - this is what you want in Android as well.
So now you've got a layout that works between screen width 150dp and 400dp; another one that works between 401dp and 800dp; a third that handles 800dp and 1000dp, etc. This way of thinking does not end up with you, as a developer, doing too much more work than before - instead of defining a phone layout, a tablet layout (each with a portrait/landscape layout), you just define a few layouts that work with different widths.
Right now we're in an awkward transitional stage as most people don't have devices that support this practice. So "best practice" is essentially all of the above. In a few years, when everyone's got ICS and beyond, then we can all breath a sigh of relief.
(I apologize if you were looking for specific solutions; this answer ended up being relatively theoretical rather than having concrete answers, mostly because I felt the question was pretty open-ended. If you've got a specific problem you want to solve, I can try to address that elsewhere.)
These are some suggestions, in random order:
In conclusion I recommend you to create a layout for phones and on for tablets, that can adjust itself to screen resolution: this will fit the most devices; for borderline devices (i.e. 7" tablets or 5.3" phone) I'd work with different drawables/different XML layouts.