Develop Reference

How do you find out/calculate which w<N>, h<N> or sw<N> a phone uses and which steps to use?

I am working on optimising layouts for multiple screens, and I'm stuck on how to define the different dimens files. So, it says on android developer that you should use sw<N>, w<N> or h<N>, but how can I find out in advance which one a given phone will use?
I have an Sony LT26i, which has screen resolution 720 x 1280, and it uses (by trial and error) the qualifiers w<360> and h<615>. I'm not entirely sure, but I would guess that 360 is backwards calculation of the px formula, i.e. px = dp * (dpi / 160) (360 = 720 * 160 / 320, where 320 is the DensityDpi as per the DisplayMetrics class). However, when I apply the same logic to the width, I get 640, so why does my phone use 615 (which corresponds to a dpi value of 333.00813)? Or do width and height have different dpis?
For optimising, how do I choose what steps to define my dimens files? I'm considering basing my calculations on my own phone(s) pixel values, create steps based on given screen densities using the px formula (above) and just scale the values based on the ratios given (i.e. from ldpi to xxxhdpi .75:2:3:4:6:8), possibly adjusting individual values depending on how things progress. Is there a better way?
Are there recommendations for specific configurations of AVDs and dimens to test the app on?

Android alternatives resources for 5.5'' and 6'' phones

I would like to know how can I add alternative resource for android devices with 5.5'' and 6' within a project structure.
I want to add a custom dimens.xml file with different text sizes for devices between 5.5 and 6 inches.
I was thinking to use the small width configuration qualifiers but there is so many screen configuration that I do not know which screen size would be the smallest width for 5.5'' and 6'' phones. The other alternative that I can use is the screen size buckets (small, normal, large, xlager) but those are deprecative from android 3.2 and above.
Can someone advice me about this?.

I appreciate your advice, but look this example.
I have this phone:
- Nexus 5x with 5.2’’ resolution 1080x1920 px, 420dpi
dp = px / (dpi / 160)
dp = 1080 px / (420 dpi / 160)
dp = 411 dp
Nexus 6p with 5.7 resolution 1440x2560 px, 560dpi
dp = px / (dpi / 160)
dp = 1440 px / (560 dpi / 160)
dp = 411 dp
if I create a specific set of resources just for the Nexus 6p with 5.7’’, or for devices with just 5.7’’ I could crate this folder
values-sw411dp
But all the resources within that folder will be used when the app is used on both devices 5.2’’ and 5.7’’.
I have other problem, it may be that smallest phones like, 5.0’’ could have biggest dp than the 5.7’’, what its going to happen is that the resources for the 5.7’’ device it will be used for the 5.0’’ devices too.
How can I specify resource just for 5.7’’ phones.

Well, you are right I'd also go with the smallest-width buckets.
You can calculate the smallest width, by checking the phones dimensions in dp, with the formula given in the official documentation:
px = dp * (dpi / 160)
So to get the smallest width dp:
dp = px / (dpi / 160)
Where px is the pixels on the smaller dimension, dpi is the dot per inch ratio of the device.
So first check the devices' pixel size and dpi value, then calculate the dp value with the formula above. Then you can create the folder with the resources like sw400dp where you can change to the calculated dp.
Also I'd suggest to check for other device dimensions to not have weird layouts on smaller / larger screens.

Abbath, thank you very mucho keep answering my questions. I am not working with images, I am working with the text size of a TextView. I need to change the textView text size, only if the devices screen size is bigger than 5.5''. I created a /value-sw411dp/dimens.xml which contain the corresponding textview text size. I found that sw411dp is the smallest dp width of the 5.5'' devices, but there is an other phone that has 5.2'' that has the same screen spaces. So, the system will used the resources within the /values-sw411dp/ for devices with 5.5''and 5.2''.
What you where telling me is that if a 5.2'' has the same screen dp as a 5.5'', I shouldn't worried about that because at the end the UI layout will look the same without problems.

Android baseline dpi does not help calculate screen percentage

If a layout has android:layout_width="160dp" it renders half the screen on the hdpi Nexus S emulator.
I was expecting the Nexus 4 emulator (xhdpi) and the Nexus 5 emulator (xxhdpi) to scale accordingly, and show me a layout that's taking up half the screen, but they did not. They were a bit less than half (2/5 ish).
What am I missing? I thought that the XML environment always uses a specific screen, so I can base my calculations from there.
If 320dp = 480px / (240dpi / 160) and the Nexus S is hdpi (high) ~240dpi. Makes sense that it's 160dp is half the screen.
Then, the Nexus 5 is xxhdpi (extra-extra-high) ~480dpi with an HD resolution.
So, 1080px / (480dpi / 160) = 360dp!
What? Why?!
Should I avoid using dp when I want to divide my screen assets? Rely on weight and grid?

