Android device sizes list

Appendix C: Everything about sizes and dimensions in Android

Designing Android app you have to be aware of enormous variety of devices. They have different physical sizes (from small phones to large tablets), different screen sizes (diagonal from 3 inches or less to above 5 inches), different screen resolutions (from 320×480 pixels to Full HD – 1920×1080 – or more) and different screen densities – number of pixels per inch (from 120 dpi to 480 dpi). And there is also screen orientation (landscape or portrait) to take into account.

It would take very, very long time to create layout for every device separately and you still couldn’t be sure that you included all combinations. Fortunately, Android creators tried to do it simpler. You don’t have to create unlimited layouts, but it doesn’t mean that there is nothing to worry about.

Available units: Forget inches (in), say goodbye to pixels (px), use density-independent pixels (dp or dip)

Android allows you to measure layout elements even in inches (abbreviation “in”). So you could say that specific TextView or Button would be 3 inch long and 1 inch tall. This would be rather difficult to use as many elements would have to be measured in fractions and still it would be impossible to be very precise. Similar situations is with millimeters (abbreviation “mm”) and points (abbreviation “pt”).

More common approach is to use pixels (abbreviation “px”). But that leads to another problem. If we create an element that is 160 pixels wide it’s length on medium density screen would be 1 inch and on extra high density screen only 0.5 inch even if the screens have the same resolution.

That’s why there is one more unit which hasn’t those problems. It’s called density-independent pixels (abbreviation “dp” or “dip” – both work). If we say that something has 100dp it would have the same real size on every screen. So for all dimensions in Android app use dp only, unless you really have to use some other unit. When you define dimension in dp, Android automatically uses as many pixels as needed on specific screen to achieve expected size.

List of supported units:

dp or dip – density-independent pixels, abstract unit based on physical density of a screen

in – inches (not recommended)

mm – millimeters (not recommended)

pt – points, 1pt equals 1/72 of inch (not recommended)

px – pixels (not recommended)

You have to put unit after the value without space between.

Источник

Supporting Different Screen Sizes Andorid

Mobile application run on different devices with different screen sizes and form factors. Android devices come in a variety of screen sizes and resolutions. That’s why handling the multiple screen size in android is most important.

Screen size : Actual physical size, measured as the screen’s diagonal.For simplicity, Android groups has 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 simplicity, Android groups has four generalized densities: low, medium, high, and extra high.

Orientation : The orientation of the screen from the user’s point of view.In Android, This is either landscape or portrait.

Resolution : The total number of physical pixels on a screen.In Android, we do not work directly with resolution; applications should be concerned only with screen size and density.

How To Support Different Screen’s

Use “wrap_content” and “match_parent”

To ensure that your layout is flexible and adapts to different screen sizes, you should use «wrap_content» and «match_parent» for the width and height of some view components. If you use «wrap_content» , the width or height of the view is set to the minimum size necessary to fit the content within that view, while «match_parent» makes the component expand to match the size of its parent view.

By using the «wrap_content» and «match_parent» size values instead of hard-coded sizes, your views either use only the space required for that view or expand to fill the available space, respectively. For example:

Notice how the sample uses «wrap_content» and «match_parent» for component sizes rather than specific dimensions. This allows the layout to adapt correctly to different screen sizes and orientations.

Use RelativeLayout

You can construct fairly complex layouts using nested instances of LinearLayout and combinations of «wrap_content» and «match_parent» sizes. However, LinearLayout does not allow you to precisely control the spacial relationships of child views; views in a LinearLayout simply line up side-by-side. If you need child views to be oriented in variations other than a straight line, a better solution is often to use a RelativeLayout , which allows you to specify your layout in terms of the spacial relationships between components. For instance, you can align one child view on the left side and another view on the right side of the screen.

Use Size Qualifiers

There’s only so much mileage you can get from a flexible layout or relative layout like the one in the previous sections. While those layouts adapt to different screens by stretching the space within and around components, they may not provide the best user experience for each screen size. Therefore, your application should not only implement flexible layouts, but should also provide several alternative layouts to target different screen configurations. You do so by using configuration qualifiers, which allows the runtime to automatically select the appropriate resource based on the current device’s configuration (such as a different layout design for different screen sizes).

For example, many applications implement the “two pane” pattern for large screens (the app might show a list of items on one pane and the content on another pane). Tablets and TVs are large enough for both panes to fit simultaneously on screen, but phone screens have to show them separately. So, to implement these layouts, you could have the following files:

• res/layout/main.xml , single-pane (default) layout:
• android:orientation=”vertical”
  android:layout_width=”match_parent”
  android:layout_height=”match_parent”>
