Develop Reference

How to determine android device resolution is small, medium, or large

I am working on a Xamarin.Forms app and I need to identify the android screen/resolution is whether small, medium or large to adjust some content with the available space. For example, some labels (single line) are getting truncated in smaller devices. So I could make some adjustments if the resolution is smaller or not.
In iOS, when iPhone screen getting bigger, the resolution is also getting increased so it's easy to identify smaller resolution devices in iOS. But in android, this seems hard.
Android device resolution can be taken from
var resolutionH = Resources.DisplayMetrics.HeightPixels;
var resolutionW = Resources.DisplayMetrics.WidthPixels;
For testing, I have created the following emulators and run the app in them. Here's my result whether a label getting truncated or not.
Resolution Density Result
---------------------------
2560x1440 560 OK
1920x1080 400 OK
1280x720 320 Truncated
1280x720 280 OK
1280x720 240 OK
800x480 240 Truncated
800x480 160 OK
The problem here is a device with higher resolution and lower DPI won't cause any problem. Like a device with 1280x720 resolution and 240 DPI (or 280 DPI). Since there are tons of Android devices are available with different resolutions and densities this problem seems harder.
Is there a better way to categorized android devices (small, medium, and large)?

The reason where a label's text getting truncated (in my case) or an element doesn't get enough space in a particular device is, the actual pixel calculation for an element using the density (dpi/ppi) and the density bucket that screen falls into. This article gives a good idea about calculating the physical size of an element for different display densities.
After some exhausting research, I was able to categorize the device screen by taking the combination of screen width pixels and density. (I got the data from Android developer website Distribution dashboard and Support different screen sizes)
I have categorized the screen width pixels into 4 categories and then calculated the screen size for each display density using following formula:
sqrt((widthPixels x widthPixels) + (heightPixels x heightPixels)) / density
Then I have searched in the GSMArena to find devices with the screen configurations in the above table. Screen size lower than 3 inches is mostly smartwatches and more than 8 inches could be Tabs and smart TVs. So I have taken devices with the screen size between 3 - 8 inches as mobile devices (smartphones).

What you are looking for is easy to do in native android you can create a method and check for the DensityMetricsDensity something like below:
private string GetDeviceDensity()
{
var density = Resources.DisplayMetrics.DensityDpi;
switch (density)
{
case DisplayMetricsDensity.Medium:
return "MDPI";
case DisplayMetricsDensity.High:
return "HDPI";
case DisplayMetricsDensity.Low:
return "LDPI";
case DisplayMetricsDensity.Xhigh:
return "XHDPI";
case DisplayMetricsDensity.Tv:
return "TV";
case DisplayMetricsDensity.Xxhigh:
return "XXHDPI";
case DisplayMetricsDensity.Xxxhigh:
return "XXXHDPI";
default:
return "Unknown";
}
}

Using different screen layouts

I have an app with different versions for screens (small, normal, largue, and extraLargue XML files) each with its XML designed for each type, but I found a Huawei phone with this screen 3.5" HVGA 320x480.
My question is, should not the UI of Android use the small configuration for this screen? Is that the app when running on this phone uses the normal configuration as if it were a nexus4 4.7" 768x1280 as I change that?
I tried to create various types of screen (create other) with multiple configurations without optimal result.

Assuming the 3.5" measurement is on the diagonal, this works out to about 165 dpi which falls into the mdpi (or normal screen size) bucket according to Android's Supporting Multiple Screens guide.
DPI = sqrt(w^2 + h^2) / d
where
w is the width of the display in pixels
h is the height of the display in pixels
d is the physical diagonal measurement of the display in inches

It is quite simple.
You need to add different UI and make controls VISIBILE and GONE.
int appScreen = getResources().getConfiguration().screenLayout &
Configuration.SCREENLAYOUT_SIZE_MASK;
switch(appScreen) {
case Configuration.SCREENLAYOUT_SIZE_LARGE:
UIControl.setVisibility(View.GONE);
break;
case Configuration.SCREENLAYOUT_SIZE_NORMAL:
UIControl.setVisibility(View.GONE);
break;
case Configuration.SCREENLAYOUT_SIZE_SMALL:
UIControl.setVisibility(View.GONE);
break;
default:
UIControl.setVisibility(View.GONE);
}

Creating a new sw<xxx>dp qualifier

I have the qualifiers for 7 inch tablets and 10 inch tablets, sw600dp and sw720dp respectively. I don't understand how those numbers were reached.
I would like to create a new layout for phones which a smaller screen size than 4 inches. Please could you explain how I should do this using the smallest width qualifier.

