A comprehensive summary of Android adaptation problems

Support multiple screens

Android runs on a variety of devices with different screen sizes and densities. For applications, the Android system provides a consistent development environment across different devices, handling most of the work to adjust each application's user interface to the screen on which it is displayed. At the same time, the system provides APIs that can be used to control the application's UI for specific screen sizes and densities to optimize UI design for different screen configurations. For example, you may want a tablet UI that is different from a phone UI.

Although the system scales and resizes your app to fit different screens, you should optimize your app for different screen sizes and densities. This maximizes the user experience on all devices, and users will feel that your app is actually designed for their device, rather than simply stretched to fit their device screen.

By following the practices described in this document, you can create a normal display application and then use a single .apk file to provide an optimized user experience on all supported screen configurations.

Note: The information in this document assumes that your application is designed for Android 1.6 (API Level 4) or higher.

Also note that Android 3.2 introduces new APIs that give you more precise control over the layout resources your app uses for different screen sizes. These new features are especially important if you're developing an app optimized for tablets.

Screen support overview

This section provides an overview of Android's support for multiple screens, including: an introduction to the terminology and overviews used in this document and the API, a summary of the screen configurations supported by the system, and an overview of the API and basic screen compatibility features.

Terms and concepts

Screen size

The actual physical size measured diagonally across the screen.

For simplicity, Android groups all actual screen sizes into four general sizes: small, normal, large, and xlarge.

Screen density

The amount of pixels in the physical area of ​​a screen; often referred to as dpi (dots per inch). For example, a "low" density screen has fewer pixels in a given physical area than a "normal" or "high" density screen.

For simplicity, Android groups all screen densities into six general densities: low, medium, high, extra high, extra extra high, and extra extra extra high.

direction

The orientation of the screen from the user's perspective, that is, landscape or portrait, indicating whether the screen's aspect ratio is wide or tall, respectively. Note that not only do different devices operate in different orientations by default, but the orientation can change at runtime as the user rotates the device.

Resolution

The total number of physical pixels on the screen. When adding support for multiple screens, your app does not work directly with resolutions; instead, it should focus only on the screen sizes and densities specified by the generic size and density groups.

Density-independent pixels (dp)

A virtual pixel unit that should be used when defining UI layouts, to express layout dimensions or positions in a density-independent manner.

A density-independent pixel is equal to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for "medium" density screens. At runtime, the system transparently handles any scaling of the dp unit as needed 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 is equal to 1.5 physical pixels. You should always use dp units when defining your app's UI to ensure that your UI displays properly on screens of different densities.

Supported screen range

Starting with Android 1.6 (API Level 4), Android supports multiple screen sizes and densities, reflecting the many different screen configurations that a device may have. You can use the features of the Android system to optimize your app's user interface for various screen configurations, ensuring that your app not only renders properly, but also provides the best user experience on each screen.

To simplify the way you design user interfaces for multiple screens, Android divides the range of actual screen sizes and densities into:

Four universal sizes: small, normal, large and extra large

Note: Starting with Android 3.2 (API level 13), these size groups are deprecated in favor of a new technique that manages screen size based on the available screen width. If developing for Android 3.2 and higher, see Declaring Tablet Layouts for Android 3.2 for more information.

Six common densities:

ldpi(low)~120dpi

mdpi(medium)~160dpi

hdpi (high) ~ 240dpi

xhdpi (ultra high) ~ 320dpi

xxhdpi (super high) ~ 480dpi

xxxhdpi (super super high) ~ 640dpi

Common sizes and densities are arranged according to a baseline configuration, which is normal size and mdpi (medium) density. This baseline is based on the screen configuration of the first generation Android device (T-Mobile G1), which has an HVGA screen (prior to Android 1.6, this was the only screen configuration supported by Android).

Each generic size and density covers a range of actual screen sizes and densities. For example, two devices that both report a normal screen size might have slightly different actual screen sizes and aspect ratios when measured manually. Similarly, two devices that report an hdpi screen density might have slightly different actual pixel densities. Android abstracts these differences to your app, allowing you to provide a UI designed for a generic size and density and let the system handle any final adjustments as needed. Figure 1 illustrates how different sizes and densities can be roughly categorized into size and density groups.

Figure 1. Illustration of how Android roughly maps actual sizes and densities to common sizes and densities (the data is not exact).