Indeed, as Budius commented, you cannot rely on dp to divide your screen into segments, since it only helps create a relative understanding of the size so that it reduces the amounts of calculated re-sizing you need to do, but does not effectively replace all unit sizes, such as what a raw percentage would do.
Using weights is the way to go.

Understanding Samsung Galaxy Tab screen density

One would say that if the Galaxy Tab screen resolution (in portrait mode) is 600px and the screen width is 3.55inch, the screen density would be 600/3.55 = 169 dpi. Knowing that and keeping in mind the way the device independent pixels (dp) is computed (http://developer.android.com/guide/practices/screens_support.html):
px = dp * (dpi / 160);
600 = dp * (169 / 160);
dip = 568
So drawing a horizontal line of 568dp (device independent pixels) width starting at position 0 must exactly match the width of the screen. But if you try this on device you will find that the screen width is 400dp. I will use the same formula again but for getting dpi:
600 = 400 * (dpi / 160);
dpi = 240
So having the 240dpi, 3.55inch screen width and 600pixels, does it mean that one physical pixel is composed of more ‘dots’ otherwise the parameters corresponds to the width of 852pixel (3.55*240).
I thought that dpi means dots per inch, which is pixels per inch. But this seems to not be true...
Added later:
This (http://developer.android.com/guide/topics/resources/more-resources.html#Dimension) says:
160dp is always one inch regardless of the screen density
Which is not true. Just check the measurement source from this:
Difference between android dimension: pt and dp
Added even later:
The reason I am asking is that violating the rule that 160dp = 1inch leads to the fact that when specifying the control width to e.g. 320dp it will cover on Galaxy Tab much bigger portion that that really necessary and much bigger then what you would expect from 600x1024px screen...
Thanks for clarification
BR
STeN

Galaxy Tab (7") doesn't report its real density. To understand this issue, read the following article:
http://realmike.org/blog/2010/12/21/multiple-screen-sizes-with-processing-for-android/
Apparently, that’s also what Samsung found when they made the Galaxy
Tab. The Galaxy Tab has a 7″, 1024×600 screen with 170 dpi. Yet, the
Tab does not report its density as “mdpi” but as “hdpi”, so the layout
looks exactly as in the second screenshot. If they used “mdpi”, the
icons would be .28″ wide, with “hdpi”, they are .42″ wide—not a big
deal, and I must admit, the layout does look prettier this way.
The article contains some images that will make you understand the problem.

basics of device-independent-pixels

im throughoutly confused by dips on Android.
I understand from the reference that the base for dp values is 160.
So, shouldn't 80dp in width equals a view with a width of 50% of the screen ?
On my Nexus One the width in dp is something around 300dp as it seems.
What am i missing here ?
thx in advance

"dp" == "Density-independent Pixels" (This is also why it was earlier called "dip", though I prefer to use "dp" these days.)
Think of it like other units -- "in" (inches), "mm" (millimeters), etc. It allows you to provide a size that is scaled based on the density of the screen.
We define mdpi to be the base density, so "10dp" on an mdpi screen will result in exactly 10 pixels. On an hdpi screen it will result in 15 pixels, because hdpi is 1.5*mdpi.
Note that though the constants for various densities are similar to DPI (mdpi is 160, etc), density is not exactly DPI. It is an abstract scaling factor that adjusts for screen dpi, but does not try to exactly reflect it. (You would use "in", "mm", etc for exact sizes but 99.9% that is not what you want so stick with "dp".) This greatly simplifies life for everyone because you don't need to deal with many Android devices having a slightly different amount of space for its UI because they each of slight different screen DPIs. Also, device manufacturers can select the density of their device to achieve a desired UI -- for example the Samsung Tab uses a density that is a fair amount larger than the actual DPI, resulting in an overall larger UI.

160 dots per inch. So 80dp would be 1/2 an inch, roughly.

I don't understand your question completely but I suggest you take a look at this, if you haven't already.
http://developer.android.com/guide/practices/screens_support.html
pixels = dps * (density / 160)

Density independent pixels (short: dp) are a virtual pixel unit that will be determined at the runtime of your application.
Formala:
1 dp = 1 Pixel on 160 dpi screen.
So 160 dpi is the baseline density for the system.
The conversion of dp units to screen pixels are quite simple.
Actual device pixels (px) = dp (1) * (dpi (of the device) / 160(baseline) )
For the sake of simplicity: px = dp * (dpi / 160)
Example:
If a 240 dpi device starts your app, then 1 dp equals to 1,5 actual device pixels.
Conclusion:
Dp automatically handles any scaling to bigger or smaller devices. The times where you hardcode the pixels are over. DP ensures the proper scaling on different screen densities.