Please checkout "Configuration example" section of official documentation first. It explains very well what is used and when. In your case default layout folder without a qualifier is used for handsets.
What is smallest width qualifier? Smallest width is
The fundamental size of a screen, as indicated by the shortest
dimension of the available screen area. Specifically, the device's
smallestWidth is the shortest of the screen's available height and
width (you may also think of it as the "smallest possible width" for
the screen).
For instance your have a phone with screen size equals to 480x800 dp. The smallest width for this device will be the smallest value of these two, which is 480dp. If you rotate your device, the smallest value will stay unchanged - 480dp.
How to use smallest width qualifier? When you create a layout you always expect a minimum width, with witch it swill looks good. Below this minimum your layout gets squeezed and doesn't look good. To make sure this doesn't happen to it, you put it to the folder with sw<N>dp qualifier, when N the minimal allowed width.
It's worth to mention that because smallest width doesn't depend on orientation, you should take case for handling landscape and portrait orientation by yourself by using land or port qualifiers. Although this approach works, it can become complicated to handle different widths and orientations very soon. To address this issue, there is another approach called responsive mobile design. I suggest to read a series of articles "Deep dive into responsive mobile design" to get better understanding.
Update:
The formula for calculating dp from px is like following:
dp = px / (ppi / 160dp)
Nexus 7 takes sw-600dp, because all calculations are based on getResources().getDisplayMetrics().density value coded in the device. This is not the real value, but a rounded value. For Nexus 7 (2013) the real value is 323/160 = 2.01875. The value coded in the device is 2, which corresponds sw-600dp. This is where some pixels get lost.

sw600dp means smallest screen width of density 600dp. But let me tell you that you need more than this because Nexus 7 (2012) and Nexus 7 (2013) are both 7inch tablets but with different densities. You can add hdpi or xhdpi with sw600dp like values-sw600dp-hdpi. For phones do the same swXXXdp but try not to do that and use screen-size like small, normal, large, and xlarge.
For reference see Android official link

Android Tablet Dimensions

We have just started Android Tablet development. I need to prototype for 7in and 10in tablets.
Is there any wireframe stencil i can get hold of ?
What are the dimensions of the canvas i need to start designing on ?

Just like phones, tablets have all sorts of dimensions and sizes.
Here is a quick list of different models with their respective sizes and dimensions:
Samsung Galaxy Tab 10.1 3G - 10.1 inches, 1280 x 800 pixels
Samsung P1000 Galaxy Tab - 7.0 inches, 600 x 1024 pixels
Dell Streak 7 - 7-inch 800×480
Motorola Xoom - 10.1-inch, 1280×800
Viewsonic G - 10.1-inchs 1024×600
These are the dimensions you'll find most often.

Rather than considering actual pixel dimensions (which can vary in size depending on pixel density), it might be easier to think in density independent pixels (dp). This is the smallest device width as given in the configuration examples from the docs:
7” tablet: 600dp
10” tablet: 720dp
Notes
For actual pixels size, multiply by 1 to get mdpi, multiple by 2 to get xhdpi, by 3 to get xxhdpi, etc. See here for more.
To provide different resources for the various screen sizes, see this answer.

Old topic but i think i've got a good way to resolve your probleme. If it can help some..
First of all, if you do right, All your activities should be composed ONLY with fragments.
You may know that when a screenSize is defined as exemple by 384* 640, that means your maxWidth is 384dp and your maxHeight is 640dp.
And so, it's easy to determine how height you should use without trying on emulator.
Still using my screenSize exemple : 384 (Widht) * 640 (Height) :
640dp
292dp
264dp '
<dimen name="max_height">640dp</dimen> <!-- screen maxHeight -->
<dimen name="half_height">292dp</dimen> <!-- ScreenMaxHeight with actionBar -->
<dimen name="half_height_bigactionbar">264dp</dimen> <!-- height without actionBar and its subActionBar -->
Down here, this is my fragment size :
<fragment
android:layout_width="match_parent"
android:layout_height="#dimen/half_height_bigactionbar"
Both of my fragmennts should now fill all the sreen
My action bar height is 56dp . If you do the map if i want he half of my screen i do ((maxScreenHeight) - (ToolBarSize) ) / 2.
I got ((640) - (56)) / 2 = 292dp !
Do the same for All of resolution you might know with all the window part you may use:
And you will have THE perfect match in every phone you know.
You can do the same math for width if you use tablet.
But remember, use as much as possible wrap_content + marginLeft and MarginRight to place your components !
When you wana create an activity. Draw it in a sheetwith small-paned . And think only with percent. Then do the math, and use ONLY fragments.
You should be fine then :). Ask if i wasn't clear enought !

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.