Only use XHDPI drawables in Android app?

Question

If you\'re planning to support LDPI, MDPI, HPDI, and perhaps XHDPI in the near future, is it ok to only include XHDPI drawables in the project and let the devices scale them

Answer 1

It's OK to have only xhdpi resources. But note that xhdpi was introduced with api level 9 (gingerbread). That is, if you target api levels <=8 you need at least also hdpi resources.

Answer 2

I tested in a simple app (develop for Android 2.1) using only xhdpi images and it works fine in small, medium and high resolutions... even I tested in an Android 2.1 (small resolution) and it opens the imagen without problem.

Maybe the thing with the memory is true, so its necessary someone test this.

Answer 3

As of Android 1.6, different densities are handled, including XHDPI (which wasn't officially added until 2.2). Your app will first look for an image matching its density, but it can look into larger "buckets" like XHDPI and then perform the scaling for you.

It's best to include specific assets for the densities you want to support. An image that's 100x100 takes 40kb; and image that's 200x200 takes 160k (uncompressed). So, any XHDPI assets used on MDPI devices have four times the amount of data that you need, which has to be handled when the app starts and your resources are prepared. Lower memory use means greater efficiency, less chance for an OutOfMemoryException.

Further, specific types of images will look bad when automatically scaled. In particular, images with fine lines or fine patterns will have their detail muddied. When you shrink the images by hand, you can choose the algorithm that best matches your needs (linear, bicubic, lanczos, etc.).

If you're worried about the time it takes to do the resizing yourself, you can incorporate a batch process or use tools such as Nine Patch Resizer: http://code.google.com/p/9patch-resizer/

Answer 4

XHDPI was only introduced in Android SDK API Level 9 (Gingerbread) (see http://developer.android.com/reference/android/util/DisplayMetrics.html#DENSITY_XHIGH) so if you plan to have a minimum SDK level of less than 9 you will also need to provide, at least, HDPI drawables as well otherwise devices with Froyo or below will display nothing.

Update: It actually seems like versions prior to Gingerbread will display xhdpi images: https://groups.google.com/d/msg/android-developers/yjYO91OmoJ4/v3he0ZbKo-UJ

Answer 5

I personally found that using just xhdpi folder works quite good in many apps and am a big supporter of this approach. In memory overhead is true but with todays devices I would consider it negligible. Also I think there is some caching involved after downscaling since I never noticed any slow down because of this. Including only one folder can dramatically reduce your APK size which end users will quite appreciate. You should keep in mind that some images will get scaling artifacts (fine patterns and stuff) but I personally never encountered nothing critical in my apps. Also for buttons and stuff be sure to use 9patches in order to reduce artifacts on rounded corners, you can even slightly reduce image size by using this approach. API level will not be a problem on older versions since I think that drawable-xhdpi is regarded as just drawable on versions that didn't support it. Don't ignore chances to define some simple drawables in xml, for example it's really easy to create gradient background with just shapes and with this you save space and don't risk scaling artifacts.

Answer 6

This statement about extra memory usage is wrong.

If you put XHDPI sized drawables inside MDPI folder, then you will have memory problems.

But if you provide XHDPI drawables inside XHDPI folder, then no extra memory will be used since android downsamples the images by skipping parts of it.

This skipping is the reason why you need to provide drawables for every density you plan to support in order them to look good.

On the other hand, only certain images will look bad when downsampled (mostly small icons) so as long as the image has enough data to be thrown away, it will look ok. Or imagne if you have a grid as a drawable, so potentialy some grid lines can get thrown away and the image will look bad.

In the end, it is better for you to experiment with different devices, then you can tell which drawales need alternative resources for their density.