page.title=<supports-screens> parent.title=The AndroidManifest.xml File parent.link=manifest-intro.html @jd:body
<supports-screens android:resizeable=["true"| "false"] android:smallScreens=["true" | "false"] android:normalScreens=["true" | "false"] android:largeScreens=["true" | "false"] android:xlargeScreens=["true" | "false"] android:anyDensity=["true" | "false"] android:requiresSmallestWidthDp="integer" android:compatibleWidthLimitDp="integer" android:largestWidthLimitDp="integer"/>
<manifest>
An application "supports" a given screen size if it resizes properly to fill the entire screen. Normal resizing applied by the system 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. However, it's often important that you optimize your application's UI for different screen sizes by providing alternative layout resources. For instance, you might want to modify the layout of an activity when it is on a tablet compared to when running on a handset device.
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 ("zoomed") 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 medium density, then zooming in so that it fills the entire screen. Beware that this causes pixelation and blurring of your UI, so it's better if you optimize your UI for large screens.
Note: Android 3.2 introduces new attributes: {@code android:requiresSmallestWidthDp}, {@code android:compatibleWidthLimitDp}, and {@code android:largestWidthLimitDp}. If you're developing your application for Android 3.2 and higher, you should use these attributes to declare your screen size support, instead of the attributes based on generalized screen sizes.
For more information about how to properly support different screen sizes so that you can avoid using screen compatibility mode with your application, read Supporting Multiple Screens.
This attribute is deprecated. It was introduced to help applications transition from Android 1.5 to 1.6, when support for multiple screens was first introduced. You should not use it.
The default value for this actually varies between some versions, so it's better if you explicitly declare this attribute at all times. Beware that setting it "false" will generally enable screen compatibility mode.
The default value for this actually varies between some versions, so it's better if you explicitly declare this attribute at all times. Beware that setting it "false" will generally enable screen compatibility mode.
This attribute was introduced in API level 9.
For applications that support Android 1.6 (API level 4) and higher, this is "true" by default and you should not set it "false" unless you're absolutely certain that it's necessary for your application to work. The only time it might be necessary to disable this is if your app directly manipulates bitmaps (see the Supporting Multiple Screens document for more information).
For example, a typical handset screen has a smallestWidth of 320dp, a 7" tablet has a smallestWidth of 600dp, and a 10" tablet has a smallestWidth of 720dp. These values are generally the smallestWidth because they are the shortest dimension of the screen's available space.
The size 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 display, the system declares the device's smallestWidth 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 minimum width required by your layout, regardless of the screen's current orientation.
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}).
Caution: The Android system does not pay attention to this attribute, so it does not affect how your application behaves at runtime. Instead, it is used to enable filtering for your application on services such as Google Play. However, Google Play currently does not support this attribute for filtering (on Android 3.2), so you should continue using the other size attributes if your application does not support small screens.
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 emulates only 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 emulates only 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.