When designing your UI for different screen sizes, you'll find that each design requires a minimum amount of space. Therefore, each of the common screen sizes above is associated with a system-defined minimum resolution. These minimum sizes are expressed in "dp" units—the same units should be used when defining your layouts—so that the system doesn't have to worry about changes in screen density.

Extra large 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: These minimum screen sizes were not properly defined prior to Android 3.0, so some devices might misclassify when transitioning between normal and large screens. These sizes are also based on the physical resolution of the screen, so they can vary between devices — for example, a 1024x720 tablet with a system status bar will have less space available for apps because of the space taken up by the system status bar.

To optimize your app's UI for different screen sizes and densities, you can provide alternative resources for any common size and density. Typically, you should provide alternative layouts for certain different screen sizes and alternative bitmap images for different screen densities. At runtime, the system uses the appropriate resources for your app based on the common size or density of the current device screen.

You do not need to provide alternative resources for every combination of screen size and density. The system provides robust compatibility features that handle most of the work of rendering your app on any device screen, provided that you have implemented your UI using techniques that resize appropriately (as described in the best practices below).

Note: The characteristics that define a device's generic screen size and density are independent of each other. For example, a WVGA high-density screen is considered a normal-size screen because its physical dimensions are approximately the same as a T-Mobile G1 (Android's first-generation device and the baseline screen configuration). On the other hand, a WVGA medium-density screen is considered a large-size screen. Although it offers the same resolution (same number of pixels), the WVGA medium-density screen has a lower screen density, meaning that each pixel is actually larger, so the entire screen is larger than the baseline (normal-size) screen.

Density independence

