Changes to screen size/resolution categories

by Peter_vdL Motorola on 09-02-2011 07:40 AM - last edited on 09-02-2011 12:23 PM by Nicole Mcmorran (nmcmorran) Motorola

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
/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
/layout-sw600dp/main_activity.xml         # Tablets
/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.  


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!









Peter van der Linden

Android Technology Evangelist 

Post a Comment
Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
reCAPTCHA challenge image
Type the characters you see in the picture above.Type the words you hear.
About MOTODEV Blog
The MOTODEV blog keeps you updated on mobile app development news from MOTODEV and the Android developer community.

Subscribe to our RSS feed Subscribe via RSS

Follow Us:
Fan MOTODEV on Facebook Join the MOTODEV LinkedIn Group MOTODEV on YouTube

motodev profile

motodev Do u have questions about the Google+ Hangout happening right now? Go to Google Moderator and ask a way: 7 days ago · reply · retweet · favorite

motodev profile

motodev Use Schema Builder to build out your data model. Find out more at our Google+ Hangout now: #l2cloud 7 days ago · reply · retweet · favorite

motodev profile

motodev It's not too late to join our Google+ Hangout: Migrating your Legacy Systems to the Cloud & Mobile: #l2cloud 7 days ago · reply · retweet · favorite

Our Blog & Comment Policy
Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Motorola. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Motorola or any other party.

Remember, when you comment, please stay on topic and avoid spam, profanity, and anything else that violates our user guidelines. All comments require approval by Motorola and can be rejected for any reason.

For customer support issues with your Motorola phone go to the Motorola customer support website.