Develop Reference

why in Android 1024x600 is considered as mdpi?

I'm new with Android, and i don't know why android consider 1024x600 as mdpi,
in my application i'm using some images, and there is no drawable folder for the 1024x600

Display resolution (e.g. 1024x600) and screen density (e.g. mdpi) are related but independent concepts.
Screen size:
Actual physical size, measured as the screen's diagonal.
For simplicity, Android groups all actual screen sizes into four generalized sizes: small, normal, large, and extra large.
Screen density:
The quantity of pixels within a physical area of the screen; usually referred to as dpi (dots per inch). For example, a "low" density screen has fewer pixels within a given physical area, compared to a "normal" or "high" density screen.
Resolution:
The total number of physical pixels on a screen. When adding support for multiple screens, applications do not work directly with resolution; applications should be concerned only with screen size and density, as specified by the generalized size and density groups.
Grossly oversimplifying, you generally provide different resources for different screen sizes when you want them to be different in phones and tablets (e.g. for layouts), and different resources for different densities so that the system doesn't need to scale them, which could cause artifacts (e.g. for images).

Is it correct way to create separate layout file for supporting different screens? [duplicate]

I'm really feeling confused. From the docs at developer.android.com, it seems in order to keep my images scaled correctly (aspect ratio too) across all current Android devices I need all these layouts below. Is that really what everyone is doing? Am I missing something, or should I be going about this a different way?
Low density Small screens QVGA 240x320
------------------------------------------------
layout-small-ldpi
layout-small-land-ldpi
Low density Normal screens WVGA400 240x400 (x432)
------------------------------------------------
layout-ldpi
layout-land-ldpi
Medium density Normal screens HVGA 320x480
------------------------------------------------
layout-mdpi
layout-land-mdpi
Medium density Large screens HVGA 320x480
------------------------------------------------
layout-large-mdpi
layout-large-land-mdpi
High density Normal screens WVGA800 480x800 (x854)
------------------------------------------------
layout-hdpi
layout-land-hdpi
Xoom (medium density large but 1280x800 res)
------------------------------------------------
layout-xlarge
layout-xlarge-land

Your app will work on 100% of the devices with the classic layout.
You can just add some buttons or change the layout in landscape mode by adding some qualifiers but that's up to you!
For instance, on LDPI (small resolution) device, you may want to adjust some buttons or change a little bit to fit the small screen.
You may also want to put some buttons on the right in landscape mode and in the bottom of your layout in portrait!
You do not "have to" use them.

According to Android Dev Protip from Roman Nurik about screen size qualifiers:
If you have custom layouts for larger screen devices such as tablets,
now's the time to stop using the -large or -xlarge resource qualifier
and switch to using -swXXdp or -wXXdp qualifiers. The latter were
introduced in API level 13, which basically all tablets now have
support for according to the latest platform version charts1.
means that for basically all cases where -large would have any effect,
-swXXdp can be used instead to provide more granularity.
So which actual sw or w qualifiers should you use? Here's a quick
just-give-me-something starting point:
7" tablets: Instead of layout-large, use layout-sw600dp.
Example: Nexus 7 = 960×600 dp; the smaller of the two dimensions is
600.
10" tablets: Instead of layout-xlarge, use layout-sw720dp.
Example: Nexus 10 = 1280×800 dp; the smaller of the two dimensions is
800. Some 10" tablets are a bit more narrow so 720 is a commonly used switching point.
There's more to it than just that (you really want to choose switching
points based on your content's minimum requirements, not on device
form factor), but that's a #Protip for another day (::cough:: +Nick
Butcher ::cough::).

In the layout if you do not use AbsoluteLayout, you application is going to be resized to fit the screen.
But in some cases, for smaller screens you need declare a new layout with less components for example.
For images:
You has some options.
Simple ignore some resolutions and let the device choose the best image to it.
Declare on AndroidManifest for wich sizes you want to support.
Or has just one and let the resize screw your application.

Yes. You should define different layout for different screen resolution.
When you are supposed to work with tablet kind of application. That time really you feel that. There is a need of different layout. Because Tablets always comes in different size.
One more thing, When you are working on android, means you should always taste your app with real device. And also test with different size emulators.

