- 5 tips for preparing for Multi-Window in Android N
- Pro-tip 1: Use the right Context
- Pro-tip 2: Handle configuration changes correctly
- Pro-tip 3: Handle all orientations
- Pro-tip 4: Build a responsive UI for all screen sizes
- Pro-tip 5: Activities started by other apps must always support multi-window
- Test all the things!
- Supporting Multiple Screens
- Quickview
- In this document
- Related samples
- See also
- Overview of Screens Support
- Terms and concepts
- Range of screens supported
- Density independence
- How to Support Multiple Screens
- Using configuration qualifiers
- Designing alternative layouts and drawables
- Alternative layouts
- Alternative drawables
- Declaring Tablet Layouts for Android 3.2
- Using new size qualifiers
- Configuration examples
- Declaring screen size support
- Best Practices
- 1. Use wrap_content, fill_parent, or the dp unit for layout dimensions
- 2. Do not use hard-coded pixel values in your application code
- 3. Do not use AbsoluteLayout
- 4. Use size and density-specific resources
- Additional Density Considerations
- Scaling Bitmap objects created at runtime
- Converting dp units to pixel units
- Using pre-scaled configuration values
- How to Test Your Application on Multiple Screens
5 tips for preparing for Multi-Window in Android N
If you’ve been digging through What’s New in Android N, you probably stumbled across multi-window support.
With split-screen multi-window, two apps will be visible side-by-side. Excited to see how this works, I know I immediately scanned through the documentation, looking for what new APIs made this sorcery work.
Turns out, there aren’t many new APIs. A few XML attributes for customizing whether you support multi-window at all and a few Activity methods to check whether you are currently in multi-window mode. So where’s the magic? The magic has been there all along.
And by magic, we mean Android’s resource system. One of the most powerful parts of the resource system is the ability to provide alternate resources — change dimensions, layouts, drawables, menus, etc. based on different qualifiers.
Multi-window takes advantage of the resource system by adjusting the configuration based on the size of your window — screen size is the obvious one, but the smallest width (i.e., the minimum of the width or height) and the orientation are also updated when resizing.
This takes us to the first tip.
Pro-tip 1: Use the right Context
Loading the proper resources requires the proper Context. If you’re using the Activity context for inflating your layouts, retrieving resources, etc, then you’re good to go.
However, if you’re using your Application context for anything UI related, you’ll find that the resources that are loaded are blissfully unaware of multi-window. Besides issues with not using your Activity’s theme, you may be loading the wrong resources entirely! Best to keep your UI stuff with the Activity Context.
Pro-tip 2: Handle configuration changes correctly
With the correct context in hand, you’ll be sure to get the right resources given the size of your window (whether it is full screen as before or split between your app and another). The process for reloading those resources is based on how you handle runtime changes.
The default case is that your whole activity is destroyed and recreated, restoring any state you saved in onSaveInstanceState() and reloading all of the resources/layouts. This has the nice property that you know everything is consistent with the new configuration and that every type of configuration is handled.
It should go without saying that each configuration change should be fast and seamless. Make sure you aren’t doing a lot of work in onResume() and consider using loaders to ensure your data survives configuration changes.
You can still handle the configuration change yourself in which case your Activity (and Fragments) will receive a callback to onConfigurationChanged() instead of being destroyed and recreated and you will need to manually update your views, reload resources, etc.
To catch the multi-window related configuration changes, you’d need to add an android:configChanges attribute to your manifest with at least these values:
Make sure you’re handling every resource that might be changing (as is your responsibility when you take on handling configuration changes yourself).
This includes reloading resources that might have been considered a constant before. Consider the case where you had a dimension in values and in values-sw600dp. In the non-multi-window world, you’d never switch between these two at runtime as the smallest width would never change (it would always be the smallest width of your device). However, with multi-window, you can and will have to switch between these resources as your app resizes.
Pro-tip 3: Handle all orientations
Remember way back in the intro where we talked about the orientation changing while the window resizes? That’s right: even if the device is in landscape, your app might be in ‘portrait’ orientation.
Turns out: “portrait” really just means the height is greater than the width and “landscape” means the width is greater than the height. So it certainly makes sense, with that definition in mind, that your app could transition from one to the other while being resized.
That also means that transitions between orientations should be as smooth as possible. Quoting the split screen material design specs:
Changing a device’s orientation should not cause the UI to change unexpectedly. For example, an app displaying a video in one of the split screens (in portrait mode) should not begin playback in full-screen if the device rotates to landscape mode.
Note: if you’d still want this type of functionality when your app is fullscreen, you’ll be able to use the inMultiWindowMode() method to check exactly which case you’re in.
Locking your screen orientation by using android:screenOrientation is also affected by multi-window. For apps not targeting Android N, adding android:screenOrientation means you will not support multi-window at all — you’ll always force the user out of multi-window mode. Things change a little when you target N — instead of not supporting multi-window at all, any orientation you set via android:screenOrientation is ignored when in multi-window mode.
Keep in mind that locking your orientation at runtime using setRequestedOrientation() will have no effect in multi-window mode, whether you target N or not.
Adding the android:immersive attribute to your Activity’s manifest also disables multi-window on apps not targeting N, with the same rules as android:screenOrientation above.
Pro-tip 4: Build a responsive UI for all screen sizes
Orientation isn’t the only thing that goes into designing for split screen. Multi-window is the first time your tablet UI (you have a tablet UI right? After all, 12.5% of 1.4 billion devices is a lot of devices…) is going to be shrunk down to a miniature size.
If you’ve been building a responsive UI that reacts to the available space and has relatively similar phone and tablet layouts, you’ll find you’ll be well prepared for multi-window. As suggested, scaling the UI down to 220dp wide/tall and building up from that size to the fullscreen size is a something you can do now.
However, if your mobile and tablet UIs are vastly different, don’t overwhelm users by switching between the two — stick with the tablet UI and work on scaling it down. There’s a number of responsive UI patterns you might consider employing to make resizing a seamless experience for your users — again, no N APIs needed.
Pro-tip 5: Activities started by other apps must always support multi-window
In the multi-window world, your whole task is represented by a single window. That’s why if you want to launch an adjacent activity you need to start a new task — new task, new window.
It also means the reverse is true, quoting that same page:
If you launch an activity within a task stack, the activity replaces the activity on the screen, inheriting all of its multi-window properties.
That means if you have an Activity that can be started by other apps, your activity will inherit the same multi-window properties as the calling Activity. This includes attributes such as minimal size. In cases of startActivityForResult(), your Activity must be part of the same task stack and even in the case of an implicit intent, you can’t guarantee that they’ll also include a FLAG_ACTIVITY_NEW_TASK.
Therefore every one of those activities (and any activities started by that Activity) must support multi-window, all the way down the smallest size. Test thoroughly!
Test all the things!
The best way to prepare for multi-window is to test your app. Even without any code changes or going through the process of setting up the Android N SDK, installing your existing app on an Android N device or emulator is a fantastic first step and an easy way to catch low hanging fruit and #BuildBetterApps.
Источник
Supporting Multiple Screens
Quickview
- Android runs on devices that have different screen sizes and densities.
- The screen on which your application is displayed can affect its user interface.
- The system handles most of the work of adapting your app to the current screen.
- You should create screen-specific resources for precise control of your UI.
In this document
Related samples
See also
Android runs on a variety of devices that offer different screen sizes and densities. For applications, the Android system provides a consistent development environment across devices and handles 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 allow you to control your application’s UI for specific screen sizes and densities, in order to optimize your UI design for different screen configurations. For example, you might want a UI for tablets that’s different from the UI for handsets.
Although the system performs scaling and resizing to make your application work on different screens, you should make the effort to optimize your application for different screen sizes and densities. In doing so, you maximize the user experience for all devices and your users believe that your application was actually designed for their devices—rather than simply stretched to fit the screen on their devices.
By following the practices described in this document, you can create an application that displays properly and provides an optimized user experience on all supported screen configurations, using a single .apk file.
Note: The information in this document assumes that your application is designed for Android 1.6 (API Level 4) or higher. If your application supports Android 1.5 or lower, please first read Strategies for Android 1.5.
Also, be aware that Android 3.2 has introduced new APIs that allow you to more precisely control the layout resources your application uses for different screen sizes. These new features are especially important if you’re developing an application that’s optimized for tablets. For details, see the section about Declaring Tablet Layouts for Android 3.2.
Overview of Screens Support
This section provides an overview of Android’s support for multiple screens, including: an introduction to the terms and concepts used in this document and in the API, a summary of the screen configurations that the system supports, and an overview of the API and underlying screen-compatibility features.
Terms and concepts
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.
For simplicity, Android groups all actual screen densities into six generalized densities: low, medium, high, extra-high, extra-extra-high, and extra-extra-extra-high.
Orientation The orientation of the screen from the user’s point of view. This is either landscape or portrait, meaning that the screen’s aspect ratio is either wide or tall, respectively. Be aware that not only do different devices operate in different orientations by default, but the orientation can change at runtime when the user rotates the device. 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. 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: . 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.
Range of screens supported
Starting with Android 1.6 (API Level 4), Android provides support for multiple screen sizes and densities, reflecting the many different screen configurations that a device may have. You can use features of the Android system to optimize your application’s user interface for each screen configuration and ensure that your application not only renders properly, but provides the best user experience possible on each screen.
To simplify the way that you design your user interfaces for multiple screens, Android divides the range of actual screen sizes and densities into:
- A set of four generalized sizes: small, normal, large, and xlarge
Note: Beginning with Android 3.2 (API level 13), these size groups are deprecated in favor of a new technique for managing screen sizes based on the available screen width. If you’re developing for Android 3.2 and greater, see Declaring Tablet Layouts for Android 3.2 for more information.
A set of six generalized densities:
- ldpi (low)
120dpi
mdpi (medium)
160dpi
hdpi (high)
240dpi
xhdpi (extra-high)
320dpi
xxhdpi (extra-extra-high)
480dpi
xxxhdpi (extra-extra-extra-high)
The generalized sizes and densities are arranged around a baseline configuration that is a normal size and mdpi (medium) density. This baseline is based upon the screen configuration for the first Android-powered device, the T-Mobile G1, which has an HVGA screen (until Android 1.6, this was the only screen configuration that Android supported).
Each generalized size and density spans a range of actual screen sizes and densities. For example, two devices that both report a screen size of normal might have actual screen sizes and aspect ratios that are slightly different when measured by hand. Similarly, two devices that report a screen density of hdpi might have real pixel densities that are slightly different. Android makes these differences abstract to applications, so you can provide UI designed for the generalized sizes and densities and let the system handle any final adjustments as necessary. Figure 1 illustrates how different sizes and densities are roughly categorized into the different size and density groups.
Figure 1. Illustration of how Android roughly maps actual sizes and densities to generalized sizes and densities (figures are not exact).
As you design your UI for different screen sizes, you’ll discover that each design requires a minimum amount of space. So, each generalized screen size above has an associated minimum resolution that’s defined by the system. These minimum sizes are in «dp» units—the same units you should use when defining your layouts—which allows the system to avoid worrying about changes in screen density.
- 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: These minimum screen sizes were not as well defined prior to Android 3.0, so you may encounter some devices that are mis-classified between normal and large. These are also based on the physical resolution of the screen, so may vary across devices—for example a 1024×720 tablet with a system bar actually has a bit less space available to the application due to it being used by the system bar.
To optimize your application’s UI for the different screen sizes and densities, you can provide alternative resources for any of the generalized sizes and densities. Typically, you should provide alternative layouts for some of the different screen sizes and alternative bitmap images for different screen densities. At runtime, the system uses the appropriate resources for your application, based on the generalized 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 can handle most of the work of rendering your application on any device screen, provided that you’ve implemented your UI using techniques that allow it to gracefully resize (as described in the Best Practices, below).
Note: The characteristics that define a device’s generalized screen size and density are independent from each other. For example, a WVGA high-density screen is considered a normal size screen because its physical size is about the same as the T-Mobile G1 (Android’s first device and baseline screen configuration). On the other hand, a WVGA medium-density screen is considered a large size screen. Although it offers the same resolution (the same number of pixels), the WVGA medium-density screen has a lower screen density, meaning that each pixel is physically larger and, thus, the entire screen is larger than the baseline (normal size) screen.
Density independence
Your application achieves «density independence» when it preserves the physical size (from the user’s point of view) of user interface elements when displayed on screens with different densities.
Maintaining density independence is important because, without it, a UI element (such as a button) appears physically larger on a low-density screen and smaller on a high-density screen. Such density-related size changes can cause problems in your application layout and usability. Figures 2 and 3 show the difference between an application when it does not provide density independence and when it does, respectively.
Figure 2. Example application without support for different densities, as shown on low, medium, and high-density screens.
Figure 3. Example application with good support for different densities (it’s density independent), as shown on low, medium, and high density screens.
The Android system helps your application achieve density independence in two ways:
- The system scales dp units as appropriate for the current screen density
- The system scales drawable resources to the appropriate size, based on the current screen density, if necessary
In figure 2, the text view and bitmap drawable have dimensions specified in pixels ( px units), so the views are physically larger on a low-density screen and smaller on a high-density screen. This is because although the actual screen sizes may be the same, the high-density screen has more pixels per inch (the same amount of pixels fit in 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 a medium-density screen, the device with a medium-density screen looks the same as it does in figure 2. For the low-density and high-density screens, however, the system scales the density-independent pixel values down and up, respectively, to fit the screen as appropriate.
In most cases, you can ensure density independence in your application simply by specifying all layout dimension values in density-independent pixels ( dp units) or with «wrap_content» , as appropriate. The system then scales bitmap drawables as appropriate in order to display at the appropriate size, based on the appropriate scaling factor for the current screen’s density.
However, bitmap scaling can result in blurry or pixelated bitmaps, which you might notice in the above screenshots. 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 use those instead of resizing the bitmap designed for medium-density screens. The following section describes more about how to supply alternative resources for different screen configurations.
How to Support Multiple Screens
The foundation of Android’s support for multiple screens is its ability to manage the rendering of an application’s layout and bitmap drawables in an appropriate way for the current screen configuration. The system handles most of the work to render your application properly on each screen configuration by scaling layouts to fit the screen size/density and scaling bitmap drawables for the screen density, as appropriate. To more gracefully handle different screen configurations, however, you should also:
- Explicitly declare in the manifest which screen sizes your application supports
By declaring which screen sizes your application supports, you can ensure that only devices with the screens you support can download your application. Declaring support for different screen sizes can also affect how the system draws your application on larger screens—specifically, whether your application runs in screen compatibility mode.
To declare the screen sizes your application supports, you should include the element in your manifest file.
Provide different layouts for different screen sizes
By default, Android resizes your application layout to fit the current device screen. In most cases, this works fine. In other cases, your UI might not look as good and might need adjustments for different screen sizes. For example, on a larger screen, you might want to adjust the position and size of some elements to take advantage of the additional screen space, or on a smaller screen, you might need to adjust sizes so that everything can fit on the screen.
The configuration qualifiers you can use to provide size-specific resources are small , normal , large , and xlarge . For example, layouts for an extra-large screen should go in layout-xlarge/ .
Beginning with Android 3.2 (API level 13), the above size groups are deprecated and you should instead use the sw dp configuration qualifier to define the smallest available width required by your layout resources. For example, if your multi-pane tablet layout requires at least 600dp of screen width, you should place it in layout-sw600dp/ . Using the new techniques for declaring layout resources is discussed further in the section about Declaring Tablet Layouts for Android 3.2.
Provide different bitmap drawables for different screen densities
By default, Android scales your bitmap drawables ( .png , .jpg , and .gif files) and Nine-Patch drawables ( .9.png files) so that they render at the appropriate physical size on each device. For example, if your application provides bitmap drawables only for the baseline, medium screen density (mdpi), then the system scales them up when on a high-density screen, and scales them down when on a low-density screen. This scaling can cause artifacts in the bitmaps. To ensure your bitmaps look their best, you should include alternative versions at different resolutions for different screen densities.
The configuration qualifiers (described in detail below) that you can use for density-specific resources are ldpi (low), mdpi (medium), hdpi (high), xhdpi extra-high), xxhdpi (extra-extra-high), and xxxhdpi (extra-extra-extra-high). For example, bitmaps for high-density screens should go in drawable-hdpi/ .
Note: The mipmap-xxxhdpi qualifier is necessary only to provide a launcher icon that can appear larger than usual on an xxhdpi device. You do not need to provide xxxhdpi assets for all your app’s images.
Some devices scale-up the launcher icon by as much as 25%. For example, if your highest density launcher icon image is already extra-extra-high-density, the scaling process will make it appear less crisp. So you should provide a higher density launcher icon in the mipmap-xxxhdpi directory, which the system uses instead of scaling up a smaller version of the icon.
See Provide an xxx-high-density launcher icon for more information. You should not use the xxxhdpi qualifier for UI elements other than the launcher icon.
Note: Place all your launcher icons in the res/mipmap-[density]/ folders, rather than the res/drawable-[density]/ folders. The Android system retains the resources in these density-specific folders, such as mipmap-xxxhdpi, regardless of the screen resolution of the device where your app is installed. This behavior allows launcher apps to pick the best resolution icon for your app to display on the home screen. For more information about using the mipmap folders, see Managing Projects Overview.
The size and density configuration qualifiers correspond to the generalized sizes and densities described in Range of screens supported, above.
Note: If you’re not familiar with configuration qualifiers and how the system uses them to apply alternative resources, read Providing Alternative Resources for more information.
At runtime, the system ensures the best possible display on the current screen with the following procedure for any given resource:
- The system uses the appropriate alternative resource
Based on the size and density of the current screen, the system uses any size- and density-specific resource provided in your application. For example, if the device has a high-density screen and the application requests a drawable resource, the system looks for a drawable resource directory that best matches the device configuration. Depending on the other alternative resources available, a resource directory with the hdpi qualifier (such as drawable-hdpi/ ) might be the best match, so the system uses the drawable resource from this directory.
If no matching resource is available, the system uses the default resource and scales it up or down as needed to match the current screen size and density
The «default» resources are those that are not tagged with a configuration qualifier. For example, the resources in drawable/ are the default drawable resources. The system assumes that default resources are designed for the baseline screen size and density, which is a normal screen size and a medium-density. As such, the system scales default density resources up for high-density screens and down for low-density screens, as appropriate.
However, when the system is looking for a density-specific resource and does not find it in the density-specific directory, it won’t always use the default resources. The system may instead use one of the other density-specific resources in order to provide better results when scaling. For example, when looking for a low-density resource and it is not available, the system prefers to scale-down the high-density version of the resource, because the system can easily scale a high-density resource down to low-density by a factor of 0.5, with fewer artifacts, compared to scaling a medium-density resource by a factor of 0.75.
For more information about how Android selects alternative resources by matching configuration qualifiers to the device configuration, read How Android Finds the Best-matching Resource.
Using configuration qualifiers
Android supports several configuration qualifiers that allow you to control how the system selects your alternative resources based on the characteristics of the current device screen. A configuration qualifier is a string that you can append to a resource directory in your Android project and specifies the configuration for which the resources inside are designed.
To use a configuration qualifier:
- Create a new directory in your project’s res/ directory and name it using the format:
- is the standard resource name (such as drawable or layout ).
- is a configuration qualifier from table 1, below, specifying the screen configuration for which these resources are to be used (such as hdpi or xlarge ).
You can use more than one at a time—simply separate each qualifier with a dash.
For example, xlarge is a configuration qualifier for extra-large screens. When you append this string to a resource directory name (such as layout-xlarge ), it indicates to the system that these resources are to be used on devices that have an extra-large screen.
Table 1. Configuration qualifiers that allow you to provide special resources for different screen configurations.
Screen characteristic | Qualifier | Description |
---|---|---|
Size | small | Resources for small size screens. |
normal | Resources for normal size screens. (This is the baseline size.) | |
large | Resources for large size screens. | |
xlarge | Resources for extra-large size screens. | |
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-extra-high-density (xxxhdpi) uses ( 640dpi). Use this for the launcher icon only, see note above. |
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. | |
Orientation | land | Resources for screens in the landscape orientation (wide aspect ratio). |
port | Resources for screens in the portrait orientation (tall aspect ratio). | |
Aspect ratio | long | Resources for screens that have a significantly taller or wider aspect ratio (when in portrait or landscape orientation, respectively) than the baseline screen configuration. |
notlong | Resources for use screens that have an aspect ratio that is similar to the baseline screen configuration. |
Note: If you’re developing your application for Android 3.2 and higher, see the section about Declaring Tablet Layouts for Android 3.2 for information about new configuration qualifiers that 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 real screen sizes and densities, see Range of Screens Supported, earlier in this document.
For example, the following application resource directories provide different layout designs for different screen sizes and different drawables. Use the mipmap/ folders for launcher icons.
For more information about how to use alternative resources and a complete list of configuration qualifiers (not just for screen configurations), see Providing Alternative Resources.
Be aware that, when the Android system picks which resources to use at runtime, it uses certain logic to determine the «best matching» resources. That is, the qualifiers you use don’t have to exactly match the current screen configuration in all cases in order for the system to use them. Specifically, when selecting resources based on the size qualifiers, the system will use resources designed for a screen smaller than the current screen if there are no resources that better match (for example, a large-size screen will use normal-size screen resources if necessary). However, if the only available resources are larger than the current screen, the system will not use them and your application will crash if no other resources match the device configuration (for example, if all layout resources are tagged with the xlarge qualifier, but the device is a normal-size screen). For more information about how the system selects resources, read How Android Finds the Best-matching Resource.
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.
Designing alternative layouts and drawables
The types of alternative resources you should create depends on your application’s needs. Usually, you should use the size and orientation qualifiers to provide alternative layout resources and use the density qualifiers to provide alternative bitmap drawable resources.
The following sections summarize how you might want to use the size and density qualifiers to provide alternative layouts and drawables, respectively.
Alternative layouts
Generally, you’ll know whether you need alternative layouts for different screen sizes once you test your application on different screen configurations. For example:
- When testing on a small screen, you might discover that your layout doesn’t quite fit on the screen. For example, a row of buttons might not fit within the width of the screen on a small screen device. In this case you should provide an alternative layout for small screens that adjusts the size or position of the buttons.
- When testing on an extra-large screen, you might realize that your layout doesn’t make efficient use of the big screen and is obviously stretched to fill it. In this case, you should provide an alternative layout for extra-large screens that provides a redesigned UI that is optimized for bigger screens such as tablets.
Although your application should work fine without an alternative layout on big screens, it’s quite important to users that your application looks as though it’s designed specifically for their devices. If the UI is obviously stretched, users are more likely to be unsatisfied with the application experience.
To summarize, you should be sure that your application layout:
- Fits on small screens (so users can actually use your application)
- Is optimized for bigger screens to take advantage of the additional screen space
- Is optimized for both landscape and portrait orientations
If your UI uses bitmaps that need to fit the size of a view even after the system scales the layout (such as the background image for a button), you should use Nine-Patch bitmap files. A Nine-Patch file is basically a PNG file in which you specify two-dimensional regions that are stretchable. When the system needs to scale the view in which the bitmap is used, the system stretches the Nine-Patch bitmap, but stretches only the specified regions. As such, you don’t need to provide different drawables for different screen sizes, because the Nine-Patch bitmap can adjust to any size. You should, however, provide alternate versions of your Nine-Patch files for different screen densities.
Alternative drawables
Figure 4. Relative sizes for bitmap drawables that support each density.
Almost every application should have alternative drawable resources for different screen densities, because almost every application has a launcher icon and that icon should look good on all screen densities. Likewise, if you include other bitmap drawables in your application (such as for menu icons or other graphics in your application), you should provide alternative versions or each one, for different densities.
Note: You only need to provide density-specific drawables for bitmap files ( .png , .jpg , or .gif ) and Nine-Patch files ( .9.png ). If you use XML files to define shapes, colors, or other drawable resources, you should put one copy in the default drawable directory ( drawable/ ).
To create alternative bitmap drawables for different densities, you should follow the 3:4:6:8:12:16 scaling ratio between the six generalized 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
- 48×48 (1.0x baseline) for medium-density
- 72×72 (1.5x) for high-density
- 96×96 (2.0x) for extra-high-density
- 180×180 (3.0x) for extra-extra-high-density
- 192×192 (4.0x) for extra-extra-extra-high-density (launcher icon only; see note above)
For more information about designing icons, see the Icon Design Guidelines, which includes size information for various bitmap drawables, such as launcher icons, menu icons, status bar icons, tab icons, and more.
Declaring Tablet Layouts for Android 3.2
For the first generation of tablets running Android 3.0, the proper way to declare tablet layouts was to put them in a directory with the xlarge configuration qualifier (for example, res/layout-xlarge/ ). In order to accommodate other types of tablets and screen sizes—in particular, 7″ tablets—Android 3.2 introduces a new way to specify resources for more discrete screen sizes. The new technique is based on the amount of space your layout needs (such as 600dp of width), rather than trying to make your layout fit the generalized size groups (such as large or xlarge).
The reason designing for 7″ tablets is tricky when using the generalized size groups is that a 7″ tablet is technically in the same group as a 5″ handset (the large group). While these two devices are seemingly close to each other in size, the amount of space for an application’s UI is significantly different, as is the style of user interaction. Thus, a 7″ and 5″ screen should not always use the same layout. To make it possible for you to provide different layouts for these two kinds of screens, Android now allows you to specify your layout resources based on the width and/or height that’s actually available for your application’s layout, specified in dp units.
For example, after you’ve designed the layout you want to use for tablet-style devices, you might determine that the layout stops working well when the screen is less than 600dp wide. This threshold thus becomes the minimum size that you require for your tablet layout. As such, you can now specify that these layout resources should be used only when there is at least 600dp of width available for your application’s UI.
You should either pick a width and design to it as your minimum size, or test what is the smallest width your layout supports once it’s complete.
Note: Remember that all the figures used with these new size APIs are density-independent pixel (dp) values and your layout dimensions should also always be defined using dp units, because what you care about is the amount of screen space available after the system accounts for screen density (as opposed to using raw pixel resolution). For more information about density-independent pixels, read Terms and concepts, earlier in this document.
Using new size qualifiers
The different resource configurations that you can specify based on the space available for your layout are summarized in table 2. These new qualifiers offer you more control over the specific screen sizes your application supports, compared to the traditional screen size groups (small, normal, large, and xlarge).
Note: The sizes that you specify using these qualifiers are not the actual screen sizes. Rather, the sizes are for the width or height in dp units that are available to your activity’s window. The Android system might use some of the screen for system UI (such as the system bar at the bottom of the screen or the status bar at the top), so some of the screen might not be available for your layout. Thus, the sizes you declare should be specifically about the sizes needed by your activity—the system accounts for any space used by system UI when declaring how much space it provides for your layout. Also beware that the Action Bar is considered a part of your application’s window space, although your layout does not declare it, so it reduces the space available for your layout and you must account for it in your design.
Table 2. New configuration qualifiers for screen size (introduced in Android 3.2).
Screen configuration | Qualifier values | Description | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
smallestWidth | sw dp Examples: | |||||||||||||||||||||||
Available screen width | w dp Examples: | |||||||||||||||||||||||
Available screen height | h dp Examples: |
High density (240), hdpi | Extra-high-density (320), xhdpi | |||
---|---|---|---|---|
Small screen | QVGA (240×320) | 480×640 | ||
Normal screen | WQVGA400 (240×400) WQVGA432 (240×432) | HVGA (320×480) | WVGA800 (480×800) WVGA854 (480×854) 600×1024 | 640×960 |
Large screen | WVGA800** (480×800) WVGA854** (480×854) | WVGA800* (480×800) WVGA854* (480×854) 600×1024 | ||
Extra-Large screen | 1024×600 | WXGA (1280×800) † 1024×768 1280×768 | 1536×1152 1920×1152 1920×1200 | 2048×1536 2560×1536 2560×1600 |
* To emulate this configuration, specify a custom density of 160 when creating an AVD that uses a WVGA800 or WVGA854 skin. ** To emulate this configuration, specify a custom density of 120 when creating an AVD that uses a WVGA800 or WVGA854 skin. † This skin is available with the Android 3.0 platform |
To see the relative numbers of active devices that support any given screen configuration, see the Screen Sizes and Densities dashboard.
Figure 7. Size and density options you can set, when starting an AVD from the AVD Manager.
We also recommend that you test your application in an emulator that is set up to run at a physical size that closely matches an actual device. This makes it a lot easier to compare the results at various sizes and densities. To do so you need to know the approximate density, in dpi, of your computer monitor (for instance, a 30″ Dell monitor has a density of about 96 dpi). When you launch an AVD from the AVD Manager, you can specify the screen size for the emulator and your monitor dpi in the Launch Options, as shown in figure 7.
If you would like to test your application on a screen that uses a resolution or density not supported by the built-in skins, you can create an AVD that uses a custom resolution or density. When creating the AVD from the AVD Manager, specify the Resolution, instead of selecting a Built-in Skin.
If you are launching your AVD from the command line, you can specify the scale for the emulator with the -scale option. For example:
To refine the size of the emulator, you can instead pass the -scale option a number between 0.1 and 3 that represents the desired scaling factor.
For more information about creating AVDs from the command line, see Managing AVDs from the Command Line.
Источник