MOTODEV Blog

[#1]

Since Android 1.6, there has been a simple, and mostly effective, classification of different screen sizes and screen resolutions.  The basic approach has been to clump similar sizes together, creating just 3 or 4 different categories that developers can handle individually with custom code, using the resources framework.  As the screen sizes and resolutions continue to grow more diverse, this approach has become too imprecise.  This blog post reviews the new paradigm, and provides links to more information.

The Way We Were

This table summarizes the "screen size" categories up to Android 3.1

	Android name	approx. size	comment
	small	2" - 3.5"
diagonal screen size	normal	3" - 4.5"	this is the baseline size
	large	4.1" - 7"
	xlarge	7" - 10.5"	introduced in Android 2.3 to anticipate tablets

This table summarizes the current "screen resolution (dpi)" categories:

	Android name	approx. resolution	comment
	ldpi	~120 dpi
screen resolution	mdpi	~160 dpi	this is the baseline density
	tvdpi	~213 dpi	this is for tv screens.  Added in API Level 13
	hdpi	~240 dpi
	xhdpi	~320 dpi	added in API Level 8
	nodpi	n/a	resources for images that should not be scaled on different density screens

You create your app, writing layouts and image resources customized for the different combinations of screen size and resolution.  You use the Android names as part of the pathname in the resource folder.  At runtime, when running on a large screen, the framework looks for a layout file in res/layout-large/foo.xml.   If you want a slightly different layout when running on normal screen with a high dpi, you put that layout file in res/layout-normal-hdpi/foo.xml

That was then, this is now

That was the way it was from the start with Android.  But Android 3.2 (API level 13) introduces a better approach to categorizing screen size and density.  It starts with an observation:  everyone is used to vertical scrolling, so (beyond an acceptable minimum size) screen height scarcely matters.  It is screen width that determines the layout of your app. 

The Android framework now provides, and can process, three screen-related metrics.  All metrics are expressed in dips (density independent pixels - you need to understand that concept before reading on).  DIP measurements let the system draw Views (buttons, text fields, progress bars, and so on) at pretty much the same size on each device, regardless of actual screen density.  The three screen metrics are

• current width of screen in dips (changes when orientation changes)
• current height of screen in dips (changes when orientation changes)
• least width that the screen will have (width in portrait mode in dips - a constant)

To convert to DIPS

You can convert from physical dpi on a device, to density independent pixels by multiplying.  This table shows the scaling factors

	Android name	approx. resolution	multiply by this scaling factor, to get dips
	ldpi	~120 dpi	1.333
screen resolution	mdpi	~160 dpi	1.0 (this is the baseline density)
	tvdpi	~213 dpi	0.751
	hdpi	~240 dpi	0.67
	xhdpi	~320 dpi	0.5

Use the dip size in resource paths

You now use the "current width", "current height", and "least width" (all converted to dips) in resource pathnames.  The three metrics (known as "resource selectors") are abbreviated to "w", "h", and "sw" respectively.  ("sw" stands for "smallest width" - the googleheads are just not good at choosing names that are both meaningful and grammatical).

Here are some examples.

1.  You have a screen that you can layout with multiple fragments, when the width is at least 600 dp

res/layout/main_activity.xml          # Single-pane
res/layout-w600dp/main_activity.xml   # Multi-fragment if wide enough (at least 600 dp wide, currently)

The "w" means "current width", and the "600dp" says "you must have at least 600dip to use this layout".

2. You can chain the resource selectors together.  They must all be true, for that resource to be chosen.

res/layout/main_activity.xml                 # For phones
res/layout-sw600dp/main_activity.xml         # Tablets
res/layout-sw600dp-w720dp/main_activity.xml  # Large width

The default layout is in res/layout/main_activity.xml

If the screen is at least 600 dip wide, the other two selectors will be considered instead.

If the screen is at least 600 dip wide, and the current width is at least 720dip,

the layout is in res/layout-sw600dp-w720dp/main_activity.xml

Otherwise the layout used is res/layout-sw600dp/main_activity.xml.

The old "size" buckets (small, normal, etc) are now deprecated, and everyone should switch to this new approach, going forward.  

Conclusion

The new approach to dealing with screen size is a significant improvement.  It removes uncertainty, and lets you specify down to the pixel.  There's little excuse now for apps that don't look good and work on every size of screen from smallest to largest.

There are more details, but this blog post summarizes the key aspects of the change.  Please read the references below to fill out your understanding, and get all the details.  Happy coding!

References:

1.  http://android-developers.blogspot.com/2011/07/new-tools-for-managing-screen-sizes.html

2.  http://developer.android.com/guide/practices/screens_support.html#NewQualifiers

3.  http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources

Peter van der Linden

Android Technology Evangelist