Application Skeleton to support multiple screens

As we know Android coming with various device which having different
Features, Resolution, and Screen-size so while developing an Application which support
multiple (small and big) screen there is an obstacle of size and layout.
This leads to different combinations of screen sizes, resolutions, and DPIs and creates quite a challenge when designing and developing for Android devices. While some other Manufacturer (non Android) have different resolutions and DPI, they share the same screen size and the resolutions follow the same aspect ratio. Therefore, an image can be created to fit the non Android devices.
My question is that is there a proper flow or architecture that one should follow to meet the requirement?
Remember we do have Tablets of different Size and Resolution.
I'm aware that Android Developer contains this information but my view is from implementation.
From my knowledge what I understood is that for designing Android graphics even Programmer must know the designing concept.

Finally created a structure which handle layouts and icon for multiple screen.
Android generalises device displays into categories based on two parameters:
Screen size, the physical size of the display (measured diagonally)
Screen density, the physical pixel density of the display (in pixels-per-inch, or ppi)`
To determine screen size & density quickly, please install "What's my Size" app for Android.
Screen size
Android defines four generalised screen sizes:
Qualifier Size
small ~3 inches (approx)
normal ~4 inches (approx)
large Exceeds 4 inches
xlarge Exceeds 7 inches
Most phones are classified as small or normal (roughly 3 to 4 inches diagonally). But now, there are many phones with large screen such as Galaxy S4, HTC One, Xperia Z
A small tablet like the Samsung Galaxy Tab is classified as large (larger than 4 inches)
Extra-large applies to large devices, for example large tablets
Android defines four generalised screen densities:
Qualifier Description Nominal value
ldpi low density 120 ppi
mdpi medium density 160 ppi
hdpi high density 240 ppi
xhdpi extra high density 320 ppi
Typically:
screen size has most impact on your app layouts
screen density has most impact on your image and graphic resources
It is listed here the percentage difference of device screen
Ldpi- 75%
Mdpi- 100% (base according to Android developer site)
Hdpi- 150%
XHdpi- 200%
But as we know now most of device coming with 480X800 so I'm consider this as based device, so our new calculation will like this
Ldpi- 50%
Mdpi- 66.67%
Hdpi- 100%
XHdpi- 133.33%
which means that first icon and design will be created for 480X800 only and then for rest ones(i.e. Ldpi, Mdpi, Xhdpi).
There are images which are common for all layout and must uniform in color and shape(no complex shape, no curve) so for this kind of image we are creating 9patch which to be put in “drawable(no-suffix)” folder. To create 9Patch image you can either use DrawNinePatch or BetterNinePatch
Now just rename your images based on Android's standards and complete your application with hdpi and then just take drawable-hdpi folder and Open Adode Photoshop(recommended)
create Action of multiple size(just change the size according to percentage ratio) once Action created for all size then just do Batch Automate and give source(drawable-hdpi) and destination(drawable-ldpi, drawable-mdpi, drawable-xdpi).
The reason I insist you to use Photoshop because it will resize automatically your image with Actions and one more plus point is that you need not to rename the file(it will assign same name as original one).
once you completed with creation of all images, refresh your project and test it.
Sometimes there may be possibility that the layout which support screen(xhdpi, hdpi, mdpi) may be get cut in small screen(ldpi) so for handling this just create separate Layout folder(layout-small) for it and add ScrollView(mostly). Thats it.
Tablet
Tablets are categorized into two size.
7"(1024X(600-48(navigation bar))) = 1024X552 (drawable-large)
10"(1280X(800-48(navigation bar))) = 1280X752 (drawable-xlarge)
In this we need to create image for both the screen and just put them accordingly
So all in all we will have this folder in our application to support multiple screen.
drawable
drawable-ldpi
drawable-mdpi
drawable-hdpi
drawable-xhdpi
drawable-large
drawable-xlarge
will be more qualifier combination with Screen size and Screen density
drawable-large-ldpi
drawable-large-mdpi
drawable-large-hdpi
drawable-large-xhdpi
more qualifier with Screen density and Version
drawable-ldpi-v11
drawable-mdpi-v11
drawable-hdpi-v11
drawable-xhdpi-v11
and more qualifier with Screen size and Version
drawable-large-v11
drawable-xlarge-v11
and more qualifier with Smallest width concept(SW)
drawable-sw???dp
Further more in Android V3.0 Honeycomb they introduced new concept of SW(smallest width) in which device are categorized into screen width, so if we are creating a folder named drawable-sw360dp then the device with 720dp(either width or height) will use resource from the this folder.
for example to find the Samsung Galaxy S3 dp to suffix to drawable-sw?dp
With reference of DP Calculation, If you want to support your layout or drawable to S3 then the calculation says
px= Device's width = 720
dpi= Device's density= 320
formula given
px = dp * (dpi / 160)
interchanging formula because we have px's value
dp = px / (dpi / 160)
now putting value,
dp= 720 / (320/160);
dp=360.
so drawable-sw360dp will do the job
Get you Device configuaration from GsmArena
Sameway you can also create folder according to Device's Android API version i.e. drawable-hdpi-v11` so the device which is having API11 and it is Hdpi then it will use this resources.
Additional Tips:
Use relative layouts, dp, sp, and mm
dp units - device independent pixels normalised to 1 physical pixel on a 160 ppi screen i.e. medium density. Scaled at runtime. Use for screen element dimensions
sp units - scaled pixels, specified as floating point values, based on dp units but additionally scaled for the user's font-size preference setting. Scaled at runtime. Use for font sizes
you should always use RelativeLayout for layouts; AbsoluteLayout is deprecated and should not be used.
Use appropriate image formats - PNG versus JPEG
Android "prefers" PNG for bitmap image files, "accepts" JPEG, and "discourages" GIF.
However, PNG and JPEG are not equivalents. They have different quality trade offs, and PNG is not always best:
JPEG can offer up to 50% file-size reductions over PNG, which is significant if your app is image-intensive
A higher quality "lossy" JPEG may look better than a highly compressed "lossless" PNG, for the same file size
Add labels to your images and graphics for debugging
Use the supports-screens element
Configure your emulators with real device values
Conventionally, desktop systems display at 72ppi (Mac), or 96ppi (Windows, Linux). Compared with mobile, desktop displays are always low density.
Always configure your Android emulators to mimic real device values, and always set them to scale to emulate device density.
In Eclipse, it's easy to create multiple emulators (from the Eclipse menu bar, select Window > AVD Manager > New) configured with values for real devices:
Name the emulator for the real device it's emulating
Specify Resolution, don't use Built-in generic sizes
Set the device density to match the real device (in the Hardware pane set Abstracted LCD Property to the real density, always an integer value)
When you launch the device, always select Scale display to real size, and type in the real screen dimension in inches.
If you don't set the device density, the emulator defaults to low density, and always loads ldpi-specific resources. Resolution (pixel dimensions) will be correct, but your density-dependent image resources will not display as intended.
Of course, nothing you do will reproduce higher density image quality on a lower density desktop display.
Here is the Data collected during a 7-day period ending on October 1, 2012. To see the latest statistic about Android platform version, go to here
Based on Screen Size
Based on Screen Density

