page.title=<supports-screens> parent.title=The AndroidManifest.xml File parent.link=manifest-intro.html @jd:body
<supports-screens android:requiresSmallestWidthDp="integer" android:compatibleWidthLimitDp="integer" android:largestWidthLimitDp="integer" android:resizeable=["true"| "false"] android:smallScreens=["true" | "false"] android:normalScreens=["true" | "false"] android:largeScreens=["true" | "false"] android:xlargeScreens=["true" | "false"] android:anyDensity=["true" | "false"] />
<manifest>
An application "supports" a given screen size if it resizes properly to fill the entire screen. By default, the system resizes your application UI to fill the screen if you have set either {@code minSdkVersion} or {@code targetSdkVersion} to {@code "4"} or higher. Normal resizing works well for most applications and you don't have to do any extra work to make your application work on screens larger than a handset device.
In addition to allowing the system to resize your application to fit the current screen, you can optimize your UI for different screen sizes by providing alternative layout resources for different sizes. For instance, you might want to modify the layout of an activity when it is on a tablet or similar device that has an xlarge screen.
However, if your application does not work well when resized to fit different screen sizes, you can use the attributes of the {@code <supports-screens>} element to control whether your application should be distributed to smaller screens or have its UI scaled up to fit larger screens using the system's screen compatibility mode. When you have not designed for larger screen sizes and the normal resizing does not achieve the appropriate results, screen compatibility mode will scale your UI by emulating a normal size screen and then zooming in on it so that it fills the entire screen—thus achieving the same layout as a normal handset device on the large screen (but this usually causes pixelation and blurring of your UI).
For more information about how to properly support different screen sizes so that you can avoid using screen compatibility mode, read Supporting Multiple Screens.
The width against which your value is compared takes into account screen decorations and system UI. For example, if the device has some persistent UI elements on the left or right edge of the display, the system declares the device's available width as one that is smaller than the actual screen size, accounting for these UI elements because those are screen pixels not available for your UI. Thus, the value you use should be the actual smallest width required by your layout.
If your application properly resizes for smaller screen sizes (down to the small size or a minimum width of 320dp), you do not need to use this attribute. Otherwise, you should use a value for this attribute that matches the smallest value used by your application for the smallest screen width qualifier ({@code sw<N>dp}).
For example, a typical handset screen has a minimum width of 320dp, a 7" tablet has a minimum width of 600dp, and a 10" tablet has a minimum width of 720dp. If the smallest available screen width on a device is less than the value you supply here, then the application is considered incompatible with that device. External services such as Android Market use this to determine whether a device is compatible with your application and prevent incompatible devices from installing it.
Beginning with Android 3.2 (API level 13), using this attribute is the preferred way to specify the minimum screen size your application requires, instead of using the other attributes for small, normal, large, and xlarge screens. The advantage of using this attribute is that you have more control over exactly how much screen space your application needs at a minimum in order to properly display its UI, rather than relying on the generalized size groups.
This attribute has no default value. If this attribute is not specified, then any of the old
smallScreens
, normalScreens
,
largeScreens
, or xlargeScreens
attributes are used instead to determine the smallest screen required.
This attribute was introduced in API level 13.
If your application is compatible with all screen sizes and its layout properly resizes, you do not need to use this attribute.
Note: Currently, screen compatibility mode only emulates handset screens with a 320dp width, so screen compatibility mode is not applied if your value for {@code android:compatibleWidthLimitDp} is larger than 320.
This attribute was introduced in API level 13.
If your application is compatible with all screen sizes and its layout properly resizes, you do not need to use this attribute. Otherwise, you should first consider using the {@code android:compatibleWidthLimitDp} attribute. You should use the {@code android:largestWidthLimitDp} attribute only when your application is functionally broken when resized for larger screens and screen compatibility mode is the only way that users should use your application.
Note: Currently, screen compatibility mode only emulates handset screens with a 320dp width, so screen compatibility mode is not applied if your value for {@code android:largestWidthLimitDp} is larger than 320.
This attribute was introduced in API level 13.
To provide the best experience on all screen sizes, you should allow resizing and, if your application does not work well on larger screens, follow the guide to Supporting Multiple Screens to enable additional screen support.
This attribute is deprecated as of API level 13.
This attribute is deprecated as of API level 13.
This attribute is deprecated as of API level 13.
This attribute is deprecated as of API level 13.
This attribute was introduced in API level 9.
This attribute is deprecated as of API level 13.
Based on the "standard" device screen density (medium dpi), the Android framework will scale down application assets by a factor of 0.75 (low dpi screens) or scale them up by a factor of 1.5 (high dpi screens), when you don't provide alternative resources for a specifc screen density. The screen density is expressed as dots-per-inch (dpi).
This attribute is deprecated as of API level 13.