• res/layout-large/main.xml , two-pane layout:
• android:layout_width=”fill_parent”
  android:layout_height=”fill_parent”
  android:orientation=”horizontal”>

Notice the large qualifier in the directory name of the second layout. This layout will be selected on devices with screens classified as large (for example, 7″ tablets and above). The other layout (without qualifiers) will be selected for smaller devices.

Use the Smallest-width Qualifier

One of the difficulties developers had in pre-3.2 Android devices was the “large” screen size bin, which encompasses the Dell Streak, the original Galaxy Tab, and 7″ tablets in general. However, many applications may want to show different layouts for different devices in this category (such as for 5″ and 7″ devices), even though they are all considered to be “large” screens. That’s why Android introduced the “Smallest-width” qualifier (amongst others) in Android 3.2.

The Smallest-width qualifier allows you to target screens that have a certain minimum width given in dp. For example, the typical 7″ tablet has a minimum width of 600 dp, so if you want your UI to have two panes on those screens (but a single list on smaller screens), you can use the same two layouts from the previous section for single and two-pane layouts, but instead of the large size qualifier, use sw600dp to indicate the two-pane layout is for screens on which the smallest-width is 600 dp.

Use Layout Aliases

The smallest-width qualifier is available only on Android 3.2 and above. Therefore, you should also still use the abstract size bins (small, normal, large and xlarge) to be compatible with earlier versions. For example, if you want to design your UI so that it shows a single-pane UI on phones but a multi-pane UI on 7″ tablets, TVs and other large devices, you’d have to supply these files:

• res/layout/main.xml: single-pane layout
• res/layout-large: multi-pane layout
• res/layout-sw600dp: multi-pane layout

Use Orientation Qualifiers

Some layouts work well in both landscape and portrait orientations, but most of them can benefit from adjustments. In the News Reader sample app, here is how the layout behaves in each screen size and orientation:

• small screen, portrait: single pane, with logo
• small screen, landscape: single pane, with logo
• 7″ tablet, portrait: single pane, with action bar
• 7″ tablet, landscape: dual pane, wide, with action bar
• 10″ tablet, portrait: dual pane, narrow, with action bar
• 10″ tablet, landscape: dual pane, wide, with action bar
• TV, landscape: dual pane, wide, with action bar

Use Nine-patch Bitmaps

Supporting different screen sizes usually means that your image resources must also be capable of adapting to different sizes. For example, a button background must fit whichever button shape it is applied to.

If you use simple images on components that can change size, you will quickly notice that the results are somewhat less than impressive, since the runtime will stretch or shrink your images uniformly. The solution is using nine-patch bitmaps, which are specially formatted PNG files that indicate which areas can and cannot be stretched.

Источник

Support different pixel densities

Not only do Android devices come in different screen sizes (handsets, tablets, TVs, and so on), but their screens also have different pixel sizes. That is, while one device has 160 pixels per square inch, another device fits 480 pixels in the same space. If you don’t consider these variations in pixel density, the system might scale your images (resulting in blurry images) or the images might appear at the completely wrong size.

This page shows you how you can design your app to support different pixel densities by using resolution-independent units of measurements and providing alternative bitmap resources for each pixel density.

Watch the video below for an overview of these techniques.

For more information about designing the actual icons assets, see the material design icon guidelines.

Use density-independent pixels

The first pitfall you must avoid is using pixels to define distances or sizes. Defining dimensions with pixels is a problem because different screens have different pixel densities, so the same number of pixels may correspond to different physical sizes on different devices.

Figure 1. Two screens of the same size may have a different number of pixels

To preserve the visible size of your UI on screens with different densities, you must design your UI using density-independent pixels (dp) as your unit of measurement. One dp is a virtual pixel unit that’s roughly equal to one pixel on a medium-density screen (160dpi; the «baseline» density). Android translates this value to the appropriate number of real pixels for each other density.

For example, consider the two devices in figure 1. If you were to define a view to be «100px» wide, it will appear much larger on the device on the left. So you must instead use «100dp» to ensure it appears the same size on both screens.

When defining text sizes, however, you should instead use scalable pixels (sp) as your units (but never use sp for layout sizes). The sp unit is the same size as dp, by default, but it resizes based on the user’s preferred text size.

For example, when you specify spacing between two views, use dp :

When specifying text size, always use sp :

Convert dp units to pixel units

In some cases, you will need to express dimensions in dp and then convert them to pixels. The conversion of dp units to screen pixels is simple:

Imagine an app in which a scroll or fling gesture is recognized after the user’s finger has moved by at least 16 pixels. On a baseline screen, a user’s must move by 16 pixels / 160 dpi , which equals 1/10th of an inch (or 2.5 mm) before the gesture is recognized. On a device with a high-density display (240dpi), the user’s must move by 16 pixels / 240 dpi , which equals 1/15th of an inch (or 1.7 mm). The distance is much shorter and the app thus appears more sensitive to the user.