Designers should create base designs of
base size of mdpi devices * density conversion factor of highest supported density bucket
size.Base screen size is 320 X 480 px and density buckets are as follows:
ldpi: 0.75
mdpi: 1.0 (base density)
hdpi: 1.5
xhdpi: 2.0
xxhdpi: 3.0
xxxhdpi: 4.0
And to tackle extra available space on Android devices should use stretchable components in both the directions (horizontally and vertically). Detailed info is available here:
http://vinsol.com/blog/2014/11/20/tips-for-designers-from-a-developer/

Screen resolution / Physical size

I'm implementing an app for Android(API 10). I have few designs for tablet(supposedly) and for mobile phone. Regarding the previous sentence it might sound a bit stupid: in my opinion layouts should be picked according to device's physical size - not resolution, otherwise there might be a phone with high resolution that renders, say, a grid of 5x5, in rather confusing, inadequately small-sized way. In order to provide division by physical size I gotta use /res/layout-* folders. Agreed ?
Also: I'm a bit confused about multiple-screens guide's definition on physical size. Would you mind explaining what physical size is in terms of Android mean, what it's measured in? Is there any correlation with dpi?
Thanks.

A workaround for api level 10 could be something like this:
use the compat lib from the SDK so that you can design with fragments.
Assume everything before android 3 is a phone. For example use your layout files in layout/* for this (and the rest will be based it on unless overriden). This assumption is basically only wrong for the original Samsung Galaxy Tab 7" from 2009.
Assume everything on android 3.x is a tablet (they are), so do some tablet specific layout if you want and have them under layout-v11 (and maybe also layout-v12 if there is anything specific to android 3.1). Tablet specific layout could mean that you arrange your fragments differently and/or show multiple fragments at the same time.
Everything newer (android 3.2+) you can use the new stuff from api level 13. Such as layout-sw600dp/ for some layouts etc etc. http://developer.android.com/guide/practices/screens_support.html#DeclaringTabletLayouts

Physical size is usually measured in inches, it simply tells you the real device's screen size (usually 3-4" inches for phones and 8-11" for tablets).
dpi, is NOT correlated with it. Dpi expresses screen density, how many pixels are shown in a given area (usually a square inch). It could be considered as a measure of screen quality.
Resolution is given by the product of the two; it expresses the total number of physical pixels on a screen.
Going back to your first question, you should be density independent as much as possible; your app should "look the same" on devices with different densities. The /res/layout-* folders are designed to provide this feature, the system scales drawable resources to the appropriate size and you could then declare in your manifest that your app supports any density:
android:anyDensity="true"
On page http://developer.android.com/guide/topics/resources/providing-resources.html#BestMatch you can learn how Android choose the best matching resource.

With Android API 10 the best option for targeting tablets is probably just distinguishing the actual size of the screen in the code using something like:
https://stackoverflow.com/a/5789916/1319155
and then just load a different drawable if the size value returned was greater than 6 (or whatever size you want to declare as a "tablet").
The reason you can't really just use the size folders (i.e. layout/large) is because the folders don't distinguish between phones and tablets very well. A kindle fire and galaxy nexus may both be considered "large" devices.
The reason you can't really use dpi is because that is not a good reflection on what type of device it is, just how "dense" the pixels are on a screen. Most new phones are much denser (having more pixels per inch) than tablets anyway.

There are two ways of doing this. From Android 1.6 (API 4) on, there are four layouts that describe the physical size of the display: small, normal, large, and xlarge. As described on http://developer.android.com/guide/practices/screens_support.html , these correspond to:
xlarge screens are at least 960dp x 720dp
large screens are at least 640dp x 480dp
normal screens are at least 470dp x 320dp
small screens are at least 426dp x 320dp
Note that these are measured in DP, not DPI. DPI is Dots Per Inch, and specifies screen density. DP, also written DIP, are Density-Independent Pixels. Again from the guide:
Density-independent pixel (dp)
A virtual pixel unit that you should use when defining UI layout, to express layout dimensions or position in a density-independent way.
The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a "medium" density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use. The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels. You should always use dp units when defining your application's UI, to ensure proper display of your UI on screens with different densities.
In other words, 160 DP = 1". Applying this standard, we see:
xlarge screens are at least 6" x 4.5" (7.5" diagonal)
large screens are at least 4" x 3" (5" diagonal)
normal screens are at least 2.9" x 2" (3.5" diagonal)
small screens are at least 2.6" x 2" (3.3" diagonal)
(Not sure why the selection is so odd, but that's what they defined.)
From Android 3.2 on (API 13), there are more options, as described here:
http://developer.android.com/guide/practices/screens_support.html#DeclaringTabletLayouts
Here you can use "smallest screen width," "available width," or "available height" options to define your own categories; again, the unit in question is DP, which is 1/160". Note that these specify the smaller of the two dimensions on the device--e.g., for a 7" tablet they recommend specifying layout-sw600dp, that is, "smallest width 3.75 inches," which would be intermediate between the "large" and "xlarge" sizes defined in API 4. They have a number of specific comments about this topic, including notes about how the widths are measured (it may exclude things like the notification bar), so it's worth taking a look at the documentation.

Android Resources - which resolutions should go into the hdpi, ldpi, mdpi and xhdpi directories

I'm trying to write an application that will work well on all screen sizes, for that I have my graphic designer produce images that are in the requested dpis for each directory (Low density (120), ldpi, Medium density (160), mdpi, High density (240), hdpi, Extra high density (320), xhdpi) however, they want to know at which resolution and aspect ratio each image should be, after looking around the android documenation, namely:
1)http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources
2)http://developer.android.com/guide/practices/screens_support.html
I came up with the following information:
It is not exact that android supports 3 screen sizes, android is an OS that can run virtually on any screen size but there are some screen sizes that are more common than others, these are demonstrated in the table below (taken from http://developer.android.com/guide/practices/screens_support.html)
Table 1. Screen sizes and densities of emulator skins included in the Android SDK.
Low density (120), ldpi Medium density (160), mdpi High density (240), hdpi Extra high density (320), xhdpi
Small screen QVGA (240x320)
Normal screen WQVGA400 (240x400)
WQVGA432 (240x432) HVGA (320x480) WVGA800 (480x800)
WVGA854 (480x854)
Large screen WVGA800* (480x800)
WVGA854* (480x854)
Extra Large screen
It’s worth noting here that even though it seems that there is no correlation between these screen sizes, there is a 3:4:6 scaling ratio between the three densities, so a 9x9 bitmap in ldpi is 12x12 in mdpi and 18x18 in hdpi (see http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources).
We can see some more information on what the screen sizes mean here:
Screen size
• small: Screens based on the space available on a low-density QVGA screen. Considering a portrait HVGA display, this has the same available width but less height—it is 3:4 vs. HVGA's 2:3 aspect ratio. Examples are QVGA low density and VGA high density.
• normal: Screens based on the traditional medium-density HVGA screen. A screen is considered to be normal if it is at least this size (independent of density) and not larger. Examples of such screens a WQVGA low density, HVGA medium density, WVGA high density.
• large: Screens based on the space available on a medium-density VGA screen. Such a screen has significantly more available space in both width and height than an HVGA display. Examples are VGA and WVGA medium density screens.
• xlarge: Screens that are considerably larger than the traditional medium-density HVGA screen. In most cases, devices with extra large screens would be too large to carry in a pocket and would most likely be tablet-style devices. Added in API Level 9.
We can also support specific aspect ratios, as defined here:
Screen aspect
• long: Long screens, such as WQVGA, WVGA, FWVGA
• notlong: Not long screens, such as QVGA, HVGA, and VGA
--
All of this however, is not enough to answer the simple question of what the resolution should be on those images - can they all be cut from the same high res image or should they be re-done for each dpi since the aspect ratio is different?
please help, this is holding up my project
Thanks!

It depends on your images, really. Very tiny graphics you'll probably want to draw separately, since you're going to lose fine details when interpolating to smaller sizes, whereas with larger ones, you'll probably be fine just rescaling, starting with a high resolution image.
For background images, that's always kind of a tricky one. Since you can't count on a specific resolution, you can either estimate and go with one slightly smaller than the average, and turn it into a 9-patch, where the edges will stretch to cover the leftover space, or you can go with one slightly larger than the average (something like 900 x 500) and just make sure the edge area doesn't contain any pertinent information. Basically, think of it like a bleed for print, it's just extra area that may be cut off if the screen's not big enough. It's easier to just use some sort of gradient drawable or other resolution independent type of image for the background, if possible, due to the large number of different resolutions to support.

When I'm creating graphics I considering this way:
ldpi 240x320
mdpi 320x480
hdpi 480x800
xhdpi 800x1280
Putting images separate drawable folders, drawable-hdpi, drawable-mdpi....
Background is a bit tricky, you may do so with bg or even set it from your program not layout xml file. That will provide you more flexibility, to chose weather you going to resize or crop it.