How Mdpi, Hdpi, Xhdpi Folder Works

How mdpi, hdpi, xhdpi folder works?

You can create different graphic objects for use at different pixel densities. Android treats mdpi (160 pixels/inch) as the base density. So for mdpi devices, 1 dp = 1 pixel. At higher densities, there are more pixels per inch (240 for hdpi, 320 for xhdpi). Android attempts to make graphic images occupy the same physical dimensions on the screen regardless of the device pixel density. So if all it finds is an mdpi resource, and the device is hdpi, it will scale the graphic by 240/160 = 150%, and it will double the size of the graphic for xhdpi.

If you don't want this automatic scaling (which can make graphics look poor), you can simply supply your own version of graphic resources for use at higher densities. These graphics should be of the same size that Android would scale an mdpi resource.

Note that the pixels/inch that was stored in the image file has nothing to do with this. It's all based on where you put the graphics files in the resources directory for your project. Any graphics placed in res/drawable are assumed to be properly sized for mdpi displays, as are graphics placed in res/drawable-mdpi. Image files that it finds in res/drawable-hdpi are assumed to be properly sized for hdpi displays, etc. When your program runs on a particular device, Android will first look for a graphic that matches the display density of that device. If it does not find one but instead finds one for a different density, it will use that and automatically scale the image based on the above rules.

What's differences between 'drawable' folder and 'drawable-hdpi-ldpi-mdpi-xhdpi' folders?

res/drawable/ is equivalent to res/drawable-mdpi/. The suffix-less name is there for backwards compatibility, before the densities were added in Android 1.5 or thereabouts.

is enough to create suitable image size rate for all devices?

If you do not mind Android scaling your images up and down for other densities, yes. Usually, the quality will degrade the further the density is from the starting point (in this case, -mdpi.

Should I create image size rate for each folder(hdpi, mdpi, ldpi, xhdpi) ?

That depends on the image and the results of the automatic scaling. Many developers will ship a couple of densities, but not all of them, and tending to aim towards higher densities (e.g., -xhdpi). But, you are welcome to do what you want, so long as you feel that your users will be comfortable with the image quality that you deliver to them.

Android Drawable hdpi xhdpi mdpi ldpi concept

The folders without any qualifiers (layout, drawable, raw, values etc.) are the default folders. Android looks for each resource in them if it isn't found in the folders that qualify for that device. If you have a copy of any resource in them, you should never get a ResourceNotFound exception for that particular resource, unless the manufacturer introduces a bug into their ROM.

Image resolution for mdpi, hdpi, xhdpi and xxhdpi

Please read the Android Documentation regarding screen sizes.

From a base image size, there is a 3:4:6:8:12:16 scaling ratio in drawable size by DPI.

LDPI - 0.75x
MDPI - Original size // means 1.0x here 
HDPI - 1.5x
XHDPI - 2.0x
XXHDPI - 3x
XXXHDPI - 4.0x

For example, 100x100px image on a MDPI will be the same size of a 200x200px on a XHDPI screen.

Android hdpi/mdpi/ldpi for Values folder?

Yes, I believe anything in the res/ folder can use "Configuration Qualifiers". So for example, you can have a values-sw600dp-mdpi-land/ folder.

See "Using Configuration Qualifiers":
http://developer.android.com/guide/practices/screens_support.html#qualifiers

I first noticed this by looking at Google's IOSched app sample code, look at the res folder:
https://github.com/google/iosched/tree/master/android/src/main/res

You'll see that they have "values-sw600dp-land", "values-w400dp" and "values-v17" folders, just to name a few.

Android drawables - use xhdpi for hdpi

Yes, Android scales drawables, selecting the drawable that will produce the best result. But not all scaling combinations work that well. Downscaling to MDPI can produce noticeably poor results. XHDPI to HDPI generally produces pretty good results. But given that the overwhelming majority of devices these days are HDPI, it's probably worthwhile to have HDPI resources. HDPI to XHDPI scaling is not terrible. Some 1280x720 devices uses XHDPI resource. These generally look ok. Google TV uses XHDPI as well. On a huge screen, scaling errors are visible.

LDPI devices are -- for all practical purposes -- non-existent now.

True that generating scaled resources is an enormous PITA. But, in my opinion, you really need to do MDPI and HDPI. And once you've got that unpleasant workflow down, it doesn't require a lot of extra work to generate XHDPI. For what it's worth, if your artwork is in vector format, the vast majority of resources don't need tweaking for specific resolutions. There doesn't seem to be any compelling need to pixel-align edges of square objects, for example. Usually it's only interior features in complex icons and artwork that benefit from some amount of pixel-pushing.

It's pretty clear that XHDPI is going to be come more and more common. Trust me, you don't want to go back and re-do all your artwork in XHDPI after the fact. My advice: if you intend to still be shipping your app a year from now, suck it up, and do the nasty as you go, while it's still relatively easy.

---

Related Topics