To fix this issue, the gesture threshold must be expressed in code in dp and then converted to actual pixels. For example:

Kotlin

The DisplayMetrics.density field specifies the scale factor you must use to convert dp units to pixels, according to the current pixel density. On a medium-density screen, DisplayMetrics.density equals 1.0; on a high-density screen it equals 1.5; on an extra-high-density screen, it equals 2.0; and on a low-density screen, it equals 0.75. This figure is the factor by which you should multiply the dp units in order to get the actual pixel count for the current screen.

Use pre-scaled configuration values

You can use the ViewConfiguration class to access common distances, speeds, and times used by the Android system. For instance, the distance in pixels used by the framework as the scroll threshold can be obtained with getScaledTouchSlop() :

Kotlin

Methods in ViewConfiguration starting with the getScaled prefix are guaranteed to return a value in pixels that will display properly regardless of the current pixel density.

Provide alternative bitmaps

To provide good graphical qualities on devices with different pixel densities, you should provide multiple versions of each bitmap in your app—one for each density bucket, at a corresponding resolution. Otherwise, Android must scale your bitmap so it occupies the same visible space on each screen, resulting in scaling artifacts such as blurring.

Figure 2. Relative sizes for bitmaps at different density sizes

There are several density buckets available for use in your apps. Table 1 describes the different configuration qualifiers available and what screen types they apply to.

Table 1. Configuration qualifiers for different pixel densities.

Density qualifier	Description
ldpi	Resources for low-density (ldpi) screens ( 120dpi).
mdpi	Resources for medium-density (mdpi) screens ( 160dpi). (This is the baseline density.)
hdpi	Resources for high-density (hdpi) screens ( 240dpi).
xhdpi	Resources for extra-high-density (xhdpi) screens ( 320dpi).
xxhdpi	Resources for extra-extra-high-density (xxhdpi) screens ( 480dpi).
xxxhdpi	Resources for extra-extra-extra-high-density (xxxhdpi) uses ( 640dpi).
nodpi	Resources for all densities. These are density-independent resources. The system does not scale resources tagged with this qualifier, regardless of the current screen’s density.
tvdpi	Resources for screens somewhere between mdpi and hdpi; approximately 213dpi. This is not considered a «primary» density group. It is mostly intended for televisions and most apps shouldn’t need it—providing mdpi and hdpi resources is sufficient for most apps and the system will scale them as appropriate. If you find it necessary to provide tvdpi resources, you should size them at a factor of 1.33*mdpi. For example, a 100px x 100px image for mdpi screens should be 133px x 133px for tvdpi.

To create alternative bitmap drawables for different densities, you should follow the 3:4:6:8:12:16 scaling ratio between the six primary densities. For example, if you have a bitmap drawable that’s 48×48 pixels for medium-density screens, all the different sizes should be:

• 36×36 (0.75x) for low-density (ldpi)
• 48×48 (1.0x baseline) for medium-density (mdpi)
• 72×72 (1.5x) for high-density (hdpi)
• 96×96 (2.0x) for extra-high-density (xhdpi)
• 144×144 (3.0x) for extra-extra-high-density (xxhdpi)
• 192×192 (4.0x) for extra-extra-extra-high-density (xxxhdpi)

Then, place the generated image files in the appropriate subdirectory under res/ and the system will pick the correct one automatically based on the pixel density of the device your app is running on:

Then, any time you reference @drawable/awesomeimage , the system selects the appropriate bitmap based on the screen’s dpi. If you don’t provide a density-specific resource for that density, the system picks the next best match and scales it to fit the screen.

Tip: If you have some drawable resources that the system should never scale (perhaps because you perform some adjustments to the image yourself at runtime), you should place them in a directory with the nodpi configuration qualifier. Resources with this qualifier are considered density-agnostic and the system will not scale them.

For more information about other configuration qualifiers and how Android selects the appropriate resources for the current screen configuration, see Providing Resources.

Put app icons in mipmap directories

Like all other bitmap assets, you need to provide density-specific versions of your app icon. However, some app launchers display your app icon as much as 25% larger than what’s called for by the device’s density bucket.

For example, if a device’s density bucket is xxhdpi and the largest app icon you provide is in drawable-xxhdpi , the launcher app scales up this icon, and that makes it appear less crisp. So you should provide an even higher density launcher icon in the mipmap-xxxhdpi directory. Now the launcher can use the xxxhdpi asset instead.

