• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1page.title=Distributing to Specific Screens
2excludeFromSuggestions=true
3parent.title=Supporting Multiple Screens
4parent.link=screens_support.html
5
6@jd:body
7
8<div id="qv-wrapper">
9<div id="qv">
10
11  <h2>Quickview</h2>
12  <ul>
13    <li>If necessary, you can control distribution of your application based on the device
14screen configuration</li>
15  </ul>
16
17  <h2>In this document</h2>
18  <ol>
19    <li><a href="#FilteringHansetApps">Declaring an App is Only for Handsets</a></li>
20    <li><a href="#FilteringTabletApps">Declaring an App is Only for Tablets</a></li>
21    <li><a href="#MultiApks">Publishing Multiple APKs for Different Screens</a></li>
22  </ol>
23
24  <h2>See also</h2>
25  <ol>
26    <li><a
27href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a></li>
28  </ol>
29
30</div>
31</div>
32
33
34
35<p>Although we recommend that you design your application to function properly on multiple
36configurations of screen size and density, you can instead choose to limit the distribution of your
37application to certain types of screens, such as only tablets and other large devices or only
38handsets and similar-sized devices. To do so, you can enable filtering by external services such as
39Google Play by adding elements to your manifest file that specify the screen configurations your
40application supports.</p>
41
42<p>However, before you decide to restrict your application to certain screen configurations, you
43should understand the techniques for <a
44href="{@docRoot}guide/practices/screens_support.html">supporting multiple screens</a> and implement
45them to the best of your ability. By supporting multiple screens, your application can be made
46available to the greatest number of users with different devices, using a single APK.</p>
47
48
49
50<h2 id="FilteringHandsetApps">Declaring an App is Only for Handsets</h2>
51
52<p>Because the system generally scales applications to fit larger screens well, you shouldn't
53need to filter your application from larger screens. As long as you follow the <a
54href="{@docRoot}guide/practices/screens_support.html#screen-independence">Best Practices for Screen
55Independence</a>, your application should work well on larger screens such as tablets. However, you
56might discover that your application can't scale up well or perhaps you've decided to publish two
57versions of your application for different screen configurations. In such a case, you can use the <a
58href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code
59<compatible-screens>}</a> element to manage the distribution of your application based on
60combinations of screen size and density. External services such as Google Play use this
61information to apply filtering to your application, so that only devices that have a screen
62configuration with which you declare compatibility can download your application.</p>
63
64<p>The <a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code
65<compatible-screens>}</a> element must contain one or more {@code <screen>} elements. Each
66{@code <screen>} element specifies a screen configuration with which your application is
67compatible, using both the {@code android:screenSize} and {@code android:screenDensity} attributes.
68Each {@code <screen>} element <strong>must include both attributes</strong> to specify an
69individual screen configuration&mdash;if either attribute is missing, then the element is invalid
70(external services such as Google Play will ignore it).</p>
71
72<p>For example, if your application is compatible with only small and normal size screens,
73regardless of screen density, you must specify eight different {@code <screen>} elements,
74because each screen size has four density configurations. You must declare each one of
75these; any combination of size and density that you do <em>not</em> specify is considered a screen
76configuration with which your application is <em>not</em> compatible. Here's what the manifest
77entry looks like if your application is compatible with only small and normal screen sizes:</p>
78
79<pre>
80&lt;manifest ... >
81    &lt;compatible-screens>
82        &lt;!-- all small size screens -->
83        &lt;screen android:screenSize="small" android:screenDensity="ldpi" />
84        &lt;screen android:screenSize="small" android:screenDensity="mdpi" />
85        &lt;screen android:screenSize="small" android:screenDensity="hdpi" />
86        &lt;screen android:screenSize="small" android:screenDensity="xhdpi" />
87        &lt;!-- all normal size screens -->
88        &lt;screen android:screenSize="normal" android:screenDensity="ldpi" />
89        &lt;screen android:screenSize="normal" android:screenDensity="mdpi" />
90        &lt;screen android:screenSize="normal" android:screenDensity="hdpi" />
91        &lt;screen android:screenSize="normal" android:screenDensity="xhdpi" />
92    &lt;/compatible-screens>
93    ...
94    &lt;application ... >
95        ...
96    &lt;application>
97&lt;/manifest>
98</pre>
99
100<p class="note"><strong>Note:</strong> Although you can also use the <a
101href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code
102<compatible-screens>}</a> element for the reverse scenario (when your application is not
103compatible with smaller screens), it's easier if you instead use the <a
104href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code
105<supports-screens>}</a> as discussed in the next section, because it doesn't require you
106to specify each screen density your application supports.</p>
107
108
109
110
111<h2 id="FilteringTabletApps">Declaring an App is Only for Tablets</h2>
112
113<p>If you don't want your app to be used on handsets (perhaps your app truly makes sense only on a
114large screen) or you need time to optimize it for smaller screens, you can prevent small-screen
115devices from downloading your app by using the <a
116href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code
117<supports-screens>}</a> manifest element.</p>
118
119<p>For example, if you want your application to be available only to tablet devices, you can declare
120the element in your manifest like this:</p>
121
122<pre>
123&lt;manifest ... >
124    &lt;supports-screens android:smallScreens="false"
125                      android:normalScreens="false"
126                      android:largeScreens="true"
127                      android:xlargeScreens="true"
128                      android:requiresSmallestWidthDp="600" />
129    ...
130    &lt;application ... >
131        ...
132    &lt;/application>
133&lt;/manifest>
134</pre>
135
136<p>This describes your app's screen-size support in two different ways:</p>
137
138<ul>
139  <li>It declares that the app does <em>not</em> support the screen sizes "small" and
140"normal", which are traditionally not tablets.</li>
141  <li>It declares that the app requires a screen size with a minimum usable area that is at least
142600dp wide.</li>
143</ul>
144
145<p>The first technique is for devices that are running Android 3.1 or older, because those devices
146declare their size based on generalized screen sizes. The <a
147href="{@docRoot}guide/topics/manifest/supports-screens-element.html#requiresSmallest">{@code
148requiresSmallestWidthDp}</a> attribute is for devices running Android 3.2 and newer, which includes
149the capability for apps to specify size requirements based on a minimum number of
150density-independent pixels available.  In this example, the app declares a minimum width requirement
151of 600dp, which generally implies a 7"-or-greater screen. </p>
152
153<p>Your size choice might be different, of course, based on how well your design works on different
154screen sizes; for example, if your design works well only on screens that are 9" or larger, you
155might require a minimum width of 720dp.</p>
156
157<p>The catch is that you must compile your application against Android 3.2 or higher in order to use
158the <code>requiresSmallestWidthDp</code> attribute. Older versions don't understand this attribute
159and will raise a compile-time error. The safest thing to do is develop your app against the platform
160that matches the API level you've set for <a
161href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#min">minSdkVersion</a
162>. When you're making final preparations to build your release candidate, change the build target to
163Android 3.2 and add the <code>requiresSmallestWidthDp</code> attribute. Android versions older than
1643.2 simply ignore that XML attribute, so there's no risk of a runtime failure.</p>
165
166<p>For more information about why the "smallest width" screen size is
167important for supporting different screen sizes, read <a
168href="http://android-developers.blogspot.com/2011/07/new-tools-for-managing-screen-sizes.html">New
169Tools for Managing Screen Sizes</a>.</p>
170
171<p class="caution"><strong>Caution:</strong> If you use the <a
172href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code
173<supports-screens>}</a> element for the reverse scenario (when your application is not compatible
174with <em>larger</em> screens) and set the larger screen size attributes to {@code "false"}, then
175external services such as Google Play <strong>do not</strong> apply filtering. Your application
176will still be available to larger screens, but when it runs, it will not resize to fit the screen.
177Instead, the system will emulate a handset screen size (about 320dp x 480dp; see <a
178href="{@docRoot}guide/practices/screen-compat-mode.html">Screen Compatibility Mode</a> for more
179information). If you want
180to prevent your application from being downloaded on larger screens, use <a
181href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code
182<compatible-screens>}</a>, as discussed in the previous section about <a
183href="#FilteringHandsetApps">Declaring an App is Only for Handsets</a>.</p>
184
185<p>Remember, you should strive to make your application available to as many devices as possible by
186applying all necessary techniques for <a
187href="{@docRoot}guide/practices/screens_support.html">supporting multiple screens</a>. You should
188use <a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html">{@code
189<compatible-screens>}</a> or <a
190href="{@docRoot}guide/topics/manifest/supports-screens-element.html">{@code
191<supports-screens>}</a> only when you cannot provide compatibility on all screen configurations
192or you have decided to provide different versions of your application for different sets of screen
193configurations.</p>
194
195
196
197<h2 id="MultiApks">Publishing Multiple APKs for Different Screens</h2>
198
199<p>Although we recommend that you publish one APK for your application, Google Play allows
200you to publish multiple APKs for the same
201application when each APK supports a different set of screen configurations (as declared in
202the manifest file). For example, if you want to publish both a handset version and a tablet
203version of your application, but you're unable to make the same APK work for both screen sizes,
204you can actually publish two APKs for the same application listing. Depending on each device's
205screen configuration, Google Play will deliver it the APK that you've declared to support that
206device's screen.</p>
207
208<p>Beware, however, that publishing multiple APKs for the same application is
209considered an advanced feature and <strong>most applications should publish only one
210APK that can support a wide range of device configurations</strong>. Supporting multiple screen
211sizes, especially, is within reason using a single APK, as long as you follow the guide to
212<a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a>.</p>
213
214<p>If you need more information about how to publish multiple APKs on Google Play, read <a
215href="{@docRoot}google/play/publishing/multiple-apks.html">Multiple APK Support</a>.</p>
216