1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
|
page.title=Tablet App Quality Checklist
@jd:body
<div id="qv-wrapper"><div id="qv">
<h2>Checklist</h2>
<ol>
<li><a href="#core-app-quality">1. Test for Basic Tablet App Quality</a></li>
<li><a href="#optimize-layouts">2. Optimize your layouts</a></li>
<li><a href="#use-extra-space">3. Use the extra screen area</a></li>
<li><a href="#use-tablet-icons">4. Use assets designed for tablets</a></li>
<li><a href="#adjust-font-sizes">5. Adjust fonts and touch targets</a></li>
<li><a href="#adjust-widgets">6. Adjust homescreen widgets</a></li>
<li><a href="#offer-full-feature-set">7. Offer the app's full feature set</a></li>
<li><a href="#android-versions">8. Target Android versions properly</a></li>
<li><a href="#hardware-requirements">9. Declare dependencies properly</a></li>
<li><a href="#support-screens">10. Declare tablet screens support</a></li>
<li><a href="#google-play">11. Showcase your tablet UI</a></li>
<li><a href="#google-play-best-practices">12. Follow publishing best practices</a></li>
</ol>
<h2>Testing</h2>
<ol>
<li><a href="#test-environment">Setting Up a Test Environment</a></li>
</ol>
</div></div>
<p>Before you publish an app on Google Play, it's important to make sure that
the app meets the basic expectations of tablet users through compelling features
and an intuitive, well-designed UI. </p>
<p>Tablets are a growing part of the Android installed base that offers new
opportunities for <a
href="{@docRoot}distribute/googleplay/spotlight/tablets.html">user engagement
and monetization</a>. If your app is targeting tablet users, this document helps
you focus on key aspects of quality, feature set, and UI that can have a
significant impact on the app's success. Each focus area is given as checklist
item, with each one comprising several smaller tasks or best practices.</p>
<p>Although the checklist tasks below are numbered for convenience,
you can handle them in any order and address them to the extent that you feel
is right for your app. In the interest of delivering the best possible product
to your customers, follow the checklist recommendations
to the greatest extent possible. </p>
<p>As you move through the checklist, you'll find links to support resources
that can help you address the topics raised in each task.</p>
<h2 id="core-app-quality" style="margin-top:1.5em;">1. Test for basic tablet app quality</h2>
<p>The first step in delivering a great tablet app experience is making sure
that it meets the <em>core app quality criteria</em> for all of the devices
and form factors that the app is targeting. For complete information, see the <a
href="{@docRoot}distribute/googleplay/quality/core.html">Core App Quality Guidelines</a>.
</p>
<p>
Before publishing, also ensure that your app passes several basic
technical checks and launch criteria, such as:
</p>
<ul>
<li><a href="#android-versions">Targets appropriate Android versions</a></li>
<li><a href="#hardware-requirements">Specifies any hardware dependencies properly</a></li>
<li><a href="#support-screens">Declares support for appropriate screens</a></li>
<li><a href="#use-extra-space">Uses all of the available screen space</a></li>
<li><a href="#google-play">Screenshots are uploaded to Google Play</a></li>
</ul>
<p>If your app is already uploaded to the Google Play Developer Console, you
can see how it is doing against these checks
by visiting the <a href="#google-play-optimization-tips">Optimization
Tips page</a>.</p>
<h2 id="optimize-layouts">2. Optimize your layouts for larger screens</h2>
<p>Android makes it easy to develop an app that runs well on a wide range of
device screen sizes and form factors. This broad compatibility works in your
favor, since it helps you design a single app that you can distribute widely to
all of your targeted devices. However, to give your users the best possible
experience on each screen configuration — in particular on tablets
— you need to optimize your layouts and other UI components for each
targeted screen configuration. On tablets, optimizing your UI lets you take
full advantage of the additional screen available, such as to offer new features,
present new content, or enhance the experience in other ways to deepen user
engagement.</p>
<p>If you developed your app for handsets and now want to distribute it to
tablets, you can start by making minor adjustments to your layouts, fonts, and
spacing. In some cases — such as for 7-inch tablets or for a game with
large canvas — these adjustments may be all
you need to make your app look great. In other cases, such as for larger
tablets, you can redesign parts of your UI to replace "stretched UI" with an
efficient multipane UI, easier navigation, and additional content. </p>
<p>Here are some suggestions:</p>
<div style="width:390px;float:right;margin:1.5em;margin-top:0em;">
<img src="{@docRoot}images/training/app-navigation-multiple-sizes-multipane-bad.png"
style="width:390px;padding:4px;margin-bottom:0em;">
<p class="image-caption" style="padding:0em .5em .5em 2em"><span
style="font-weight:500;">Get rid of "stretched" UI</span>: On tablets, single-pane
layouts lead to awkward whitespace and excessive line lengths. Use padding to
reduce the width of UI elements and consider using multi-pane layouts.</p>
</div>
<ul>
<li>Provide custom layouts as needed for <code>large</code> and
<code>xlarge</code> screens. You can also provide layouts that are loaded based
on the screen's <a href="{@docRoot}guide/practices/screens_support.html#NewQualifiers">shortest
dimension</a> or the <a href="{@docRoot}guide/practices/screens_support.html#NewQualifiers">minimum
available width and height</a>. </li>
<li>At a minimum, customize dimensions such as font sizes, margins, spacing for
larger screens, to improve use of space and content legibility. </li>
<li>Adjust positioning of UI controls so that they are easily accessible to
users when holding a tablet, such as toward the sides when in
landscape orientation.</li>
<li>Padding of UI elements should normally be larger on tablets than on handsets. A
<a href="{@docRoot}design/style/metrics-grids.html#48dp-rhythm">48dp rhythm</a> (and a 16dp
grid) is recommended.</li>
<li>Adequately pad text content so that it is not aligned directly along screen edges.
Use a minimum <code>16dp</code> padding around content near screen edges.</li>
</ul>
<p>In particular, make sure that your layouts do not appear "stretched"
across the screen:</p>
<ul>
<li>Lines of text should not be excessively long — optimize for a maximum
100 characters per line, with best results between 50 and 75.</li>
<li>ListViews and menus should not use the full screen width.</li>
<li>Use padding to manage the widths of onscreen elements or switch to a
multi-pane UI for tablets (see next section).</li>
</ul>
<div class="rel-resources">
<h3>
Related resources
</h3>
<ul>
<li>
<a href=
"{@docRoot}design/style/metrics-grids.html">Metrics
and Grids</a>—Android Design document that explains how to create
layouts based on density-independent grids.
</li>
<li>
<a href=
"{@docRoot}design/style/devices-displays.html">Devices
and Displays</a>—Android Design document that explains how to
design a UI that works well on different devices and
screen sizes.
</li>
<li>
<a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple
Screens</a>—Developer documentation that explains the details of
managing UI for best display on multiple screen sizes.
</li>
<li>
<a href=
"{@docRoot}guide/practices/screens_support.html#ConfigurationExamples">
Configuration examples</a>—Examples of how to declare layouts and
other resources for specific screen sizes.
</li>
</ul>
</div>
<h2 id="use-extra-space">3. Take advantage of extra screen area available on tablets</h2>
<div style="width:290px;float:right;margin:1.5em;margin-bottom:0;margin-top:0;">
<img src="{@docRoot}images/training/app-navigation-multiple-sizes-multipane-good.png"
style="width:280px;padding:4px;margin-bottom:0em;">
<p class="image-caption" style="padding:0em .5em .5em 1.5em"><span
style="font-weight:500;">Multi-pane layouts</span> result in a better visual
balance on tablet screens, while offering more utility and legibility.</p>
</div>
<p>Tablet screens provide significantly more screen real estate to your app,
especially when in landscape orientation. In particular, 10-inch tablets offer a
greatly expanded area, but even 7-inch tablets give you more space for
displaying content and engaging users. </p>
<p>As you consider the UI of your app when running on tablets, make sure that it
is taking full advantage of extra screen area available on tablets. Here are
some suggestions:</p>
<ul>
<li>Look for opportunities to include additional content or use an alternative
treatment of existing content.</li>
<li>Use <a href="{@docRoot}design/patterns/multi-pane-layouts.html">multi-pane
layouts</a> on tablet screens to combine single views into a compound view. This
lets you use the additional screen area more efficiently and makes it easier for
users to navigate your app. </li>
<li>Plan how you want the panels of your compound views to reorganize when
screen orientation changes.</li>
<div style="width:490px;margin:1.5em auto 1.5em 0;">
<div style="">
<img src="{@docRoot}images/ui-ex-single-panes.png"
style="width:490px;padding:4px;margin-bottom:0em;" align="middle">
<img src="{@docRoot}images/ui-ex-multi-pane.png" style="width:490px;padding:4px;margin-bottom:0em;">
<p class="image-caption" style="padding:.5em"><span
style="font-weight:500;">Compound views</span> combine several single views from a
handset UI <em>(above)</em> into a richer, more efficient UI for tablets
<em>(below)</em>. </p>
</div>
</div>
<li>While a single screen is implemented as an {@link android.app.Activity}
subclass, consider implementing individual content panels as {@link
android.app.Fragment} subclasses. This lets you
maximize code reuse across different form factors and across screens that
share content.</li>
<li>Decide on which screen sizes you'll use a multi-pane UI, then provide the
different layouts in the appropriate screen size buckets (such as
<code>large</code>/<code>xlarge</code>) or minimum screen widths (such as
<code>sw600dp</code>/<code>sw720</code>).</li>
</ul>
<div class="rel-resources">
<h3>
Related resources
</h3>
<ul>
<li>
<a href="{@docRoot}design/patterns/multi-pane-layouts.html">Multi-pane
Layouts</a>—Android Design guide for using multi-pane UI, including
examples of how to flatten navigation and integrate more content into
your tablet UI.
</li>
<li>
<a href=
"{@docRoot}training/design-navigation/multiple-sizes.html">Planning for Multiple
Touchscreen Sizes</a>—Android Training class that walks you through
the essentials of planning an intuitive, effective navigation for tablets
and other devices.
</li>
<li>
<a href="{@docRoot}training/multiscreen/index.html">Designing for
Multiple Screens</a>—Android Training class that walks you through
the essentials of planning an intuitive, effective navigation for tablets
and other devices.
</li>
</ul>
</div>
<h2 id="use-tablet-icons">4. Use Icons and other assets that are designed
for tablet screens</h2>
<p>So that your app looks its best, make sure to use icons and other bitmap
assets that are created specifically for the densities used by tablet screens.
Specifically, you should create sets of alternative bitmap drawables for each
density in the range commonly supported by tablets.</p>
<p class="table-caption"><strong>Table 1</strong>. Raw asset sizes for icon types.<table>
<tr>
<th>Density </th>
<th colspa>Launcher</th>
<th>Action Bar</th>
<th>Small/Contextual</th>
<th>Notification</th>
</tr>
<tr>
<td><code>mdpi</code></td>
<td>48x48px</td>
<td>32x32px</td>
<td>16x16px</td>
<td>24x24px</td>
</tr>
<tr>
<td><code>hdpi</code></td>
<td>72x72px</td>
<td>48x48px</td>
<td>24x24px</td>
<td>36x36px</td>
</tr>
<tr>
<td><code>tvdpi</code></td>
<td><em>(use hdpi)</em></td>
<td><em>(use hdpi)</em></td>
<td><em>(use hdpi)</em></td>
<td><em>(use hdpi)</em></td>
</tr>
<tr>
<td><code>xhdpi</code></td>
<td>96x96px</td>
<td>64x64px</td>
<td>32x32px</td>
<td>48x48px</td>
</tr>
</table>
<p>Other points to consider: </p>
<ul>
<li>Icons in the action bar, notifications, and launcher should be designed
according to the icon design guidelines and have the same physical size on
tablets as on phones.</li>
<li>Use density-specific <a
href="{@docRoot}guide/topics/resources/providing-resources.html#AlternativeResources">
resource qualifiers</a> to ensure that the proper set of alternative resources
gets loaded.</li>
</ul>
<p style="margin-bottom:.5em;">At a minimum, your app should supply sets of
custom drawables and assets for common tablet screen densities,
tagged with these qualifiers as appropriate:</p>
<ul>
<li><code>hdpi</code>, OR</li>
<li><code>xhdpi</code>, OR</li>
<li><code>xxhdpi</code></li>
</ul>
<div class="rel-resources">
<h3>
Related resources
</h3>
<ul>
<li>
<a href="{@docRoot}design/style/iconography.html">Iconography</a>— Android
Design document that shows how to use various types of icons.
</li>
<li>
<a href=
"{@docRoot}guide/topics/resources/providing-resources.html">Providing
Resources</a>—Developer documentation on how to provide
sets of layouts and drawable resources for specific ranges of device
screens.
</li>
<li>
<a href="{@docRoot}guide/practices/screens_support.html">Supporting
Multiple Screens</a>—API Guide documentation that
explains the details of managing UI for best display on multiple screen
sizes.
</li>
<li>
<a href=
"{@docRoot}training/basics/supporting-devices/screens.html">Supporting Different
Screens</a>—Android Training class that takes you
through the process of optimizing the user experience for different
screen sizes and densities.
</li>
</ul>
</div>
<h2 id="adjust-font-sizes">5. Adjust font sizes and touch targets for tablet screens</h2>
<p>To make sure your app is easy to use on tablets, take some time to adjust the
font sizes and touch targets in your tablet UI, for all of the screen
configurations you are targeting. You can adjust font sizes through <a
href="{@docRoot}guide/topics/ui/themes.html">styleable attributes</a> or <a
href="{@docRoot}guide/topics/resources/more-resources.html#Dimension">dimension
resources</a>, and you can adjust touch targets through layouts and bitmap
drawables, as discussed above. </p>
<p>Here are some considerations:</p>
<ul>
<li>Text should not be excessively large or small on tablet screen sizes and
densities. Make sure that labels are sized appropriately for the UI elements they
correspond to, and ensure that there are no improper line breaks in labels,
titles, and other elements.</li>
<li>The recommended touch-target size for onscreen elements is 48dp (32dp
minimum) — some adjustments may be needed in your tablet UI. Read <a
href="{@docRoot}design/style/metrics-grids.html">Metrics and
Grids
</a> to learn about implementation strategies to help most of your users. To
meet the accessibility needs of certain users, it may be appropriate to use
larger touch targets. </li>
<li>When possible, for smaller icons, expand the touchable area to more than
48dp using {@link android.view.TouchDelegate}
or just centering the icon within the transparent button.</li>
</ul>
<div class="rel-resources">
<h3>
Related resources
</h3>
<ul>
<li>
<a href=
"{@docRoot}design/style/metrics-grids.html">Metrics
and Grids</a> —Android Design document that explains how to arrange
and size touch targets and other UI elements on the screen.
</li>
<li>
<a href="{@docRoot}design/style/typography.html">Typography</a>—Android
Design document that gives an overview of how to use typography in your
apps.
</li>
<li>
<a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple
Screens</a>—Developer documentation that explains the details of
managing UI for best display on multiple screen sizes.
</li>
<li>
<a href="{@docRoot}training/multiscreen/screendensities.html">Supporting
Different Densities</a>—Android Training class that shows you how
to provide sets of layouts and drawable resources for specific ranges of
device screens.
</li>
</ul>
</div>
<h2 id="adjust-widgets">6. Adjust sizes of home screen widgets for tablet screens</h2>
<p>If your app includes a home screen widget, here are a few points to consider
to ensure a great user experience on tablet screens: </p>
<ul>
<li>Make sure that the widget's default height and width are set appropriately
for tablet screens, as well as the minimum and maximum resize height and width.
</li>
<li>The widget should be resizable to 420dp or more, to span 5 or more home
screen rows (if this is a vertical or square widget) or columns (if this is a
horizontal or square widget). </li>
<li>Make sure that 9-patch images render correctly.</li>
<li>Use default system margins.</li>
<li>Set the app's <code>targetSdkVersion</code> to 14 or higher, if
possible.</li>
</ul>
<div class="rel-resources">
<h3>
Related resources
</h3>
<ul>
<li>
<a href="{@docRoot}guide/topics/appwidgets/index.html#MetaData">Adding the
AppWidgetProviderInfo Metadata</a> —API Guide that explains how to
set the height and width dimensions of a widget.
</li>
<li>
<a href="{@docRoot}guide/practices/ui_guidelines/widget_design.html">App Widget
Design Guidelines</a>—API Guide that provides best practices and
techniques for designing and managing the size of widgets.
</li>
</ul>
</div>
<h2 id="offer-full-feature-set">7. Offer the app's full feature set to tablet users</h2>
<p>Let your tablet users experience the best features of your app. Here are
some recommendations:</p>
<ul>
<li>Design your app to offer at least the same set of features on tablets as it does on
handsets. </li>
<li>In exceptional cases, your app might omit or replace certain features on
tablets if they are not supported by the hardware or use-case of most tablets.
For example:
<ul>
<li>If the handset uses telephony features but telephony is not available on the
current tablet, you can omit or replace the related functionality.</li>
<li>Many tablets have a GPS sensor, but most users would not normally carry
their tablets while running. If your phone app provides functionality to let the
user record a GPS track of their runs while carrying their phones, the app would not need to
provide that functionality on tablets because the use-case is not
compelling.</li>
</ul>
</li>
<li>If you will omit a feature or capability from your tablet UI, make sure
that it is not accessible to users or that it offers “graceful degradation”
to a replacement feature (also see the section below on hardware features).</li>
</ul>
<h2 id="android-versions">8. Target Android versions properly</h2>
<p>To ensure the broadest possible distribution to tablets, make sure that your
app properly targets the Android versions that support tablets. Initial support for
tablets was added in <a href="{@docRoot}about/versions/android-3.0">Android 3.0</a> (API level 11). Unified UI
framework support for tablets, phones, and other devices was introduced in <a href="{@docRoot}about/versions/android-4.0">Android 4.0</a> (API level 14) and is supported in later versions.
<p>You can set the app's
range of targeted Android versions in the manifest file, in the
<a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><code><uses-sdk></code></a> element. In most cases, you can target Android versions properly by setting the element's <code>targetSdkVersion</code> attribute to the highest API level available.</p>
<p style="margin-bottom:.5em;">At a minimum, check the <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html"><code><uses-sdk></code></a>
element to make sure that:</p>
<ol style="list-style-type:lower-alpha;margin-top:0em;">
<li><code>targetSdkVersion</code> is declared with value 11 or higher (14 or higher is recommended), OR</li>
<li><code>minSdkVersion</code> is declared with value 11 or higher.</li>
<li>If a <code>maxSdkVersion</code> attribute is declared, it must have a value of 11 or higher. Note that, in general, the use of <code>maxSdkVersion</code> is <em>not recommended</em>.</li>
</ol>
<div class="rel-resources">
<h3>
Related resources
</h3>
<ul>
<li>
<a href=
"{@docRoot}guide/topics/manifest/uses-sdk-element.html#ApiLevels">Android API
Levels</a>—Introduces API levels and how they relate to compatibility.
A reference of available API levels is included.
</li>
<li>
<a href="{@docRoot}training/basics/supporting-devices/platforms.html">Supporting Different Platform Versions</a>—Training class showing how to declare support for
minimum and target API levels in your app.
</li>
</ul>
</div>
<h2 id="hardware-requirements">9. Declare hardware feature dependencies properly</h2>
<p>
Handsets and tablets typically offer slightly different hardware support for
sensors, camera, telephony, and other features. For example, many tablets are
available in a "Wi-Fi" configuration that does not include telephony support.
</p>
<p>
So that you can distribute a single APK broadly across your full customer
base of phones and tablets, make sure that your app doesn't declare
requirements for hardware features that aren't commonly available on tablets.
Instead, properly declare the hardware features as <em>not required</em> in the app
manifest, as described below.
</p>
<ul>
<li>In your app manifest, locate any <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a>
elements. In particular, look for hardware features that might not be
available on some tablets, such as:
<ul>
<li><code>android.hardware.telephony</code></li>
<li><code>android.hardware.camera</code> (refers to back camera), or</li>
<li><code>android.hardware.camera.front</code></li>
</ul></li>
<li>Declare the <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a>
elements as <em>not required</em> by including the <code>android:required=”false”</code>
attribute.
<p>
For example, here's the proper way to declare a dependency on
<code>android.hardware.telephony</code>, such that you can still
distribute the app broadly, even to devices that don't offer telephony:
</p>
<pre><uses-feature android:name="android.hardware.telephony" android:required="false" /></pre></li>
<li>Similarly, check the manifest for <a href="/guide/topics/manifest/permission-element.html"><code><permission></code></a> elements that
<a href="/guide/topics/manifest/uses-feature-element.html#permissions">imply hardware
feature requirements</a> that not be appropriate for tablets. If you find such
permissions, make sure to explicitly declare a corresponding
<code><uses-feature></code> element for the features and includes the
<code>android:required=”false”</code> attribute.</li>
</ul>
<p>
After declaring hardware features as <em>not required</em>, make sure to test
your app on a variety of devices. The app should function normally when the
hardware features it uses are not available, and it should offer "graceful
degradation" and alternative functionality where appropriate.
</p>
<p>
For example, if an app normally uses GPS to set the location but GPS is not
supported on the device, the app could let the user set the location manually
instead. The app can check for device hardware capabilities at runtime and handle
as needed.
</p>
<div class="rel-resources">
<h3>
Related resources
</h3>
<ul>
<li>
<a href=
"{@docRoot}guide/topics/manifest/uses-feature-element.html#permissions">Permissions
that Imply Feature Requirements</a>—A list of permissions that may
cause unwanted filtering if declared in your app's manifest.
</li>
<li>
<a href=
"{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a>—Description
and reference documentation for the <code><uses-feature></code>
manifest element.
</li>
<li>
<a href="{@docRoot}guide/topics/manifest/uses-feature-element.html#testing">Testing
the features required by your application</a>—Description of how to
determine the actual set of hardware and software requirements (explicit or
implied) that your app requires.
</li>
</ul>
</div>
<h2 id="support-screens">10. Declare support for tablet screens</h2>
<p>To ensure that you can distribute your app to a broad range of tablets, your app should
declare support for tablet screen sizes in its manifest file, as follows:</p>
<ul>
<li>A
<a href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><code><supports-screens></code></a>
element, if declared, must not specify <code>android:largeScreens="false"</code>
or <code>android:xlargeScreens="false"</code>.</li>
<li>For apps targeting <code>minSdkVersion</code> value less than 13, a
<a href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><code><supports-screens></code></a>
element must be declared with both <code>android:largeScreens="true"</code> and
<code>android:xlargeScreens="true"</code>.</li>
</ul>
<p>If the app declares a
<a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html"><code><compatible-screens></code></a>
element in the manifest, the element should include attributes that specify
<em>all of the size and density combinations for tablet screens</em> that the
app supports. Note that, if possible, you should avoid using the
<a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html"><code><compatible-screens></code></a>
element in your app.</p>
<div class="rel-resources">
<h3>
Related resources
</h3>
<ul>
<li>
<a href=
"{@docRoot}guide/practices/screens_support.html#DeclaringScreenSizeSupport">Declaring
Screen Size Support</a>—Developer documentation that explains the
details of managing UI for best display on multiple screen sizes.
</li>
</ul>
</div>
<h2 id="google-play">11. Showcase your tablet UI in Google Play</h2>
<p>
After you've done the work to create an rich, optimized UI for your tablet
app, make sure that you let your customers know about it! Here are some key
ways to promote your tablet app to users on Google Play.
</p>
<h4>
Upload screenshots of your tablet UI
</h4>
<p>
Tablet users want to know what your app is like on a tablet device, not on a
phone. If you developed a tablet app, make sure to upload screenshots
of your tablet UI to the Google Play Developer Console. Here are some guidelines:
</p>
<ul style="margin-top:0;">
<li>Your screenshots should show the core functionality of your app, not a
startup or sign-in page. Wherever users will spend most of their time, that's
what you should show in your screenshots.
</li>
<li>Add screenshots taken on both 7-inch and 10-inch tablets.
</li>
<li>It's recommended that you add screenshots taken in both landscape and
portrait orientations, if possible.
</li>
<li>Use screen captures if possible. Avoid showing actual device hardware in your
screenshots.</li>
<li>The recommended resolution of your tablet screenshots is <strong>1280 x 720</strong>
or higher in each orientation.
</li>
<li>You can upload as many as 8 screenshots of your tablet UI for 7-inch tablets
and an additional 8 for 10-inch tablets.
</li>
</ul>
<h4>
Update your app description and release notes
</h4>
<ul>
<li>In your app description, make sure to highlight that your app offers
tablet-optimized UI and great features for tablet users. Consider adding some
detail about how your tablet UI works and why users will like it.
</li>
<li>Include information about tablet support in the app's release notes and
update information.
</li>
</ul>
<h4>
Update your promotional video
</h4>
<p>
Many users view an app's promotional video to get an idea of what the app is
like and whether they'll enjoy it. For tablet users, capitalize on this
interest by highlighting your app's tablet UI in your promotional video. Here
are some tips and guidelines:
</p>
<ul>
<li>Add one or more shots of your app running on a tablet. To engage with
tablet users most effectively, it's recommended that you promote your tablet
UI in approximately equal proportion to your phone UI.
</li>
<li>Show your tablet UI as early as possible in the video. Don't assume that
tablet users will wait patiently through a feature walkthrough on a phone UI.
Ideally, you should engage them immediately by showing the tablet UI within
the first 10 seconds, or at the same point that you introduce the phone UI.
</li>
<li>To make it clear that you are showing a tablet UI, include shots of your
app running on a hand-held tablet device.
</li>
<li>Highlight your app's tablet UI in the video's narrative or voiceover.
</li>
</ul>
<h4>
Feature your tablet UI in your promotional campaigns
</h4>
<p>
Make sure to let tablet users know about your tablet UI in your promotional
campaigns, web site, social posts, advertisements, and elsewhere. Here are
some suggestions:
</p>
<ul>
<li>Plan a marketing or advertising campaign that highlights the use of your
app on tablets.</li>
<li>Show your tablet app at its best in your promotional campaigns—use the <a href=
"{@docRoot}distribute/promote/device-art.html">Device Art Generator</a> to
quickly generate a high-quality promotional image of your app running on a
7-inch or 10-inch tablet, in the orientation of your choice, with or without
drop-shadow and screen glare. It's as simple as capture, drag, and drop.
</li>
<li>Include a Google Play badge in your online promotions to let users link
directly to your app's store listing. You can generate a badge in a variety
of languages using the <a href=
"{@docRoot}distribute/googleplay/promote/badges.html">Badge Generator</a>.
</li>
</ul>
<div class="rel-resources">
<h3>
Related resources
</h3>
<ul>
<li>
<a href="{@docRoot}distribute/googleplay/publish/preparing.html">Publishing
Checklist</a>
—Recommendations on how to prepare your app for publishing, test
it, and launch successfully on Google Play.
</li>
<li>
<a href="https://play.google.com/apps/publish/">Google Play
Developer Console</a>—The tools console for publishing
your app to Android users.
</li>
<li>
<a href=
"{@docRoot}distribute/googleplay/promote/badges.html">Google Play
Badge Generator</a>—Create "Get it on Google Play" badges for your
app in a variety of languages with a single click.
</li>
<li>
<a href=
"{@docRoot}distribute/googleplay/promote/device-art.html">Device Art
Generator</a>—Drag and drop tool that lets you instantly create production-
ready art showing your app running on a tablet device.
</li>
</ul>
</div>
<h2 id="google-play-best-practices">12. Follow best practices for publishing in Google Play</h2>
<p>Here are some best practices for delivering a successful tablet app on Google Play.</p>
<h4 id="google-play-optimization-tips">Check out your app's Optimization Tips</h4>
<p>The Google Play Developer Console now offers an Optimization Tips page that
lets you quickly check how your app is doing against basic guidelines for tablet app
distribution and quality. To visit the page, sign into the Developer Console,
load the app from All Applications, and click Optimization Tips in
the left navigation.</p>
<div class="sidebox-wrapper">
<div class="sidebox">
<h2 style="line-height:1em;">How to Send Feedback</h2>
<p>Please use the link below to send
feedback or request a manual review of your Optimization Tips.</p>
<p>Make sure to read the relevant sections of the Tablet App Quality
Guidelines prior to sending feedback.</p>
<p><strong><a href="https://support.google.com/googleplay/android-developer/contact/tabletf"
target="_googleplay" style="white-space:nowrap">Tablet Optimization
Tips Feedback Form »</a></strong></p>
</div>
</div>
<p>The Developer Console creates your app's Optimization Tips page
by running a series of checks to verify basic quality
criteria. If it finds any issues, it alerts you to them as "To Do"
items in the Optimization Tips page.</p>
<p>If you've developed a tablet experience for your app, make sure
to visit the Optimization Tips page to see how your app is doing
against the basic checks. If there are any issues listed, we
recommend addressing them in your app and uploading a new binary for
distribution, if needed.</p>
<p>If the Optimization Tips page lists "To Do" issues that you feel don't
apply to your app or affect its quality on tablets, please notify us
using the <a href="https://support.google.com/googleplay/android-developer/contact/tabletf"
target="_googleplay" style="white-space:nowrap">Tablet Optimization
Tips Feedback Form</a>. We
will review your app and update your Optimization Tips page as
appropriate.</p>
<h4>Confirm the app's filtering</h4>
<p>After you've uploaded the app to the <a href="https://play.google.com/apps/publish/">Developer Console</a>, check the APK's Supported Devices list to make sure that the app is not filtered from tablet devices that you want to target.</p>
<h4>Distribute as a single APK</h4>
<p>
It's recommended that you publish your app as a single APK for all screen
sizes (phones and tablets), with a single Google Play listing. This approach
has several important advantages.
</p>
<ul style="margin-top:.25em;">
<li>Easier for users to find your app from search, browsing, or promotions
</li>
<li>Easier for users to restore your app automatically if they get a new
device.
</li>
<li>Your ratings and download stats are consolidated across all devices.
</li>
<li>Publishing a tablet app in a second listing can dilute ratings for your
brand.
</li>
</ul>
<p>
If necessary, you can alternatively choose to deliver your app using <a href=
"{@docRoot}google/play/publishing/multiple-apks.html">Multiple APK Support</a>,
although in most cases using a single APK to reach all devices is strongly
recommended.
</p>
<div class="rel-resources">
<h3>Related resources</h3>
<ul>
<li><a href="{@docRoot}distribute/googleplay/publish/preparing.html">Publishing
Checklist</a>—
Recommendations on how to prepare your app for publishing, test it, and launch
successfully on Google Play.</li>
<li><a href="https://play.google.com/apps/publish/">Google Play Developer
Console</a>—The tools console for publishing your app to Android users.</li>
</ul>
</div>
<h2 id="test-environment">Setting Up a Test Environment for Tablets</h2>
<p>To assess the quality of your app on tablets — both for core app quality
and tablet app quality — you need to set up a suitable
hardware or emulator environment for testing. </p>
<p>The ideal test environment would
include a small number of actual hardware devices that represent key form
factors and hardware/software combinations currently available to consumers.
It's not necessary to test on <em>every</em> device that's on the market —
rather, you should focus on a small number of representative devices, even using
one or two devices per form factor. The table below provides an overview of
devices you could use for testing.</p>
<p>If you are not able to obtain actual hardware devices for testing, you should
<a href="{@docRoot}tools/devices/index.html">set up emulated devices (AVDs)</a>
to represent the most common form factors and
hardware/software combinations. See the table below for suggestions on the emulator
configurations to use. </p>
<p>To go beyond basic testing, you can add more devices, more form factors, or
new hardware/software combinations to your test environment. For example, you
could include mid-size tablets, tablets with more or fewer hardware/software
features, and so on. You can also increase the number or complexity of tests
and quality criteria. </p>
<p class="table-caption"><strong>Table 1</strong>. A typical tablet test environment might
include one or two devices from each row in the table below, with one of the
listed platform versions, screen configurations, and hardware feature configurations.</p>
<table>
<tr>
<th>Type</th>
<th>Size</th>
<th>Density</th>
<th>Version</th>
<th>AVD Skin</th>
</tr>
<tr>
<td>7-inch tablet</td>
<td><span style="white-space:nowrap"><code>large</code> or</span><br /><code>-sw600</code></td>
<td><code>hdpi</code>,<br /><code>tvdpi</code></td>
<td>Android 4.0+ (API level 14 and higher)</td>
<td>WXGA800-7in</td>
</tr>
<tr>
<td><span style="white-space:nowrap">10-inch</span> tablet</td>
<td><span style="white-space:nowrap"><code>xlarge</code> or</span><br /><code>-sw800</code></td>
<td><code>mdpi</code>,<br /><code>hdpi</code>,<br /><code>xhdpi</code></td>
<td>Android 3.2+ (API level 13 and higher)</td>
<td>WXGA800</td>
</tr>
</table>
|