docs/html/distribute/googleplay/quality/tablet.jd

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 Core 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="#hardware-requirements">8. Don’t require hardware features</a></li>
<li><a href="#support-screens">9. Declare tablet screen support</a></li>
<li><a href="#google-play">10. Showcase your tablet UI</a></li>
<li><a href="#google-play-bp">11. Follow publishing best practices</a></li>

</ol>
<h2>Testing</h2>
<ol>
<li><a href="#basic-technical-checks">Basic Technical Checks for Tablets</a></li>
<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">1. Test for Core Tablet App Quality</h2>

<p>Before publishing, make sure that your app and it's store listing meet the
  core quality guidlines below. </p>

<h5>Core app quality</h5>

<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>

<h5>Basic technical checks for tablets</h5>
<p>
  Before publishing, you should also ensure that your app passes several basic
  technical checks, such as:
</p>

<ul>
  <li>Targeting appropriate Android versions</li>
  <li>Specifying any feature dependencies properly</li>
  <li>Declaring support for appropriate screens</li>
</ul>

<p>
  For details, see <a href="#basic-technical-checks">Basic Technical
  Checks</a>.
</p>

<h5>Tablet screenshots and other promotional tools</h5>

<p>Make sure that you upload screenshots of your tablet UI to the
  Developer Console and highlight your tablet experience in your app description,
  video, and promotional campaigns. For details, see <a href="#google-play">Showcase your
  tablet UI in Google Play.</a></p>

<h5>Test environment</h5>

<p>
  To assess the quality of your app on tablets, you need to set up a suitable
  hardware or emulator environment for testing. For more information, see
  <a href="#test-environment">Setting Up a Test Environment</a>.
</p>
<p>
  Note that a successful tablet app will go <em>well beyond the core and tablet
  app quality criteria</em> to offer a custom tablet experience to users. Read
  the sections below for ideas on how to plan and develop a great tablet UI for
  your app.
</p>


<div class="rel-resources">
  <h3>
    Related resources
  </h3>

  <ul>
    <li>
      <a href="{@docRoot}distribute/googleplay/quality/core.html">Core App
      Quality</a>&mdash;A set of core quality criteria that all Android apps
      should meet on all targeted devices.
    </li>

    <li>
      <a href="#basic-technical-checks">Basic Technical Checks for
      Tablets</a>&mdash;Additional quality criteria for any app that is
      targeting, designed for, or distributable to Android tablets.
    </li>
    <li>
      <a href="#google-play">Showcase your tablet UI on Google Play</a>&mdash;Information
      on how to upload tablet screenshots and promote your tablet app.
    </li>
  </ul>
</div>

<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 &mdash; in particular on tablets
&mdash; 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 &mdash; such as for 7-inch tablets or for a game with
large canvas &mdash; 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 &mdash; 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>&mdash;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>&mdash;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>&mdash;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>&mdash;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>&mdash;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=
      "/training/design-navigation/multiple-sizes.html">Planning for Multiple
      Touchscreen Sizes</a>&mdash;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>&mdash;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>

<div class="rel-resources">
  <h3>
    Related resources
  </h3>

  <ul>
    <li>
      <a href="{@docRoot}design/style/iconography.html">Iconography</a>&mdash; Android
      Design document that shows how to use various types of icons.
    </li>

    <li>
      <a href=
      "/guide/topics/resources/providing-resources.html">Providing
      Resources</a>&mdash;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>&mdash;API Guide documentation that
      explains the details of managing UI for best display on multiple screen
      sizes.
    </li>

    <li>
      <a href=
      "/training/basics/supporting-devices/screens.html">Supporting Different
      Screens</a>&mdash;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) &mdash; 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> &mdash;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>&mdash;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>&mdash;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>&mdash;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> &mdash;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>&mdash;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="hardware-requirements">8. Don’t require hardware features that might not be
  available on tablets</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>To ensure that you can deliver a single APK broadly across the
your full customer base, make sure that your app does not have built-in
requirements for hardware features that aren't commonly available on tablets.
</p>

<ul>
<li>Your app's manifest should not include <a
href="{@docRoot}guide/topics/manifest/uses-feature-element.html"><code>&lt;uses-feature&gt;</code></a>
elements for hardware features or capabilities that might not be
available on tablets, except when they are declared with the
<code>android:required=”false”</code> attribute. For example, your app should
not <em>require</em> features 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>Similarly, your app manifest should not include any <a
href="{@docRoot}guide/topics/manifest/permission-element.html"><code>&lt;permission&gt;</code></a> elements that <a
href="{@docRoot}guide/topics/manifest/uses-feature-element.html#permissions">imply
feature requirements</a> that might not be appropriate for tablets, except when
accompanied by a corresponding <code>&lt;uses-feature&gt;</code> element
declared with the <code>android:required=”false”</code> attribute.
<p>Here's an example of a dependency that's properly declared as "not required", so that 
it does not limit distribution to devices that do not support the dependency:</p>
<p><code>&lt;uses-feature android:name="android.hardware.telephony"
android:required="false" /&gt;</code></p></li>
</ul>

<p>In all cases, the app must function normally when the hardware features it
uses are not available and should offer "graceful degradation" and alternative
functionality where appropriate. For example, if GPS is not supported on the device,
your app could let the user set their location manually. The app should do
run-time checking for the hardware capability that it needs and handle as needed.</p>

<div class="rel-resources">
<h3>
  Related resources
</h3>

<ul>
  <li>
    <a href=
    "/guide/topics/manifest/uses-feature-element.html#permissions">Permissions
    that Imply Feature Requirements</a>&mdash;A list of permissions that may
    cause unwanted filtering if declared in your app's manifest.
  </li>
  <li>
    <a href=
    "/guide/topics/manifest/uses-feature-element.html"><code>&lt;uses-feature&gt;</code></a>&mdash;Description
    and reference documentation for the <code>&lt;uses-feature&gt;</code>
    manifest element.
  </li>

  <li>
    <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html#testing">Testing
    the features required by your application</a>&mdash;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">9. Declare support for tablet screen configurations</h2>

<p>To ensure that you can distribute your app to a broad range of tablets,
declare all the screen sizes that your app supports in its manifest:</p>

<ul>
<li>Declare a <a
href="{@docRoot}guide/topics/manifest/supports-screens-element.html"><code>&lt;supports-screens&gt;</code></a> element
with appropriate attributes, as needed. For details, see <a 
href="#basic-technical-checks">Basic Technical Checks</a>
later in this document.</li>
<li>If the app declares a <code>&lt;compatible-screens&gt;</code> element in the
manifest, the element must 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 this element in your app.</li>
</ul>

<div class="rel-resources">
  <h3>
    Related resources
  </h3>

  <ul>
    <li>
      <a href="#basic-technical-checks">Basic Technical
      Checks</a>&mdash;Includes details (see <a href="#TB-R4">TB-R4</a>) on how
      to properly declare screens support for tablet screen sizes.
    </li>

    <li>
      <a href=
      "/guide/topics/manifest/supports-screens-element.html"><code>&lt;supports-screens&gt;</code></a>&mdash;Description
      and reference documentation for the <code>&lt;supports-screens&gt;</code>
      manifest element.
    </li>

    <li>
      <a href=
      "/guide/practices/screens_support.html#DeclaringScreenSizeSupport">Declaring
      Screen Size Support</a>&mdash;Developer documentation that explains the
      details of managing UI for best display on multiple screen sizes.
    </li>
  </ul>
</div>


<h2 id="google-play">10. 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>

<h5>
  Upload screenshots of your tablet UI
</h5>

<p>
  Tablet users want to know what your app is like on a tablet device, not on a
  phone. Capitalize on their interest by showing them screenshots of your
  tablet UI on your app's store listing page. You can upload tablet screenshots
  from the Developer Console. Here are some tips and 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, if possible.
  </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>

<h5>
  Update your app description and release notes
</h5>

<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>

<h5>
  Update your promotional video
</h5>

<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>

<h5>
  Feature your tablet UI in your promotional campaigns
</h5>

<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&mdash;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>
      &mdash;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>&mdash;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>&mdash;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>&mdash;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-bp">11. Follow best practices for publishing in Google Play</h2>

<p>Make sure that your app follows key best practices that ensure broad
  distribution to tablet devices. </p>

<h5>Verify basic technical checks</h5>

  <ul>
    <li>Verify that the app is targeting the proper Android versions and screen sizes 
    for Android tablets. Follow the <a href="#basic-technical-checks">Basic Technical
    Checks for Tablets</a> listed in the next section. </li>
    <li>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></li>
  </ul>

<h5>
  Distribute as a single APK
</h5>

<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=
  "/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>&mdash;
  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>&mdash;The tools console for publishing your app to Android users.</li>
</ul>
</div>

<h2 id="basic-technical-checks">Basic Technical Checks for Tablets</h2>

<p>
  This section lists specific details on basic technical checks that you should
  perform before publishing. The checks ensure that your app is properly targeted to a
  broad range of tablet devices. Make sure that the app meets all of the checks
  listed below.
</p>

<p>
  To verify the basic technical checks, follow the <a href="#tests">Test
  Procedures</a> listed below. Before you start, you need to obtain need the
  application source code.
</p>

<h5 id="criteria">
Technical checks
</h5>

<table>
  <tr>
    <th style="width:2px;">
      Area
    </th>
    <th style="width:54px;">
      ID
    </th>
    <th>
      Description
    </th>
    <th style="width:54px;">
      Tests
    </th>
  </tr>
  <tr id="TB-R1">
    <td rowspan="2">Android Versions</td>
    <td>
      TB-R1
    </td>
    <td>
      <p style="margin-bottom:.5em;">App <em>does</em> target minimum Android versions
        that support tablets:</p>
      <ol style="margin-bottom:.5em;list-style-type:lower-alpha">
        <li><code>targetSdkVersion</code> is declared with value 11 or higher, OR</li>
        <li><code>minSdkVersion</code> is declared with value 11 or higher.</li>
      </ol>
    </td>
      <td><a href="#tests">TA-1</a></td>
  </tr>
  <tr id="TB-R2">
    <td>
      TB-R2
    </td>
    <td>
      <p style="margin-bottom:.5em;">App <em>does not</em> limit targeting to
        exclude Android versions that support tablets:</p>
      <ol style="margin-bottom:.5em;list-style-type:lower-alpha">
        <li><code>maxSdkVersion</code>, if declared, must have a value of 12
          or higher. </li>
      </ol>
      <p class="caution" style="margin-bottom:.25em;">Note that, in most cases, the use of <code>
        maxSdkVersion</code> is not recommended.</p>
    </td>
    <td><a href="#tests">TA-1</a></td>
  </tr>
  <tr id="TB-R3">
    <td rowspan="1">Feature Dependencies</td>
    <td>
      TB-R3
    </td>
    <td>
      <p style="margin-bottom:.5em;">App <em>does not</em> limit distribution to
        tablets by requiring hardware features not normally available on tablets,
        whether <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html#declared"
        declared explicitly</a> or <a href=
        "/guide/topics/manifest/uses-feature-element.html#permissions">implied by
        permissions</a>.
      </p> 
      <ol style="margin-bottom:.5em;list-style-type:lower-alpha">
        <li>the app must not declare a <code>&lt;uses-feature&gt;</code> element for
          <code>android.hardware.telephony</code> unless the element is specifically
          marked with the <code>android:required="false"</code> attribute. 
        </li>
      </ol>
      <p>For details, see <a href="#hardware-requirements">Hardware Requirements</a>
        earlier in this document.</p>
    </td>
    <td><a href="#tests">TA-1</a></td>
  </tr>
  <tr id="TB-R4">
  <td rowspan="2">Screens Support</td>
    <td>
      TB-R4
    </td>
    <td>
      <p style="margin-bottom:.5em;">App <em>does not</em> limit distribution to common
        tablet screen sizes:</p>
      <ol style="margin-bottom:.5em;list-style-type:lower-alpha">
        <li>If declared, <code>&lt;supports-screens&gt;</code> element must not specify
          <code>android:largeScreens="false"</code> or <code>android:xlargeScreens="false"</code>.</li>
        <li>For a <code>minSdkVersion</code> value less than 13, a <code>&lt;supports-screens&gt;</code>
          element must be declared with both <code>android:largeScreens="true"</code>
          and <code>android:xlargeScreens="true"</code>.</li>
      </ol>
    </td>
    <td><a href="#tests">TA-1</a></td>
  </tr>
  <tr id="TB-R5">
    <td>
          TB-R5
    </td>
    <td>
      <p style="margin-bottom:.5em;">App <em>does</em> supply custom drawables and
        assets for common tablet screen densities. Specifically, the APK must include
        corresponding resource directories tagged with these qualifiers:</p>
        <ol style="margin-bottom:.5em;list-style-type:lower-alpha">
            <li>An <code>hdpi</code> qualifier, OR</li>
            <li>An <code>xhdpi</code> qualifier, OR</li>
            <li>An <code>xxhdpi</code> qualifier</li>
          </ol>

          <p>For details, see <a href="#use-tablet-icons">Icons and Other Assets</a>
            earlier in this document.</p>
      </td>
    <td><a href="#tests">TA-2</a></td>
  </tr>
</table>

<p>If you use <a href="{@docRoot}google/play/publishing/multiple-apks.html">multiple APK
  support</a> to deliver size- or version-specific APKs, the APKs and their
  characteristics must meet all of the criteria listed above, either individually
  or as a cumulative set.</p>

<h5 id="tests">
  Test procedures
</h5>

<table>
  <tr>
    <th style="width:54px;">
      Procedure
    <th>
      Description
    </th>
  </tr>
    <td>
         TA-1
   </td>
    <td>
      <p style="margin-bottom:.5em;">Obtain the APK and inspect the manifest.xml file. Check for the required attribute values.</p>
    </td>
  </tr>
  <tr id="ta2">
    <td>
      TA-2
    </td>
    <td>
      <p style="margin-bottom:.5em;">Obtain the APK and inspect the resources
        directories. Make sure that the app includes custom drawables and assets
        directories tagged with the required qualifiers.</p>
      </td>
  </tr>
</table>

<div class="rel-resources">
  <h3>
    Related resources
  </h3>

  <ul>
    <li>
      <a href="{@docRoot}distribute/googleplay/quality/core.html">Core App
      Quality</a>&mdash;A set of core quality criteria that all Android apps
      should meet on all targeted devices.
    </li>

    <li>
      <a href="#test-environment">Setting up a Test
      Environment</a>&mdash;Information on how to set up an environment to test
      your app on tablets.
    </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 &mdash; both for core app quality
and tablet app quality &mdash; 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 &mdash;
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>