An app is "density independent" if it maintains the physical size of its user interface elements (from the user's perspective) when displayed on screens of different densities.

Maintaining density independence is important because without this feature, UI elements (such as buttons) appear larger on low-density screens and smaller on high-density screens. These density-dependent size changes can cause problems for app layout and usability. Figures 2 and 3 show the difference between an app without density independence and an app with density independence, respectively.

Figure 2. How a sample app without support for different densities would appear on low-, medium-, and high-density screens.

Figure 3. An example app with good density support (density independence) appears on low-, medium-, and high-density screens.

The Android system helps your app achieve density independence in two ways:

The system expands the number of dp units according to the current screen density

The system scales drawable resources to the appropriate size, if necessary, based on the current screen density.

In figure 2, the text view and bitmap drawable have dimensions specified in pixels (px units), so the physical size of the views is larger on low-density screens and smaller on high-density screens. This is because, although the actual screen size may be the same, a high-density screen has more pixels per inch (the same number of pixels fit into a smaller area). In figure 3, the layout dimensions are specified in density-independent pixels (dp units). Because the baseline for density-independent pixels is medium-density screens, a device with a medium-density screen would look the same as in figure 2. But for low-density and high-density screens, the system increases and decreases the density-independent pixel values, respectively, to fit the screen.

In most cases, ensuring screen independence in your app is as simple as specifying all layout size values ​​in appropriate density-independent pixels (dp units) or "wrap_content". The system then scales your bitmap drawables appropriately to display them at the appropriate size, based on the scaling factor appropriate for the current screen density.

However, bitmap scaling can result in blurry or pixelated bitmaps, which you might have noticed in the screenshots above. To avoid these artifacts, you should provide alternative bitmap resources for different densities. For example, you should provide higher-resolution bitmaps for high-density screens, and the system will then use these bitmaps for medium-density screens without resizing the bitmaps. The next section details how to provide alternative resources for different screen configurations.

How to support multiple screens

Fundamental to Android's support for multiple screens is its ability to manage your app's layouts and bitmap drawables to render appropriately for the current screen configuration. The system handles most of the work of rendering your app on each screen configuration by appropriately scaling layouts to fit the screen size/density and scaling bitmap drawables based on the screen density. However, to more appropriately handle different screen configurations, you should also:

Explicitly declare in your manifest which screen sizes your app supports

By declaring which screen sizes your app supports, you ensure that only devices with supported screens can download your app. Declaring support for different screen sizes can also affect how the system draws your app on larger screens—specifically, whether your app runs in screen compatibility mode.

To declare the screen sizes that your application supports, include the supports-screens element in your manifest file.

Provide different layouts for different screen sizes

By default, Android resizes your app's layout to fit the current device screen. Most of the time this works well. But sometimes your UI might not look good and need to be adjusted for different screen sizes. For example, on a larger screen you might want to adjust the position and size of certain elements to take advantage of the additional screen space, or on a smaller screen you might need to resize so that everything fits on the screen.

Configuration qualifiers that can be used to provide size-specific resources include small, normal, large, and xlarge. For example, a layout for an extra-large screen should use layout-xlarge/.

Starting with Android 3.2 (API level 13), the above size groups are deprecated and you should instead use the swdp configuration qualifier to define the minimum width at which layout resources are available. For example, if a multi-pane tablet layout requires at least 600dp of screen width, it should be placed in layout-sw600dp/. The Declaring Tablet Layouts for Android 3.2 section further discusses how to declare layout resources using the new technique.

Providing different bitmap drawables for different screen densities

By default, Android scales bitmap drawables (.png, .jpg, and .gif files) and nine-grid drawables (.9.png files) so that they appear at the appropriate physical size on each device. For example, if your app only provides bitmap drawables for a baseline medium-density screen (mdpi), the bitmaps will be enlarged on high-density screens and reduced on low-density screens. This scaling can cause artifacts in the bitmap. To ensure the best display of your bitmaps, include alternative versions at different resolutions for different screen densities.

Configuration qualifiers (described in detail below) that can be used for density-specific resources include ldpi (low), mdpi (medium), hdpi (high), xhdpi (extra high), xxhdpi (extra extra high), and xxxhdpi (extra extra extra high). For example, a bitmap for a high-density screen should use drawable-hdpi/.

Note: You only need to provide the mipmap-xxxhdpi qualifier if you want to provide a larger-than-normal bitmap launcher icon on xxhdpi devices. You do not need to provide xxxhdpi assets for all of your app's images.

Some devices will scale launcher icons up to 25%. For example, if your highest-density launcher icon is already extra-extra-high-density, the scaling process will reduce its clarity. Therefore, provide higher-density launcher icons in the mipmap-xxxhdpi directory, and the system will scale up the smaller icon instead.

See Providing xxx-high-density launcher icons for details. You should not use the xxxhdpi qualifier for UI elements other than launcher icons.

Note: Place all of your launcher icons in res/mipmap-[density]/ folders, not res/drawable-[density]/ folders. The Android system keeps resources in these density-specific folders, such as mipmap-xxxhdpi, regardless of the screen resolution of the device on which your app is installed. This behavior lets the launcher app choose the best resolution icon for your app to display on the Home screen. For more information about working with mipmap folders, see the Managing Projects Overview.

The size and density configuration qualifiers correspond to the common sizes and densities described earlier in Supported range of screens.

At runtime, the system ensures that any given resource maintains the best possible display quality on the current screen by:

The system uses appropriate alternative resources

Depending on the size and density of the current screen, the system uses any size- and density-specific resources provided by your app. For example, if the device has a high-density screen and your app requests drawable resources, the system looks for a drawable resource directory that best matches the device configuration. Depending on the other alternative resources available, a resource directory that includes the hdpi qualifier (for example, drawable-hdpi/) might be the best match, so the system uses the drawable resources in this directory.

If no matching resources are found, the system uses the default resources, scaling them up or down as necessary to match the current screen size and density.

"Default" resources are resources that are not marked with a configuration qualifier. For example, resources in drawable/ are default drawable resources. The system assumes that the default resources are designed for a baseline screen size and density, which is a normal screen size and medium density. Therefore, the system scales the default density resources up for high-density screens and down for low-density screens.

When the system looks for a density-specific resource and doesn't find it in a density-specific directory, the default resource isn't necessarily used. The system might instead use a different density-specific resource that provides better results when scaling. For example, when a low-density resource is looked for and it's not available, the system scales down the high-density version of the resource because the system can easily scale down a high-density resource by a factor of 0.5 to a low-density resource with fewer artifacts than scaling down a medium-density resource by a factor of 0.75.

For more information about how Android selects alternative resources by matching configuration qualifiers to device configurations, see How Android Finds the Best Matching Resource.

Using Configuration Qualifiers

Android supports several configuration qualifiers that give you control over how the system selects alternative resources based on the characteristics of the current device screen. Configuration qualifiers are strings that can be appended to resource directories in your Android project to specify the configuration in which the resource is designed.

To use configuration qualifiers:

Create a new directory in your project's res/ directory and name it using the following format: <resources_name>-<qualifier>

<resources_name> is a standard resource name (such as drawable or layout).

<qualifier> is a configuration qualifier from Table 1 below that specifies the screen configuration (for example, hdpi or xlarge) for which these resources are to be used.

You can use more than one <qualifier> at a time — just separate each qualifier with a dash.

Save the appropriate configuration specific resources in this new directory. These resource files must be named exactly like the default resource files.

For example, xlarge is a configuration qualifier for extra-large screens. When you append this string to a resource directory name (e.g. layout-xlarge), it points the system to use these resources on devices with extra-large screens.

Table 1. Configuration qualifiers that can be used to provide special resources for different screen configurations.

Screen Characteristics Qualifier Description Size small Resources for small screens.

normal Resources for normal-sized screens. (This is the baseline size.)

large Resources for large screen sizes.

xlarge Resources for extra-large screen sizes.

density 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-high-density (xxxhdpi) screens (~640dpi). This qualifier applies only to launcher icons, see the note above.

nodpi Resources that apply to all densities. These are density-independent resources. The system does not scale resources marked with this qualifier, regardless of the density of the current screen.

tvdpi is for resources that are for screens with densities between mdpi and hdpi (about 213dpi). It is not a "primary" density group, it is primarily for TVs, and most apps don't need it - for most apps, it is sufficient to provide both mdpi and hdpi resources, and the system will scale them as needed. If you find that you must provide tvdpi resources, you should resize them by a factor of 1.33*mdpi. For example, a 100px x 100px image for an mdpi screen should be equivalent to 133px x 133px for tvdpi.

Direction land is for resources with a horizontal screen (aspect ratio).

The orientation port is suitable for resources with a vertical screen (aspect ratio).

Aspect ratio long is intended for resources that are intended for screens with aspect ratios that are significantly taller or wider (in portrait or landscape, respectively) than the baseline screen configuration.

notlong is intended for resources that use screens with aspect ratios similar to the baseline screen configuration.

Note: If you are developing your app for Android 3.2 and higher, see the section about declaring tablet layouts for Android 3.2 to learn about the new configuration qualifiers you should use when declaring layout resources for specific screen sizes (instead of using the size qualifiers in Table 1).

For more information about how these qualifiers roughly correspond to actual screen sizes and densities, see Supported screen ranges earlier in this document.

For example, the following application resource directory provides different layout designs for different screen sizes and different drawable objects. Use the mipmap/ folder to place the launcher icon.

 res/layout/my_layout.xml // layout for normal screen size (" default ")
 res/layout-large/my_layout.xml // layout for large screen size  
 res/layout-xlarge/my_layout.xml // layout for extra-large screen size  
 res/layout-xlarge-land/my_layout.xml // layout for extra-large in landscape orientation
 res/drawable-mdpi/graphic.png // bitmap for medium-density
 res/drawable-hdpi/graphic.png // bitmap for high-density
 res/drawable-xhdpi/graphic.png // bitmap for extra-high-density
 res/drawable-xxhdpi/graphic.png // bitmap for extra-extra-high-density
 res/mipmap-mdpi/my_icon.png // launcher icon for medium-density
 res/mipmap-hdpi/my_icon.png // launcher icon for high-density
 res/mipmap-xhdpi/my_icon.png // launcher icon for extra-high-density
 res/mipmap-xxhdpi/my_icon.png // launcher icon for extra-extra-high-density
 res/mipmap-xxxhdpi/my_icon.png // launcher icon for extra-extra-extra-high-density

Note that when the Android system chooses which resources to use at runtime, it uses specific logic to determine the "best match" resources. That is, the qualifiers you use do not have to exactly match the current screen configuration in all cases for the system to use them. In particular, when selecting resources based on screen size qualifiers, the system will use resources designed for screens smaller than the current screen if no better match is available (for example, a large screen will use standard-sized screen resources if necessary). However, if the only available resources are larger than the current screen, the system will not use those resources, and the app will crash if no other resources match the device configuration (for example, if all layout resources are marked with the xlarge qualifier, but the device has a standard-sized screen).

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

Designing alternative layouts and drawables

The types of alternative resources you should create depend on your app's needs. Typically, you should provide alternative layout resources using size and orientation qualifiers, and alternative bitmap drawable resources using density qualifiers.

The following sections summarize how you might want to use size and density qualifiers to provide alternative layouts and drawables, respectively.

Alternative layouts

Generally speaking, after testing your app on different screen configurations, you'll know if you need alternative layouts for different screen sizes. For example:

When testing on a small screen, you might find that your layout doesn't quite fit on the screen. For example, a row of buttons might not fit on a small device's screen width. In this case, you should provide an alternative layout that resizes or positions the buttons for the small screen.

When testing on an extra-large screen, you may find that your layout does not effectively utilize the large screen and is noticeably stretched to fill the screen. In this case, you should provide an alternative layout for extra-large screens to provide a redesigned UI that is optimized for larger screens (such as tablets).

Although your app will work fine on larger screens without using alternative layouts, it's important for users to feel like your app was designed specifically for their device. If your UI is noticeably stretched, users are likely to be dissatisfied with your app experience.

Moreover, when comparing the horizontal screen test and the vertical screen test, you may find that the UI placed at the bottom in the vertical screen should be located on the right side of the screen in the horizontal screen.

In short, you should ensure that your app layout:

Adapt to small screens (so users can actually use your app)

Optimized for large screens to take advantage of additional screen space

Optimized for both landscape and portrait orientations

If the bitmap used by your UI needs to adapt to the view size even after the system scales the layout (such as the background image of a button), you should use a nine-grid bitmap file. A nine-grid file is basically a PNG file that specifies a stretchable two-dimensional area. When the system needs to scale the view that uses the bitmap, the system stretches the nine-grid bitmap, but only the specified area. Therefore, you do not need to provide different drawable objects for different screen sizes, because the nine-grid bitmap can be adjusted to any size. But you should provide alternative versions of the nine-grid file for different screen densities.

Alternative drawables

Figure 4. Relative sizes of bitmap drawables supported for each density.

Basically every app should have alternative drawable resources for different densities, because basically every app has a launcher icon, and that icon should look good in all screen densities. Similarly, if your app includes other bitmap drawables (such as menu icons or other graphics in your app), you should provide alternative versions for different densities or one version per density.

Note: You only need to provide density-specific drawables for bitmap files (.png, .jpg, or .gif) and nine-grid files (.9.png). If you use an XML file to define shapes, colors, or other drawable resources, you should place a copy in the default drawable directory (drawable/).

To create alternative bitmap drawables for different densities, follow the 3:4:6:8:12:16 scaling ratios between the six common densities. For example, if your bitmap drawable is 48×48 pixels for medium-density screens, all the different sizes should be:

36×36 (0.75x) for low density

48×48 (1.0x baseline) for medium density

72×72 (1.5x) for high density

96×96 (2.0x) for ultra-high density

144×144 (3.0x) for ultra-high density

192×192 (4.0x) for ultra-ultra-high density (launcher icon only; see note above)

For more information on designing icons, see Icon Design Guidelines, which contains sizing information for various bitmap drawables, such as launcher icons, menu icons, status bar icons, tab icons, and more.

Declaring a tablet layout for Android 3.2

For the first generation of tablets running Android 3.0, the correct way to declare tablets was to place them in a directory with the xlarge configuration qualifier (for example, res/layout-xlarge/). To accommodate other types of tablets and screen sizes—particularly 7-inch tablets—Android 3.2 introduces a new way to specify resources for more specific screen sizes. Rather than trying to make your layout fit a generalized size group (such as large or xlarge), the new technique is based on the amount of space your layout requires (for example, 600dp wide).

The reason designing for 7-inch tablets is tricky when using generalized size groups is that 7-inch tablets are technically in the same group as 5-inch phones (the large group). While the two devices appear to be close in size, the amount of space devoted to your app's UI is significantly different, as is the way the user interacts. Therefore, you don't necessarily use the same layout for 7-inch and 5-inch screens. To make it easier for you to provide different layouts for these two screens, Android now allows you to specify layout resources (specified in dp units) based on the width and/or height that is actually available for your app's layout.

For example, after designing a layout for a tablet-style device, you might discover that the layout doesn't work well when the screen width is less than 600dp. This threshold then becomes the minimum size required for a tablet layout. As a result, you can now specify that these layout resources should only be used when there is at least 600dp of width available for the application's UI.

You should either choose one width and design to that minimum size, or test your layout for the smallest supported width once it has been designed.

Note: Remember that all data used by these new size APIs is density-independent pixel (dp) values, and your layout sizes should always be defined using dp units, since you are interested in the amount of screen space available after the system takes into account the screen density (as opposed to using raw pixel resolution). For more information on density-independent pixels, see Terminology and Concepts earlier in this document.

Using the New Size Qualifier

Due to the word limit on WeChat, please click the original link in the lower left corner to read the full content.