Tablets are a growing part of the Android installed base and offer new opportunities for user engagement and monetization. The guidelines in this document will help you meet the expectations of tablet users through compelling features and an intuitive, well-designed UI.
Although the guidelines are numbered, you can approach them in any order. You should address each guideline’s recommendations to the extent that they’re appropriate for your app, but — in the interest of delivering the best product to your customers — follow them to the greatest extent possible.
Through the document you'll find links to resources that can help you address each recommendation included.
The first step in delivering a great tablet app experience is making sure that it meets the core app quality criteria for all of the devices and form factors that the app is targeting. For complete information, see the Core App Quality Guidelines.
Before publishing, also ensure that your app passes the basic technical checks and launch criteria, such as:
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 Optimization Tips page.
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.
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.
Get rid of "stretched" UI: 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.
Here are some suggestions:
large and
xlarge screens. You can also provide layouts that are loaded
based on the screen's shortest
dimension or the minimum
available width and height.
16dp padding around content near
screen edges.
In particular, make sure that your layouts do not appear "stretched" across the screen:
Multi-pane layouts result in a better visual balance on tablet screens, while offering more utility and legibility.
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.
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:
Compound views combine several single views from a handset UI (above) into a richer, more efficient UI for tablets (below).
large/xlarge) or minimum screen widths (such as
sw600dp/sw720).
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 Iconography guidelines and provide them in multiple densities, so they appear at the appropriate size on all screens without blurring or other scaling artifacts.
Table 1. Raw asset sizes for icon types.
| Density | Launcher | Action Bar | Small/Contextual | Notification |
|---|---|---|---|---|
mdpi |
48x48 px | 32x32 px | 16x16 px | 24x24 px |
hdpi |
72x72 px | 48x48 px | 24x24 px | 36x36 px |
tvdpi |
(use hdpi) | (use hdpi) | (use hdpi) | (use hdpi) |
xhdpi |
96x96 px | 64x64 px | 32x32 px | 48x48 px |
xxhdpi |
144x144 px | 96x96 px | 48x48 px | 72x72 px |
As a minimum, supply a version of each icon and bitmap asset that's optimized for at least one the following common tablet screen densities:
hdpixhdpixxhdpiOther tips:
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 styleable attributes or dimension resources, and you can adjust touch targets through layouts and bitmap drawables, as discussed above.
Here are some considerations:
If your app includes a home screen widget, here are a few points to consider to ensure a great user experience on tablet screens:
targetSdkVersion to 14 or higher, if
possible.
Let your tablet users experience the best features of your app. Here are some recommendations:
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 Android 3.0 (API level 11). Unified UI framework support for tablets, phones, and other devices was introduced in Android 4.0
You can set the app's range of targeted Android versions in the manifest
file, in the <uses-sdk>
element. In most cases, you can target Android versions properly by setting
the element's targetSdkVersion attribute to the highest API
level available.
At a minimum, check the <uses-sdk>
element to make sure that:
targetSdkVersion is declared with value 11 or higher (14 or
higher is recommended), OR
minSdkVersion is declared with value 11 or higher.
maxSdkVersion attribute is declared, it must have a
value of 11 or higher. Note that, in general, the use of
maxSdkVersion is not recommended.
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.
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 not required in the app manifest, as described below.
<uses-feature>
elements. In particular, look for hardware features that might not be
available on some tablets, such as:
android.hardware.telephonyandroid.hardware.camera (refers to back camera), orandroid.hardware.camera.front<uses-feature>
elements as not required by including the android:required=”false”
attribute.
For example, here's the proper way to declare a dependency on
android.hardware.telephony, such that you can still
distribute the app broadly, even to devices that don't offer telephony:
<uses-feature android:name="android.hardware.telephony" android:required="false" />
<permission> elements that
imply hardware
feature requirements that not be appropriate for tablets. If you find such
permissions, make sure to explicitly declare a corresponding
<uses-feature> element for the features and includes the
android:required=”false” attribute.After declaring hardware features as not required, 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.
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.
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:
<supports-screens>
element, if declared, must not specify android:largeScreens="false"
or android:xlargeScreens="false".minSdkVersion value less than 13, a
<supports-screens>
element must be declared with both android:largeScreens="true" and
android:xlargeScreens="true".If the app declares a
<compatible-screens>
element in the manifest, the element should include attributes that specify
all of the size and density combinations for tablet screens that the
app supports. Note that, if possible, you should avoid using the
<compatible-screens>
element in your app.
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.
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:
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:
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:
Here are some best practices for delivering a successful tablet app on Google Play.
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.
Please use the link below to send feedback or request a manual review of your Optimization Tips.
Make sure to read the relevant sections of the Tablet App Quality Guidelines prior to sending feedback.
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.
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.
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 Designed for Tablets Contact Form ». We will review your app and update your Optimization Tips page as appropriate.
After you've uploaded the app to the Developer Console, check the APK's Supported Devices list to make sure that the app is not filtered from tablet devices that you want to target.
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.
If necessary, you can alternatively choose to deliver your app using Multiple APK Support, although in most cases using a single APK to reach all devices is strongly recommended.
Assess the quality of your app on tablets — both for core app quality and tablet app quality — with a suitable hardware or emulator environment for testing.
Compared to the recommended test environment for testing against the core app quality criteria, include mid-size tablets and tablets with more or fewer hardware/software features.
Table 1. 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.
| Type | Size | Density | Version | AVD Skin |
|---|---|---|---|---|
| 7-inch tablet | large or-sw600 |
hdpi,tvdpi |
Android 4.0+ (API level 14 and higher) | WXGA800-7in |
| 10-inch tablet | xlarge or-sw800 |
mdpi,hdpi,xhdpi |
Android 3.2+ (API level 13 and higher) | WXGA800 |