Because your app icon might be scaled up like this, you should put all your app icons in mipmap directories instead of drawable directories. Unlike the drawable directory, all mipmap directories are retained in the APK even if you build density-specific APKs. This allows launcher apps to pick the best resolution icon to display on the home screen.

For icon design guidelines, see the material guide for icons.

Use vector graphics instead

An alternative to creating multiple density-specific versions of an image is to create just one vector graphic. Vector graphics create an image using XML to define paths and colors, instead of using pixel bitmaps. As such, vector graphics can scale to any size without scaling artifacts, though they’re usually best for illustrations such as icons, not photographs.

Vector graphics are often provided as an SVG (Scalable Vector Graphics) file, but Android does not support this format so you must convert SVGs files to Android’s vector drawable format.

You can easily convert an SVG to a vector drawable from Android Studio using Vector Asset Studio as follows:

1. In the Project window, right-click on the res directory and select New > Vector Asset.
2. Select Local file (SVG, PSD).

Locate the file you want to import and make any adjustments.

Figure 3. Importing an SVG with Android Studio

You might notice some errors appear in the Asset Studio window, indicating some properties of the file that vector drawables do not support. But this will not prevent you from importing—the unsupported properties are simply ignored.

Click Next.

On the next screen, confirm the source set where you want the file in your project and click Finish.

Because one vector drawable can be used on all pixel densities, this file goes in your default drawables directory (you don’t need to use density-specific directories):

For more information about creating vector graphics, read the Vector Drawable documentation.

Advice for uncommon density issues

This section describes more about how Android performs scaling for bitmaps on different pixel densities and how you can further control how bitmaps are drawn on different densities. Unless your app manipulates graphics or you have encountered problems when running on different pixel densities, you can ignore this section.

To better understand how you can support multiple densities when manipulating graphics at runtime, you should understand that the system helps ensure the proper scale for bitmaps in the following ways:

Pre-scaling of resources (such as bitmap drawables)

Based on the density of the current screen, the system uses any density-specific resources from your app. If resources are not available in the correct density, the system loads the default resources and scales them up or down as needed. The system assumes that default resources (those from a directory without configuration qualifiers) are designed for the baseline pixel density (mdpi) and will resize those bitmaps to the appropriate size for the current pixel density.

If you request the dimensions of a pre-scaled resource, the system returns values representing the dimensions after scaling. For example, a bitmap designed at 50×50 pixels for an mdpi screen is scaled to 75×75 pixels on an hdpi screen (if there is no alternative resource for hdpi) and the system reports the size as such.

There are some situations in which you might not want Android to pre-scale a resource. The easiest way to avoid pre-scaling is to put the resource in a resource directory with the nodpi configuration qualifier. For example:

When the system uses the icon.png bitmap from this folder, it does not scale it based on the current device density.

Auto-scaling of pixel dimensions and coordinates

You can disable pre-scaling dimensions and images by setting android:anyDensity to «false» in the manifest or programmatically for a Bitmap by setting inScaled to «false» . In this case, the system auto-scales any absolute pixel coordinates and pixel dimension values at draw time. It does this to ensure that pixel-defined screen elements are still displayed at approximately the same physical size as they would be at the baseline pixel density (mdpi). The system handles this scaling transparently to the app and reports the scaled pixel dimensions to the app, rather than physical pixel dimensions.

For instance, suppose a device has a WVGA high-density screen, which is 480×800 and about the same size as a traditional HVGA screen, but it’s running an app that has disabled pre-scaling. In this case, the system will «lie» to the app when it queries for screen dimensions, and report 320×533 (the approximate mdpi translation for the pixel density). Then, when the app does drawing operations, such as invalidating the rectangle from (10,10) to (100, 100), the system transforms the coordinates by scaling them the appropriate amount, and actually invalidate the region (15,15) to (150, 150). This discrepancy may cause unexpected behavior if your app directly manipulates the scaled bitmap, but this is considered a reasonable trade-off to keep the performance of apps as good as possible. If you encounter this situation, read Converting dp units to pixel units.

Usually, you should not disable pre-scaling. The best way to support multiple screens is to follow the basic techniques described in this document.

If your app manipulates bitmaps or directly interacts with pixels on the screen in some other way, you might need to take additional steps to support different pixel densities. For example, if you respond to touch gestures by counting the number of pixels that a finger crosses, you need to use the appropriate density- independent pixel values, instead of actual pixels, but you can easily convert between dp and px values.

Test on all pixel densities

It’s important to test your app on multiple devices with different pixel densities so you can ensure your UI scales correctly. Testing on a physical device is easy but you can also use the Android Emulator if you don’t have access to physical devices for all the different pixel densities.

If you would rather test on a physical device, but don’t want to buy the devices, you can use Firebase Test Lab to access devices in a Google data center.

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник