Use only XHDPI graphics in an Android app?

Question

If you plan to support LDPI, MDPI, HPDI, and possibly XHDPI in the near future, is it normal to include only XHDPI drawings in the project and allow devices to scale them to the required resolution?

I tested resizing drawings in MDPI and HDPI in Photoshop, and then compared the result with the XHDPI sizes only changed on Android, and I don't see any difference. Is it a bad design to use this shortcut? It would be nice not to resize each of them in 3 different resolutions.

Planning to use the target SDK - 2.1 or 2.2.

BR Emil

Answer 1

I think this is a good way. The only drawback I can think of is the overhead of small devices and possible artifacts due to downscaling. In fact, this year Google IO Chris Pruet recommended deploying only high-resolution assets and let opengl handle scaling.

Answer 2

Starting with Android 1.6, different densities are processed, including XHDPI (which was not officially added until 2.2). At first, your application will look for an image that matches its density, but it can look at large “buckets” such as XHDPI, and then scale for you.

It’s best to include specific assets for the density you want to maintain. Image which 100x100 occupies 40kb; and an image that 200x200 takes 160k (uncompressed). Thus, any XHDPI assets used on MDPI devices have four times the required data that needs to be processed when the application starts and your resources. Using lower memory means more efficiency and less chance of an OutOfMemoryException.

In addition, certain types of images will not look good with automatic scaling. In particular, images with thin lines or thin patterns will be confused. When you reduce the images manually, you can choose the algorithm that best suits your needs (linear, bicubic, lanczos, etc.).

If you are worried about the time it takes to resize, you can enable the batch process or use tools like Nine Patch Resizer: http://code.google.com/p/9patch-resizer/

Answer 3

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

Maybe the thing with the memory is correct, so someone needs to check it.

Answer 4

I personally found that using only the xhdpi folder works well in many applications and I really support this approach. The memory overhead is true, but with today's devices, I would find this insignificant. In addition, I think that there is some caching related to downscaling, as I have never noticed a slowdown due to this. Including only one folder can significantly reduce the size of the APK, which end users will appreciate. You should keep in mind that some images will get artifact scaling (thin templates, etc.), but I personally have never come across anything critical in my applications. Also, for buttons and stuff, be sure to use 9 patches to reduce artifacts at rounded corners, you can even slightly reduce the image size using this approach. The API level will not be a problem for older versions, since I believe drawable-xhdpi is considered simply available for versions that do not support it. Do not ignore the possibilities of defining some simple drawings in xml, for example, it is very simple to create a gradient background with only shapes, and with this you will save space and do not risk scaling artifacts.

Answer 5

XHDPI was introduced only in the 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 drawings, and devices with Froyo or lower will not display anything.

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

Answer 6

It is normal to have only xhdpi resources. But keep in mind that xhdpi was introduced with api level 9 (gingerbread cookies). That is, if you target api levels <= 8, you will need at least hdpi resources.

Answer 7

This statement about using extra memory is incorrect.

If you put XHDPI dimensional drawings inside the MDPI folder, then you will have memory problems.

But if you provide XHDPI drawables inside XHDPI , then no additional memory will be used, since android reduces the number of images by skipping parts of them.

This skipping is the reason you need to provide blueprints for each density you plan to maintain so that they look good.

On the other hand, only some images will look bad, if downsampled (mostly small icons), as long as the image has enough data to be discarded, it will look normal. Or imagne, if you have a grid as a drawable, so the potential of some grid lines may be thrown away and the image will look bad.

In the end, you'd better experiment with different devices, then you can determine which descendants need alternative resources for their density.