| page.title=Tablet App Quality Checklist |
| @jd:body |
| <div id="butterbar-wrapper" > |
| <div id="butterbar" > |
| <div id="butterbar-message"> |
| <a target="_blank" href="https://docs.google.com/a/google.com/forms/d/1EHLPGqhbxj2HungHRRN4_0K9TGpc-Izy-u46vBDgS8Q/viewform"> |
| Take the Android Developer Survey</a> |
| </div> |
| </div> |
| </div> |
| |
| <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>To ensure your app looks its best, provide icons and other bitmap |
| assets for each density in the range commonly supported by tablets. Specifically, you should |
| design your icons for the action bar, notifications, and launcher according to the |
| <a href="{@docRoot}design/style/iconography.html">Iconography</a> guidelines and |
| provide them in multiple densities, so they appear at the appropriate size on all screens |
| without blurring or other scaling artifacts.</p> |
| |
| <p class="table-caption"><strong>Table 1</strong>. Raw asset sizes for icon types.<table> |
| <tr> |
| <th>Density</th> |
| <th>Launcher</th> |
| <th>Action Bar</th> |
| <th>Small/Contextual</th> |
| <th>Notification</th> |
| </tr> |
| <tr> |
| <td><code>mdpi</code></td> |
| <td>48x48 px</td> |
| <td>32x32 px</td> |
| <td>16x16 px</td> |
| <td>24x24 px</td> |
| </tr> |
| <tr> |
| <td><code>hdpi</code></td> |
| <td>72x72 px</td> |
| <td>48x48 px</td> |
| <td>24x24 px</td> |
| <td>36x36 px</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>96x96 px</td> |
| <td>64x64 px</td> |
| <td>32x32 px</td> |
| <td>48x48 px</td> |
| </tr> |
| <tr> |
| <td><code>xxhdpi</code></td> |
| <td>144x144 px</td> |
| <td>96x96 px</td> |
| <td>48x48 px</td> |
| <td>74x74 px</td> |
| </tr> |
| |
| </table> |
| |
| <p>Your app should supply a version of each icon and bitmap asset that's optimized |
| for <strong>at least one</strong> the following common tablet screen densities:</p> |
| |
| <ul> |
| <li><code>hdpi</code></li> |
| <li><code>xhdpi</code></li> |
| <li><code>xxhdpi</code></li> |
| </ul> |
| |
| <p>Other tips:</p> |
| |
| <ul> |
| <li>When possible, use vector shapes for your icon designs so you can scale them |
| without loss of detail and edge crispness.</li> |
| <li>Use density-specific <a |
| href="{@docRoot}guide/topics/resources/providing-resources.html#AlternativeResources"> |
| resource qualifiers</a> to ensure that the proper icons are loaded for each screen density.</li> |
| <li>Tablets and other large screen devices often request a launcher icon that is one density |
| size larger than the device's actual density, so you should provide your launcher |
| icon at the highest density possible. For example, if a tablet has an {@code xhdpi} screen, |
| it will request the {@code xxhdpi} version of the launcher icon.</li> |
| </ul> |
| |
| <div class="rel-resources"> |
| <h3> |
| Related resources |
| </h3> |
| |
| <ul> |
| <li> |
| <a href="{@docRoot}design/style/iconography.html">Iconography</a>— |
| Design guidelines and tips about how to create 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/tabletq" |
| target="_googleplay" style="white-space:nowrap">Designed for Tablets Contact 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/tabletq" |
| target="_googleplay" style="white-space:nowrap">Designed for Tablets Contact 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> |