1 page.title=Tablet App Quality Checklist
4 <div id="qv-wrapper"><div id="qv">
8 <li><a href="#core-app-quality">1. Test for Basic Tablet App Quality</a></li>
9 <li><a href="#optimize-layouts">2. Optimize your layouts</a></li>
10 <li><a href="#use-extra-space">3. Use the extra screen area</a></li>
11 <li><a href="#use-tablet-icons">4. Use assets designed for tablets</a></li>
12 <li><a href="#adjust-font-sizes">5. Adjust fonts and touch targets</a></li>
13 <li><a href="#adjust-widgets">6. Adjust homescreen widgets</a></li>
14 <li><a href="#offer-full-feature-set">7. Offer the app's full feature set</a></li>
15 <li><a href="#android-versions">8. Target Android versions properly</a></li>
16 <li><a href="#hardware-requirements">9. Declare dependencies properly</a></li>
17 <li><a href="#support-screens">10. Declare tablet screens support</a></li>
18 <li><a href="#google-play">11. Showcase your tablet UI</a></li>
19 <li><a href="#google-play-best-practices">12. Follow publishing best practices</a></li>
24 <li><a href="#test-environment">Setting Up a Test Environment</a></li>
28 <p>Before you publish an app on Google Play, it's important to make sure that
29 the app meets the basic expectations of tablet users through compelling features
30 and an intuitive, well-designed UI. </p>
32 <p>Tablets are a growing part of the Android installed base that offers new
34 href="{@docRoot}distribute/googleplay/spotlight/tablets.html">user engagement
35 and monetization</a>. If your app is targeting tablet users, this document helps
36 you focus on key aspects of quality, feature set, and UI that can have a
37 significant impact on the app's success. Each focus area is given as checklist
38 item, with each one comprising several smaller tasks or best practices.</p>
40 <p>Although the checklist tasks below are numbered for convenience,
41 you can handle them in any order and address them to the extent that you feel
42 is right for your app. In the interest of delivering the best possible product
43 to your customers, follow the checklist recommendations
44 to the greatest extent possible. </p>
46 <p>As you move through the checklist, you'll find links to support resources
47 that can help you address the topics raised in each task.</p>
50 <h2 id="core-app-quality" style="margin-top:1.5em;">1. Test for basic tablet app quality</h2>
52 <p>The first step in delivering a great tablet app experience is making sure
53 that it meets the <em>core app quality criteria</em> for all of the devices
54 and form factors that the app is targeting. For complete information, see the <a
55 href="{@docRoot}distribute/googleplay/quality/core.html">Core App Quality Guidelines</a>.
59 Before publishing, also ensure that your app passes several basic
60 technical checks and launch criteria, such as:
64 <li><a href="#android-versions">Targets appropriate Android versions</a></li>
65 <li><a href="#hardware-requirements">Specifies any hardware dependencies properly</a></li>
66 <li><a href="#support-screens">Declares support for appropriate screens</a></li>
67 <li><a href="#use-extra-space">Uses all of the available screen space</a></li>
68 <li><a href="#google-play">Screenshots are uploaded to Google Play</a></li>
71 <p>If your app is already uploaded to the Google Play Developer Console, you
72 can see how it is doing against these checks
73 by visiting the <a href="#google-play-optimization-tips">Optimization
77 <h2 id="optimize-layouts">2. Optimize your layouts for larger screens</h2>
79 <p>Android makes it easy to develop an app that runs well on a wide range of
80 device screen sizes and form factors. This broad compatibility works in your
81 favor, since it helps you design a single app that you can distribute widely to
82 all of your targeted devices. However, to give your users the best possible
83 experience on each screen configuration — in particular on tablets
84 — you need to optimize your layouts and other UI components for each
85 targeted screen configuration. On tablets, optimizing your UI lets you take
86 full advantage of the additional screen available, such as to offer new features,
87 present new content, or enhance the experience in other ways to deepen user
90 <p>If you developed your app for handsets and now want to distribute it to
91 tablets, you can start by making minor adjustments to your layouts, fonts, and
92 spacing. In some cases — such as for 7-inch tablets or for a game with
93 large canvas — these adjustments may be all
94 you need to make your app look great. In other cases, such as for larger
95 tablets, you can redesign parts of your UI to replace "stretched UI" with an
96 efficient multipane UI, easier navigation, and additional content. </p>
98 <p>Here are some suggestions:</p>
100 <div style="width:390px;float:right;margin:1.5em;margin-top:0em;">
101 <img src="{@docRoot}images/training/app-navigation-multiple-sizes-multipane-bad.png"
102 style="width:390px;padding:4px;margin-bottom:0em;">
103 <p class="image-caption" style="padding:0em .5em .5em 2em"><span
104 style="font-weight:500;">Get rid of "stretched" UI</span>: On tablets, single-pane
105 layouts lead to awkward whitespace and excessive line lengths. Use padding to
106 reduce the width of UI elements and consider using multi-pane layouts.</p>
110 <li>Provide custom layouts as needed for <code>large</code> and
111 <code>xlarge</code> screens. You can also provide layouts that are loaded based
112 on the screen's <a href="{@docRoot}guide/practices/screens_support.html#NewQualifiers">shortest
113 dimension</a> or the <a href="{@docRoot}guide/practices/screens_support.html#NewQualifiers">minimum
114 available width and height</a>. </li>
115 <li>At a minimum, customize dimensions such as font sizes, margins, spacing for
116 larger screens, to improve use of space and content legibility. </li>
117 <li>Adjust positioning of UI controls so that they are easily accessible to
118 users when holding a tablet, such as toward the sides when in
119 landscape orientation.</li>
120 <li>Padding of UI elements should normally be larger on tablets than on handsets. A
121 <a href="{@docRoot}design/style/metrics-grids.html#48dp-rhythm">48dp rhythm</a> (and a 16dp
122 grid) is recommended.</li>
123 <li>Adequately pad text content so that it is not aligned directly along screen edges.
124 Use a minimum <code>16dp</code> padding around content near screen edges.</li>
127 <p>In particular, make sure that your layouts do not appear "stretched"
128 across the screen:</p>
131 <li>Lines of text should not be excessively long — optimize for a maximum
132 100 characters per line, with best results between 50 and 75.</li>
133 <li>ListViews and menus should not use the full screen width.</li>
134 <li>Use padding to manage the widths of onscreen elements or switch to a
135 multi-pane UI for tablets (see next section).</li>
138 <div class="rel-resources">
146 "{@docRoot}design/style/metrics-grids.html">Metrics
147 and Grids</a>—Android Design document that explains how to create
148 layouts based on density-independent grids.
153 "{@docRoot}design/style/devices-displays.html">Devices
154 and Displays</a>—Android Design document that explains how to
155 design a UI that works well on different devices and
160 <a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple
161 Screens</a>—Developer documentation that explains the details of
162 managing UI for best display on multiple screen sizes.
167 "{@docRoot}guide/practices/screens_support.html#ConfigurationExamples">
168 Configuration examples</a>—Examples of how to declare layouts and
169 other resources for specific screen sizes.
175 <h2 id="use-extra-space">3. Take advantage of extra screen area available on tablets</h2>
177 <div style="width:290px;float:right;margin:1.5em;margin-bottom:0;margin-top:0;">
178 <img src="{@docRoot}images/training/app-navigation-multiple-sizes-multipane-good.png"
179 style="width:280px;padding:4px;margin-bottom:0em;">
180 <p class="image-caption" style="padding:0em .5em .5em 1.5em"><span
181 style="font-weight:500;">Multi-pane layouts</span> result in a better visual
182 balance on tablet screens, while offering more utility and legibility.</p>
185 <p>Tablet screens provide significantly more screen real estate to your app,
186 especially when in landscape orientation. In particular, 10-inch tablets offer a
187 greatly expanded area, but even 7-inch tablets give you more space for
188 displaying content and engaging users. </p>
190 <p>As you consider the UI of your app when running on tablets, make sure that it
191 is taking full advantage of extra screen area available on tablets. Here are
192 some suggestions:</p>
195 <li>Look for opportunities to include additional content or use an alternative
196 treatment of existing content.</li>
197 <li>Use <a href="{@docRoot}design/patterns/multi-pane-layouts.html">multi-pane
198 layouts</a> on tablet screens to combine single views into a compound view. This
199 lets you use the additional screen area more efficiently and makes it easier for
200 users to navigate your app. </li>
201 <li>Plan how you want the panels of your compound views to reorganize when
202 screen orientation changes.</li>
204 <div style="width:490px;margin:1.5em auto 1.5em 0;">
206 <img src="{@docRoot}images/ui-ex-single-panes.png"
207 style="width:490px;padding:4px;margin-bottom:0em;" align="middle">
208 <img src="{@docRoot}images/ui-ex-multi-pane.png" style="width:490px;padding:4px;margin-bottom:0em;">
209 <p class="image-caption" style="padding:.5em"><span
210 style="font-weight:500;">Compound views</span> combine several single views from a
211 handset UI <em>(above)</em> into a richer, more efficient UI for tablets
212 <em>(below)</em>. </p>
216 <li>While a single screen is implemented as an {@link android.app.Activity}
217 subclass, consider implementing individual content panels as {@link
218 android.app.Fragment} subclasses. This lets you
219 maximize code reuse across different form factors and across screens that
221 <li>Decide on which screen sizes you'll use a multi-pane UI, then provide the
222 different layouts in the appropriate screen size buckets (such as
223 <code>large</code>/<code>xlarge</code>) or minimum screen widths (such as
224 <code>sw600dp</code>/<code>sw720</code>).</li>
227 <div class="rel-resources">
234 <a href="{@docRoot}design/patterns/multi-pane-layouts.html">Multi-pane
235 Layouts</a>—Android Design guide for using multi-pane UI, including
236 examples of how to flatten navigation and integrate more content into
242 "{@docRoot}training/design-navigation/multiple-sizes.html">Planning for Multiple
243 Touchscreen Sizes</a>—Android Training class that walks you through
244 the essentials of planning an intuitive, effective navigation for tablets
249 <a href="{@docRoot}training/multiscreen/index.html">Designing for
250 Multiple Screens</a>—Android Training class that walks you through
251 the essentials of planning an intuitive, effective navigation for tablets
258 <h2 id="use-tablet-icons">4. Use Icons and other assets that are designed
259 for tablet screens</h2>
261 <p>So that your app looks its best, make sure to use icons and other bitmap
262 assets that are created specifically for the densities used by tablet screens.
263 Specifically, you should create sets of alternative bitmap drawables for each
264 density in the range commonly supported by tablets.</p>
266 <p class="table-caption"><strong>Table 1</strong>. Raw asset sizes for icon types.<table>
269 <th colspa>Launcher</th>
271 <th>Small/Contextual</th>
272 <th>Notification</th>
275 <td><code>mdpi</code></td>
282 <td><code>hdpi</code></td>
289 <td><code>tvdpi</code></td>
290 <td><em>(use hdpi)</em></td>
291 <td><em>(use hdpi)</em></td>
292 <td><em>(use hdpi)</em></td>
293 <td><em>(use hdpi)</em></td>
296 <td><code>xhdpi</code></td>
305 <p>Other points to consider: </p>
308 <li>Icons in the action bar, notifications, and launcher should be designed
309 according to the icon design guidelines and have the same physical size on
310 tablets as on phones.</li>
311 <li>Use density-specific <a
312 href="{@docRoot}guide/topics/resources/providing-resources.html#AlternativeResources">
313 resource qualifiers</a> to ensure that the proper set of alternative resources
317 <p style="margin-bottom:.5em;">At a minimum, your app should supply sets of
318 custom drawables and assets for common tablet screen densities,
319 tagged with these qualifiers as appropriate:</p>
322 <li><code>hdpi</code>, OR</li>
323 <li><code>xhdpi</code>, OR</li>
324 <li><code>xxhdpi</code></li>
327 <div class="rel-resources">
334 <a href="{@docRoot}design/style/iconography.html">Iconography</a>— Android
335 Design document that shows how to use various types of icons.
340 "{@docRoot}guide/topics/resources/providing-resources.html">Providing
341 Resources</a>—Developer documentation on how to provide
342 sets of layouts and drawable resources for specific ranges of device
347 <a href="{@docRoot}guide/practices/screens_support.html">Supporting
348 Multiple Screens</a>—API Guide documentation that
349 explains the details of managing UI for best display on multiple screen
355 "{@docRoot}training/basics/supporting-devices/screens.html">Supporting Different
356 Screens</a>—Android Training class that takes you
357 through the process of optimizing the user experience for different
358 screen sizes and densities.
364 <h2 id="adjust-font-sizes">5. Adjust font sizes and touch targets for tablet screens</h2>
366 <p>To make sure your app is easy to use on tablets, take some time to adjust the
367 font sizes and touch targets in your tablet UI, for all of the screen
368 configurations you are targeting. You can adjust font sizes through <a
369 href="{@docRoot}guide/topics/ui/themes.html">styleable attributes</a> or <a
370 href="{@docRoot}guide/topics/resources/more-resources.html#Dimension">dimension
371 resources</a>, and you can adjust touch targets through layouts and bitmap
372 drawables, as discussed above. </p>
374 <p>Here are some considerations:</p>
376 <li>Text should not be excessively large or small on tablet screen sizes and
377 densities. Make sure that labels are sized appropriately for the UI elements they
378 correspond to, and ensure that there are no improper line breaks in labels,
379 titles, and other elements.</li>
380 <li>The recommended touch-target size for onscreen elements is 48dp (32dp
381 minimum) — some adjustments may be needed in your tablet UI. Read <a
382 href="{@docRoot}design/style/metrics-grids.html">Metrics and
384 </a> to learn about implementation strategies to help most of your users. To
385 meet the accessibility needs of certain users, it may be appropriate to use
386 larger touch targets. </li>
387 <li>When possible, for smaller icons, expand the touchable area to more than
388 48dp using {@link android.view.TouchDelegate}
389 or just centering the icon within the transparent button.</li>
392 <div class="rel-resources">
400 "{@docRoot}design/style/metrics-grids.html">Metrics
401 and Grids</a> —Android Design document that explains how to arrange
402 and size touch targets and other UI elements on the screen.
406 <a href="{@docRoot}design/style/typography.html">Typography</a>—Android
407 Design document that gives an overview of how to use typography in your
412 <a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple
413 Screens</a>—Developer documentation that explains the details of
414 managing UI for best display on multiple screen sizes.
418 <a href="{@docRoot}training/multiscreen/screendensities.html">Supporting
419 Different Densities</a>—Android Training class that shows you how
420 to provide sets of layouts and drawable resources for specific ranges of
427 <h2 id="adjust-widgets">6. Adjust sizes of home screen widgets for tablet screens</h2>
429 <p>If your app includes a home screen widget, here are a few points to consider
430 to ensure a great user experience on tablet screens: </p>
433 <li>Make sure that the widget's default height and width are set appropriately
434 for tablet screens, as well as the minimum and maximum resize height and width.
436 <li>The widget should be resizable to 420dp or more, to span 5 or more home
437 screen rows (if this is a vertical or square widget) or columns (if this is a
438 horizontal or square widget). </li>
439 <li>Make sure that 9-patch images render correctly.</li>
440 <li>Use default system margins.</li>
441 <li>Set the app's <code>targetSdkVersion</code> to 14 or higher, if
445 <div class="rel-resources">
452 <a href="{@docRoot}guide/topics/appwidgets/index.html#MetaData">Adding the
453 AppWidgetProviderInfo Metadata</a> —API Guide that explains how to
454 set the height and width dimensions of a widget.
458 <a href="{@docRoot}guide/practices/ui_guidelines/widget_design.html">App Widget
459 Design Guidelines</a>—API Guide that provides best practices and
460 techniques for designing and managing the size of widgets.
466 <h2 id="offer-full-feature-set">7. Offer the app's full feature set to tablet users</h2>
468 <p>Let your tablet users experience the best features of your app. Here are
469 some recommendations:</p>
472 <li>Design your app to offer at least the same set of features on tablets as it does on
474 <li>In exceptional cases, your app might omit or replace certain features on
475 tablets if they are not supported by the hardware or use-case of most tablets.
478 <li>If the handset uses telephony features but telephony is not available on the
479 current tablet, you can omit or replace the related functionality.</li>
480 <li>Many tablets have a GPS sensor, but most users would not normally carry
481 their tablets while running. If your phone app provides functionality to let the
482 user record a GPS track of their runs while carrying their phones, the app would not need to
483 provide that functionality on tablets because the use-case is not
487 <li>If you will omit a feature or capability from your tablet UI, make sure
488 that it is not accessible to users or that it offers “graceful degradation”
489 to a replacement feature (also see the section below on hardware features).</li>
492 <h2 id="android-versions">8. Target Android versions properly</h2>
494 <p>To ensure the broadest possible distribution to tablets, make sure that your
495 app properly targets the Android versions that support tablets. Initial support for
496 tablets was added in <a href="{@docRoot}about/versions/android-3.0">Android 3.0</a> (API level 11). Unified UI
497 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.
499 <p>You can set the app's
500 range of targeted Android versions in the manifest file, in the
501 <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>
503 <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>
504 element to make sure that:</p>
506 <ol style="list-style-type:lower-alpha;margin-top:0em;">
507 <li><code>targetSdkVersion</code> is declared with value 11 or higher (14 or higher is recommended), OR</li>
508 <li><code>minSdkVersion</code> is declared with value 11 or higher.</li>
509 <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>
512 <div class="rel-resources">
520 "{@docRoot}guide/topics/manifest/uses-sdk-element.html#ApiLevels">Android API
521 Levels</a>—Introduces API levels and how they relate to compatibility.
522 A reference of available API levels is included.
525 <a href="{@docRoot}training/basics/supporting-devices/platforms.html">Supporting Different Platform Versions</a>—Training class showing how to declare support for
526 minimum and target API levels in your app.
531 <h2 id="hardware-requirements">9. Declare hardware feature dependencies properly</h2>
534 Handsets and tablets typically offer slightly different hardware support for
535 sensors, camera, telephony, and other features. For example, many tablets are
536 available in a "Wi-Fi" configuration that does not include telephony support.
540 So that you can distribute a single APK broadly across your full customer
541 base of phones and tablets, make sure that your app doesn't declare
542 requirements for hardware features that aren't commonly available on tablets.
543 Instead, properly declare the hardware features as <em>not required</em> in the app
544 manifest, as described below.
548 <li>In your app manifest, locate any <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a>
549 elements. In particular, look for hardware features that might not be
550 available on some tablets, such as:
553 <li><code>android.hardware.telephony</code></li>
554 <li><code>android.hardware.camera</code> (refers to back camera), or</li>
555 <li><code>android.hardware.camera.front</code></li>
558 <li>Declare the <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a>
559 elements as <em>not required</em> by including the <code>android:required=”false”</code>
563 For example, here's the proper way to declare a dependency on
564 <code>android.hardware.telephony</code>, such that you can still
565 distribute the app broadly, even to devices that don't offer telephony:
568 <pre><uses-feature android:name="android.hardware.telephony" android:required="false" /></pre></li>
570 <li>Similarly, check the manifest for <a href="/guide/topics/manifest/permission-element.html"><code><permission></code></a> elements that
571 <a href="/guide/topics/manifest/uses-feature-element.html#permissions">imply hardware
572 feature requirements</a> that not be appropriate for tablets. If you find such
573 permissions, make sure to explicitly declare a corresponding
574 <code><uses-feature></code> element for the features and includes the
575 <code>android:required=”false”</code> attribute.</li>
580 After declaring hardware features as <em>not required</em>, make sure to test
581 your app on a variety of devices. The app should function normally when the
582 hardware features it uses are not available, and it should offer "graceful
583 degradation" and alternative functionality where appropriate.
587 For example, if an app normally uses GPS to set the location but GPS is not
588 supported on the device, the app could let the user set the location manually
589 instead. The app can check for device hardware capabilities at runtime and handle
593 <div class="rel-resources">
601 "{@docRoot}guide/topics/manifest/uses-feature-element.html#permissions">Permissions
602 that Imply Feature Requirements</a>—A list of permissions that may
603 cause unwanted filtering if declared in your app's manifest.
607 "{@docRoot}guide/topics/manifest/uses-feature-element.html"><code><uses-feature></code></a>—Description
608 and reference documentation for the <code><uses-feature></code>
613 <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html#testing">Testing
614 the features required by your application</a>—Description of how to
615 determine the actual set of hardware and software requirements (explicit or
616 implied) that your app requires.
621 <h2 id="support-screens">10. Declare support for tablet screens</h2>
623 <p>To ensure that you can distribute your app to a broad range of tablets, your app should
624 declare support for tablet screen sizes in its manifest file, as follows:</p>
628 <a href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><code><supports-screens></code></a>
629 element, if declared, must not specify <code>android:largeScreens="false"</code>
630 or <code>android:xlargeScreens="false"</code>.</li>
631 <li>For apps targeting <code>minSdkVersion</code> value less than 13, a
632 <a href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><code><supports-screens></code></a>
633 element must be declared with both <code>android:largeScreens="true"</code> and
634 <code>android:xlargeScreens="true"</code>.</li>
637 <p>If the app declares a
638 <a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html"><code><compatible-screens></code></a>
639 element in the manifest, the element should include attributes that specify
640 <em>all of the size and density combinations for tablet screens</em> that the
641 app supports. Note that, if possible, you should avoid using the
642 <a href="{@docRoot}guide/topics/manifest/compatible-screens-element.html"><code><compatible-screens></code></a>
643 element in your app.</p>
645 <div class="rel-resources">
653 "{@docRoot}guide/practices/screens_support.html#DeclaringScreenSizeSupport">Declaring
654 Screen Size Support</a>—Developer documentation that explains the
655 details of managing UI for best display on multiple screen sizes.
661 <h2 id="google-play">11. Showcase your tablet UI in Google Play</h2>
664 After you've done the work to create an rich, optimized UI for your tablet
665 app, make sure that you let your customers know about it! Here are some key
666 ways to promote your tablet app to users on Google Play.
670 Upload screenshots of your tablet UI
674 Tablet users want to know what your app is like on a tablet device, not on a
675 phone. If you developed a tablet app, make sure to upload screenshots
676 of your tablet UI to the Google Play Developer Console. Here are some guidelines:
679 <ul style="margin-top:0;">
680 <li>Your screenshots should show the core functionality of your app, not a
681 startup or sign-in page. Wherever users will spend most of their time, that's
682 what you should show in your screenshots.
685 <li>Add screenshots taken on both 7-inch and 10-inch tablets.
688 <li>It's recommended that you add screenshots taken in both landscape and
689 portrait orientations, if possible.
692 <li>Use screen captures if possible. Avoid showing actual device hardware in your
695 <li>The recommended resolution of your tablet screenshots is <strong>1280 x 720</strong>
696 or higher in each orientation.
699 <li>You can upload as many as 8 screenshots of your tablet UI for 7-inch tablets
700 and an additional 8 for 10-inch tablets.
705 Update your app description and release notes
709 <li>In your app description, make sure to highlight that your app offers
710 tablet-optimized UI and great features for tablet users. Consider adding some
711 detail about how your tablet UI works and why users will like it.
714 <li>Include information about tablet support in the app's release notes and
720 Update your promotional video
724 Many users view an app's promotional video to get an idea of what the app is
725 like and whether they'll enjoy it. For tablet users, capitalize on this
726 interest by highlighting your app's tablet UI in your promotional video. Here
727 are some tips and guidelines:
731 <li>Add one or more shots of your app running on a tablet. To engage with
732 tablet users most effectively, it's recommended that you promote your tablet
733 UI in approximately equal proportion to your phone UI.
736 <li>Show your tablet UI as early as possible in the video. Don't assume that
737 tablet users will wait patiently through a feature walkthrough on a phone UI.
738 Ideally, you should engage them immediately by showing the tablet UI within
739 the first 10 seconds, or at the same point that you introduce the phone UI.
742 <li>To make it clear that you are showing a tablet UI, include shots of your
743 app running on a hand-held tablet device.
746 <li>Highlight your app's tablet UI in the video's narrative or voiceover.
751 Feature your tablet UI in your promotional campaigns
755 Make sure to let tablet users know about your tablet UI in your promotional
756 campaigns, web site, social posts, advertisements, and elsewhere. Here are
761 <li>Plan a marketing or advertising campaign that highlights the use of your
764 <li>Show your tablet app at its best in your promotional campaigns—use the <a href=
765 "{@docRoot}distribute/promote/device-art.html">Device Art Generator</a> to
766 quickly generate a high-quality promotional image of your app running on a
767 7-inch or 10-inch tablet, in the orientation of your choice, with or without
768 drop-shadow and screen glare. It's as simple as capture, drag, and drop.
771 <li>Include a Google Play badge in your online promotions to let users link
772 directly to your app's store listing. You can generate a badge in a variety
773 of languages using the <a href=
774 "{@docRoot}distribute/googleplay/promote/badges.html">Badge Generator</a>.
778 <div class="rel-resources">
785 <a href="{@docRoot}distribute/googleplay/publish/preparing.html">Publishing
787 —Recommendations on how to prepare your app for publishing, test
788 it, and launch successfully on Google Play.
792 <a href="https://play.google.com/apps/publish/">Google Play
793 Developer Console</a>—The tools console for publishing
794 your app to Android users.
798 "{@docRoot}distribute/googleplay/promote/badges.html">Google Play
799 Badge Generator</a>—Create "Get it on Google Play" badges for your
800 app in a variety of languages with a single click.
804 "{@docRoot}distribute/googleplay/promote/device-art.html">Device Art
805 Generator</a>—Drag and drop tool that lets you instantly create production-
806 ready art showing your app running on a tablet device.
811 <h2 id="google-play-best-practices">12. Follow best practices for publishing in Google Play</h2>
813 <p>Here are some best practices for delivering a successful tablet app on Google Play.</p>
815 <h4 id="google-play-optimization-tips">Check out your app's Optimization Tips</h4>
817 <p>The Google Play Developer Console now offers an Optimization Tips page that
818 lets you quickly check how your app is doing against basic guidelines for tablet app
819 distribution and quality. To visit the page, sign into the Developer Console,
820 load the app from All Applications, and click Optimization Tips in
821 the left navigation.</p>
823 <div class="sidebox-wrapper">
824 <div class="sidebox">
825 <h2 style="line-height:1em;">How to send feedback</h2>
827 <p>Please use the link below to send
828 feedback or request a manual review of your Optimization Tips.</p>
830 <p>Make sure to read the relevant sections of the Tablet App Quality
831 Guidelines prior to sending feedback.</p>
833 <p><strong><a href="https://support.google.com/googleplay/android-developer/contact/tabletq"
834 target="_googleplay" style="white-space:nowrap">Designed for Tablets Contact Form »</a></strong></p>
838 <p>The Developer Console creates your app's Optimization Tips page
839 by running a series of checks to verify basic quality
840 criteria. If it finds any issues, it alerts you to them as "To Do"
841 items in the Optimization Tips page.</p>
843 <p>If you've developed a tablet experience for your app, make sure
844 to visit the Optimization Tips page to see how your app is doing
845 against the basic checks. If there are any issues listed, we
846 recommend addressing them in your app and uploading a new binary for
847 distribution, if needed. </p>
849 <p>If the Optimization Tips page lists "To Do" issues that you feel don't
850 apply to your app or affect its quality on tablets, please notify us
851 using the <a href="https://support.google.com/googleplay/android-developer/contact/tabletq"
852 target="_googleplay" style="white-space:nowrap">Designed for Tablets Contact Form »</a>. We
853 will review your app and update your Optimization Tips page as
857 <h4>Confirm the app's filtering</h4>
859 <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>
861 <h4>Distribute as a single APK</h4>
864 It's recommended that you publish your app as a single APK for all screen
865 sizes (phones and tablets), with a single Google Play listing. This approach
866 has several important advantages.
869 <ul style="margin-top:.25em;">
870 <li>Easier for users to find your app from search, browsing, or promotions
873 <li>Easier for users to restore your app automatically if they get a new
877 <li>Your ratings and download stats are consolidated across all devices.
880 <li>Publishing a tablet app in a second listing can dilute ratings for your
886 If necessary, you can alternatively choose to deliver your app using <a href=
887 "{@docRoot}google/play/publishing/multiple-apks.html">Multiple APK Support</a>,
888 although in most cases using a single APK to reach all devices is strongly
892 <div class="rel-resources">
893 <h3>Related resources</h3>
895 <li><a href="{@docRoot}distribute/googleplay/publish/preparing.html">Publishing
897 Recommendations on how to prepare your app for publishing, test it, and launch
898 successfully on Google Play.</li>
899 <li><a href="https://play.google.com/apps/publish/">Google Play Developer
900 Console</a>—The tools console for publishing your app to Android users.</li>
905 <h2 id="test-environment">Setting Up a Test Environment for Tablets</h2>
907 <p>To assess the quality of your app on tablets — both for core app quality
908 and tablet app quality — you need to set up a suitable
909 hardware or emulator environment for testing. </p>
911 <p>The ideal test environment would
912 include a small number of actual hardware devices that represent key form
913 factors and hardware/software combinations currently available to consumers.
914 It's not necessary to test on <em>every</em> device that's on the market —
915 rather, you should focus on a small number of representative devices, even using
916 one or two devices per form factor. The table below provides an overview of
917 devices you could use for testing.</p>
919 <p>If you are not able to obtain actual hardware devices for testing, you should
920 <a href="{@docRoot}tools/devices/index.html">set up emulated devices (AVDs)</a>
921 to represent the most common form factors and
922 hardware/software combinations. See the table below for suggestions on the emulator
923 configurations to use. </p>
925 <p>To go beyond basic testing, you can add more devices, more form factors, or
926 new hardware/software combinations to your test environment. For example, you
927 could include mid-size tablets, tablets with more or fewer hardware/software
928 features, and so on. You can also increase the number or complexity of tests
929 and quality criteria. </p>
931 <p class="table-caption"><strong>Table 1</strong>. A typical tablet test environment might
932 include one or two devices from each row in the table below, with one of the
933 listed platform versions, screen configurations, and hardware feature configurations.</p>
945 <td>7-inch tablet</td>
946 <td><span style="white-space:nowrap"><code>large</code> or</span><br /><code>-sw600</code></td>
947 <td><code>hdpi</code>,<br /><code>tvdpi</code></td>
948 <td>Android 4.0+ (API level 14 and higher)</td>
952 <td><span style="white-space:nowrap">10-inch</span> tablet</td>
953 <td><span style="white-space:nowrap"><code>xlarge</code> or</span><br /><code>-sw800</code></td>
954 <td><code>mdpi</code>,<br /><code>hdpi</code>,<br /><code>xhdpi</code></td>
955 <td>Android 3.2+ (API level 13 and higher)</td>